Agile Waterfall
At a glance, I could be talking about a very weak waterfall prone to going away over a missed rainfall, others would consider two distinct methodologies where one is reminiscent of old school software development and the other being some hip cool way to rapidly get stuff done.
Either way; I happen to hold the opinion that although both meanings are different; they are the same.
As many in our field are commonly asked – “What is Agile?”, “What is Waterfall?”, or “When should one be used versus the other?” etc. I’m sure we’ve all had some question like this that then has a few answers depending on the audience. There are several resources all over the internet regarding both; therefore, this article won’t dive into either since there are greater minds that regurgitate the text book definitions. I’d like to take the time to explain a missing topic that’s not usually discussed within that research.
For executives; I normally default to an overly simple explanation that Waterfall is almost always used at the executive level to handle budget and marketing timelines and cross departmental planning – essentially meaning that regardless of how “Agile” your development team is; you still need to plan everything out, develop a budget and KPIs then get some sort of approval. At this level; Agile is more about the ability to provide a set of tools that provide visibility into the project which can drill down to help understand group efficiency. Therefore culture will determine more about what to use and your management style must adjust to which is appropriate.
My understanding is that Agile was born out of inefficient manufacturing practices that caused delays and missed opportunities for automotive manufacturers (Waterfall) while Toyota developed a process that abstracted numerous processes and components which thus allowed for delay on certain commitments thus providing the ability to easily pivot from one thing or another up to the latest moment to release (Agile).
This makes it obvious that the focus for Agile should be about the architecture and not necessarily the implementation details. In software development; it’s more important that the architecture be Agile than that the team follow Agile practices. Every design should be done in such a way that each dependency is abstracted from the core and decoupled. A savvy reader may understand this as Micro-service architecture – and yes – that’s one name for something like this; but it’s about taking something very large and breaking it down to smaller parts and creating a layer of abstraction between each part where that part serves its own function or purpose.
This doesn’t diminish Agile practices; they are critical to helping to motivate the modern development team and provide tools for communication and visibility, but it’s important to appreciate that you can fully operate under waterfall and still develop the architecture in an agile way that supports rapid adoption of new market requirements. As tech leaders; we need to identify what makes operational sense for the organization and properly architect an agile solution using whatever practices fit within the organization culture.
The team following the best agile practices or a strong well developed waterfall model that will meet all customer demands at release - without an agile architecture – will still be prone to going away over a missed rainfall.
