At IndigoBlue, we have spent many years developing and refining the ideas that help people understand how and why Agile works. In a recent workshop, I was asked how our ideas differ from the Agile Manifesto. It’s been a while since I analysed the manifesto in detail, and I found the process interesting.
In our model, the three key fundamental aspects of Agile are:
- Incremental delivery
- Uncertainty management
The Agile Manifesto actually maps to these quite easily:
- Individuals and interactions over processes and tools ( = Collaboration)
- Working software over comprehensive documentation ( = Incremental delivery)
- Customer collaboration over contract negotiation ( = Collaboration)
- Responding to change over following a plan ( = Uncertainty management)
The ones relating to collaboration are fairly straightforward, but the other two require a bit of explanation.
In a nutshell, incremental delivery is about achieving incremental value by delivering a series of ever more capable, complete solutions. Each of these solutions, or increments, must therefore be “working software”.
Traditional processes don’t generally think in terms of increments (although projects can have phases). Instead, they focus on a single point of completion, considering the work to be done as a single “batch”. Work breakdown is a series of stepwise refinements of the complete solution, starting with a series of design documents. So, saying we prefer “working software over comprehensive documentation” is another way of saying we prefer many small increments/batches over stepwise refinement of a single batch.
Uncertainty management is about making explicit and optimal decisions about when and how to resolve the things we don’t know. Traditional processes assume that all uncertainty is removed up-front, but this is suboptimal because it leads to lower quality resolutions (all decisions are made at the time where least is known) and it delays the delivery of value.
Of course, leaving all design decisions to the last minute does not work in the general case either. Reducing the cost of change enables decisions to be made later and makes it easier to perform experiments by implementing and then modifying real solutions. This directly improves the options available for uncertainty resolution.
This all leads to an important question: if there is a direct correlation between the two approaches, why do we explain them in a different way from the more well-known Agile Manifesto?
There are two main reasons for this:
- Incremental delivery and uncertainty management are more precise and usable concepts. For example, it makes more sense to answer the question “does your plan achieve a series of incrementally better systems?” than “does you plan value working software?”
- The way the Agile Manifesto is expressed has, in my opinion, caused some gross misunderstandings. The negatives of “documentation” and “planning” are not bad in themselves, but bad in what they imply: one-off deliverables and upfront uncertainty resolution. In fact, both documentation and planning are fundamentally important aspects of projects. The problem is that large numbers of people now follow these counterproductive mantras that “documentation is bad” and “planning is bad”.
Using the approach of the manifesto, we might say:
- We prefer collaborative teams over delegated tasks
- We prefer a flow of small, complete increments to a series of tasks adding up to a large increment
- We prefer addressing uncertainty at the best time to rigid approaches that treat all situations the same