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.
The graphic from Spotify is utter bollocks. If you start off with a skateboard, you’ll end up with a hoverboard and not a car. Each of the steps in the ‘right’ way to do it (according to them) has zero re-use and entails a complete design (NOT re-design) from scratch. Each of the designs ends with a car – if you know you want a car then why waste all the time involved in going through those other options?
Their ‘wrong’ way of doing things is perhaps worse. If you want a car, you start with a chassis, axles with wheels, power and drive, and control mechanisms. You define the template with the user, and then work on the refinements. With agile you build the template as a proof of concept to see if it’s really what they want; scrap the PoC; and then do an iterative build. That way you find out early on that what they want is a quad.
Perhaps they put the graphic out there as a teaser to see how many people identified all the ways in which it was crap.
At the risk of boiling your blood further, here’s the creator of the original picture with more on the topic: http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp 🙂
I think the key point they’re trying to make on the ‘right’ way to do it is that you don’t know that your end state is a car. You’ve been given an open-ended business problem of ‘get the user from A to B’. Rather than leap to what you think is the right answer and building an expensive thing that turns out to be not what is needed at all, instead you create early releases to explore the context and possible solutions. Perhaps it turns out (to stretch the metaphor further) that the users need a way to get around a golf course and a cart is the most is appropriate answer, and a car would have been an inappropriate white elephant.