Everyone seems to be doing agile these days. Not everyone is being agile however.

There is a big difference between employing the rituals of agile and really applying the agile manifesto values such as having working software that users can get benefit from every step of the way. This graphic describing how Spotify build products illustrates the point:

The image is powerful and intuitively rings true, but there are a few deeper points – possibly unintended – that are worth exploring.

The key message from the diagram is that there is more business and user benefit from having something that can be used every step of the way, and feedback from real usage will help to shape an end result that users really need.

This is an hugely significant point for agile projects, but I argue that this benefit is dependent on how well understood the problem domain and proposed solution is, as to whether this holds true, and the key thing is to pick the right method for the problem at hand.

The ‘not like this‘ approach arguably costs less if we are building a car (to deliberately take the analogy a bit too literally). Cars are a well understood product, with generally incremental improvements to a well understood design. The ‘not like this’ approach is well suited, as every single production step is focused on building a car, without distractions or rework. In the agile approach, between the later steps a significant amount of the product needs to be thrown away or reworked based on the lessons learnt from the previous step. If you’re absolutely clear of the required end product (a car in this case) in a well understood domain, and cost is a critical factor then this kind of incremental waterfall approach is arguably the way to go.

The ‘like this‘ agile approach could transpire to be less costly if the problem domain is poorly understood and the real need is unclear. Usage may identify that a bicycle does the job well enough, and avoid over-engineering (and over-pricing) the solution. Or perhaps step 4 reveals that the user really needs to use the vehicle in rough terrain; so a quad bike would be a more appropriate final goal and you can change target at this point. By comparison, if you’re building a car using the first approach, you might not discover that what is really needed is a quad bike until the product has been launched and you’re inundated with unhappy users for whom the car is the wrong answer.

To summarise: for novel and poorly understood requirements, concentrate on exploring the user need whilst delivering working software using agile techniques; for well understood deliverables and problem domains, use more ‘industrial’ techniques such as LEAN to deliver as efficiently and effectively as possible. The trick is then to identify which ‘mode’ you’re in, and also when and how to move from one mode of development to another.