BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Agile Techniques Content on InfoQ

  • Patterns for Continuous Delivery

    There is no one-size-fits-all solution to implementing Continuous Delivery. The number and composition of the teams will greatly affect what options are available and what trade-offs need to be made. Staff editor Jonathan Allen reflects on some of the patterns he has observed over the last 15 years.

  • Interview and Book Review: Continuous Delivery

    Continuous delivery means that a software product is production-ready from day one of the project, even if all features not implemented, and the product can be released to users on demand. InfoQ spoke with Jez Humble and David Farley, authors of "Continuous Delivery" book on the continuous delivery concept and how it can be used to deliver the software product more efficiently.

  • Limiting Work in Progress and Scrum

    Sean recounts the story of how he learned the value of limiting work in progress and removing blockages to allow the flow of work in an IT server lab, and how the lessons he learnt are now applied on Scrum teams doing software development.

  • Agile Architecture Interactions

    James Madison shows how architects can bring agile and architecture practices together to pragmatically balance business and architectural priorities while delivering both with agility.

  • Patterns-Based Engineering: Successfully Delivering Solutions via Patterns

    InfoQ spoke with Lee and Celso about the Patterns-Based Engineering: Successfully Delivering Solutions via Patterns book, discussing patterns for working with patterns, MDD and the promise of reuse. The book focuses on how to improve efforts in identifying, producing, managing and consuming patterns – leading to better software delivered more quickly with fewer resources.

  • Large-Scale Agile Design & Architecture: Ways of Working

    During my 2011 QCon London keynote on "Scaling Lean & Agile: Large, Multisite or Offshore Delivery", I mentioned — as an aside — that, "Architecture is a bad metaphor. We don't construct our software like a building, we grow it like a garden." This prompted many a tweet, and some people were interested in clarification or elaboration.

  • The Accidental Agilist: A Personal Look Back at 10 Years of the Agile Manifesto

    Johanna Rothman reflects on her journey to pragmatic agility. She discusses the way in which agile practices work together to improve project outcomes, and how this is not restricted to software development. She challenges teams to embrace the transparency that agile brings and stop talking about becoming agile and start doing it properly.

  • Estimation Toolkit

    No matter what kind of software you write, or the size company you work for, you probably have to provide estimates to someone. There are many techniques agile teams can use to help guide their estimation efforts. The toolkit described in this article consists of a number of novel approaches to estimating agile software projects that will help you answer the question – “When will we be done?”.

  • Doing Kanban Wrong

    Kanban as a tool to support lean software development continues to increase in popularity all the time. However, like countless tools before it, Kanban will be unfairly blamed for many project failures by people who are doing Kanban wrong. This article discusses some ways the author has tried to give Kanban a bad name. Hopefully these examples will keep you from falling into similar traps.

  • Agile Goal Setting

    It is well understood that too succeed in developing great applications or even great things in our lives we need goals. Goals that motivate and push us to go beyond the ordinary. However if we Google Agile Goal Setting there are few items that give much consideration to what these should look like or how to create them. Jurgen Appelo looks at what it takes to make great goals.

  • Technical Debt a Perspective for Managers

    Developers often talk about Technical Debt saying its slowing your projects down. What are they really saying? What measures can you take to reduce it before it cripples your projects?

  • Introducing New Technology in Agile

    This article combines the case-study experience of the author and a general decision-making framework for agile teams facing the challenge of introducing a new technology, mid-stream in a project.

BT