If you are directly involved with software development or wonder about how it is done this gives an interesting insight into it - if you do or have done a little/some/lots of writing code in a professional context - it rings pretty true:
It mostly rings true for me - maybe not the very end.
Well, ‘waterfall’ development is just about the most frustrating thing ever, especially if you are waiting on others with differing priorities to yours. Agile is a deep breath of fresh air in comparison.
I find the comments about software development in general eirily similar to the stuff we say about health: horrifically complex, the problems and costs virtually uncontainable, etc etc.
The article highlights the trouble that emerges when agile approaches go mainstream. Agile solves one problem - that of bureaucracy crippling software development. But all the other problems remain!
I’ve noticed software development is often a challenge because we have two levels of ambiguity we’re struggling with - first, the business’ understanding of ‘what they really really want/need’ and the ability to articulate it in a form that provides requirements and second, the pace of change.
Waterfall seeks to disambiguate all requirements early - Agile seeks to disambiguate iteratively, accepting the cost of change for the benefit of meeting changing needs.
(and ambiguity is also what makes the health system complex, we need the ambiguity to operate with heuristics in non ‘simple’ cases, as rigid rules don’t necessarily deliver the outcomes we want because … humans are complex systems!)
Waterfall works when the pace of change in requirements and environment is slow and/or consequences of failure are high. (e.g. nuclear power plants, definitely waterfall is preferred IMHO!). Sometimes it is good - horses for courses. For stakeholders with mature, well known and stable needs and an experienced delivery team this can work well, and be really efficient.
When we are facing ongoing changes in business needs and/or the business/tech environments, then agile works better - delegate a person to be the ‘product owner’ who manages the change and prioritisation in the ‘what they really really want/need’ space, and feeds the development effort with the highest priority needs (user stories), and help the stakeholders to develop their understanding and approach on the journey.
That said - a clear view of the end game (and how it is changing) is required in either approach 