Are we agile yet?
When teams approach agile software development for the first time, they tend to focus on how to do it rather than why. Consequently, they’ll invest a considerable amount of time in establishing the daily and weekly practices which — “when seen from a distance” — will give everyone else the impression that these teams are now practising agile.
A very common pitfall that we have observed, when working with teams who try to shift to agile ways of working for the first time, is that these teams will focus so much on the daily practices and tools (for example the Scrum events and artifacts) that they will fail to recognise the very essence of agile software development: the different approach to value, risk and adaptability.
Waterfall
For those who remember Waterfall development, the advantages of the agile mindset may have seemed obvious when agile was first formalised. Because in Waterfall you define the entire set of requirements upfront, and then the system design, by definition Waterfall prescribes working with the “maximum theoretical batch size”. And it’s optimised to deliver fixed scope in a fixed time. The fixed time aspect is not inherently derived from the structure of a Waterfall project, but in practice, organisations will — unsurprisingly — start a new initiative having a budget and a timeline in mind.
Agile and Lean methods
Agile and Lean methods, on the other hand, stress the importance of a fast feedback cycle, achieved by trying to minimise development cycle time or equivalently by wrapping iterations in short time-boxes.
This is because being agile means being able to deliver value early and continuously to our customer, in a way that makes risk decrease fast while adaptability stays high throughout the project.
On the contrary, in Waterfall projects we deliver value late, when — following testing and integration — the system can be deployed for the customer to use.
Risk and adaptability
Waterfall development is risky. Because you don’t start writing code until the requirements and the system have been fully defined and signed-off; this means that you don’t get the benefit of early customer feedback. In this case, risk is not only the risk of having to revisit the requirements and the design when more is learned, but also the risk of building a product that is no longer desired by your customer and/or the risk of building extra features that your customer doesn’t actually need.
To keep adaptability high, the agile approach favours emergent architecture, a way to design just enough of the system just in time and defer decisions to the last responsible moment, in line with Lean thinking — unsurprisingly, Agile and Lean are really two sides of the same coin.
In Waterfall projects, adaptability decreases early and fast, because we’re making all the decisions upfront: late changes in the project are painful and costly.
When teams focus merely on daily stand-ups, planning meetings, demos and retrospectives without paying attention to value, risk and adaptability, they end up working in a way that resembles agile on the surface, but is really just “Waterfall with sprints”. We discuss this and other agile anti-patterns in a short series of blog posts:
As we’ll see, these anti-patterns are symptoms of organisational design issues that should be addressed as part of the “agile transformation” or the benefits of moving to agile will simply be confined to a new set of techniques and tools.
