Being a history buff, I have been travelling extensively in Eastern Europe in the last few years and always take the walking tours of the cities I visit. Every single tour I have been on sounded like scripted liberal propaganda on socialism — as if nothing good has ever come out or will out of the idea of socialism. Meh.
This always reminded me of…
Waterfall has become socialism for the millennial tech generation — the catch-all term to absorb all the blame; while Agile being the magic cure for all ills.
Like every other thing in life, there are pros and cons of both Agile and Waterfall and the text-book Agile religiously promoted as a dogma post the dot com boom does not and will not work for every situation. There are plenty of things we can learn from Waterfall — after all, it did steer the rise of hundreds of technology products and projects for half a century before the Agile gurus started preaching it was stupid to use it.
No software development methodology is a panacea — they are all based on some underlying premises, that is not correct in all circumstances. The waterfall is still appropriate for some projects and can be applied to pretty much all projects with lessons learnt from its failures and success of Agile.
An example when a variation of Waterfall will work better than Agile is if there’s a need for a firm commitment to deliver a defined scope by a specified date or when you have geographically distributed teams (*bins the no documentation in Agile nonsense*). Someone tell me how do you collaborate and communicate with teams in different timezones without documentation?
It is impossible in many cases to adopt textbook Agile methodology. Take corporates, public sector, regulated environments as an example — where you have a solid need for cost and schedule accountability. No board-room is going to listen to this nonsense that we are building something, which we don’t know how long is going to take so just keep funding us and we’ll see when we finish and what we end up with.
For about two decades now, Waterfall has been labelled rigid, inefficient, simplistic and simply obsolete. While countless models have been devised, and they all promise efficient development — some form of Waterfall still sticks even in the hardcore Agile organisations because some of it simply works and is the only practical option. If you ask any technology professional, they will dismiss Waterfall but I see this more of a fashion statement. It has just become difficult to speak in favour of Waterfall and not sound like an outdated technologist unwilling to embrace change and efficiency. On that, kudos to the Agile gurus and coaches (they have built a whole industry out of it) for super marketing!
Don’t get me wrong, I have no beef with Agile, I quite like it infact — my problem is with making it a dogma and the sermons of its preachers as a cure for all technology ills.
The modern interpretation of Agile as promised by the gurus is to deliver more code, more testing, more requirements and all of that quicker to the user — the problem I see is that while it promises efficient development, but the cost is effectiveness. Too many times in the last ten years of my career I have seen Agile teams build and deliver ill prioritised features just to be quicker without delivering what is more valuable because it will take longer. Waterfall has clearly taken a serious black eye from Agile zealots, but traditionalists still cling to it. I am not into predictions but the rise of Waterfall or a variation of it is not too far because it just works for many projects especially incorporates and enterprises.
With that, I present you my personal interpretation of Agile Manifesto spiced up with my picks from Waterfall and I call it Agile in a Waterfall framework — it embraces change and uncertainty driven by Agile, but allows for structure and comprehensive documentation to make it suitable for medium to large size organisations. Then I also add some tarka (tempering is the English word, but doesn’t do justice) of Spiral SDLC and you have the magic flavour. Let’s explore this in more detail in my next blog.