You most certainly saw pictures like the one above contrasting agile and waterfall, and maybe was even left wondering if it’s one versus the other. But I’ll tell you, agile is not the opposite of waterfall.
The reality is they are just different. And while agile has gained a lot of ground in all possible businesses and industries, it doesn’t make waterfall a villain that should be banned from the face of projects and products.
In fact, in some situations waterfall may still be applied with a lot of success.
In this blog post I want to talk to you about how it’s unhelpful to contrast agile and waterfall and what can help you be more effective instead, recognizing the strengths of each approach and, more importantly, focusing on the real issues your teams and departments might be facing.
Useful waterfall
Waterfall is an approach best used when there is stability in requirements, and it places importance in strictly defined sequential phases. Suppose you are climbing a staircase with 5 steps; you would only move to step 2 once you are absolutely sure all that needed doing in step 1 is completed.
That is an important concept of waterfall: the phases. They usually signal something important for a business, a department or even for budgeting. For example, suppose you have a step of requirements and research before you go into development and production mode.
In this case, you could only proceed to developing a product (and it could be software, pharmaceutical, a book, etc.) once the contract is approved, a health or security check is cleared, or once you secure a budget.
Those are gate phases, and they are significantly important in some businesses, and it is possible that even though your software is developed in agile, the whole research that led to it even being approved as a product is not.
Some tools that we used in waterfall such as Gantt charts to control the timelines and impact of delays, green light-red light can still be adapted outside of this approach.
While some people complain about Gantt charts, for example, that sort of visualization gives a bird’s eye view on deadlines, dependencies and the project as a whole. It shows how changing certain pieces of the plan can have a significant impact on the product roadmap. And that, my friend, is a golden element for stakeholder feedback.
Projects and waterfall
Waterfall was available since 1970s and was very popular up till the 1990s with some many large-scale and complex implementation of ERP products such as SAP, PeopleSoft etc. It was also very much at the heart of how PMI would describe project management.
But even that has changed. Did you know that PMI now holds a very different approach for project management, focused on value delivery, navigating ambiguity, and change and adaptability? You can read more about it here.
While a view product is dominant in agile, projects still exist and instead of debating nomenclature, it can be useful for you to familiarize yourself with the new approach most project managers know. I find with the new changes, the gaps on both tools and mindset are starting to close.
Now does anyone still use waterfall?
Yes. Even though we see health care, government and other heavily regulated industries coming to use agile, some sort of waterfall is still used.
Think of the pharmaceutical industry generating a new drug. Several rounds of trials are required before a pharmaceutical product is approved for mass production and human consumption. There are approvals and checks that you must do before proceeding to the next phase. You can’t burn stages as safety is non-negotiable.
But in each phase, it’s less rare to use agile within.
Why use agile?
When you can’t rely on a long-term plan, that is, when instability and change are rather common. And that can come from many fronts, such as quick pace of the market or constant change in technology. Fast adaptation for business and products is basically what the word means: agile = quick to pivot.
When you want to have better stakeholder engagement. You want the people who ask for things to be produced to be present, to give their feedback constantly, and to help make the decisions about how to move forward.
To reduce risks and increase quality with smaller and frequent delivery of whatever it is that you do. Reviewing and changing smaller pieces is more responsive than going through a monolith of a product later on. It’s not only more difficult to change big things, that difficulty translates into higher cost for change.
To create more capacity for a faster response. Whenever anyone in a project or team understands the full picture, instead of a single leader or manager dictating what happens, you have multiple heads and hands on deck, being able to offer a change, a fix, and an improvement at any time. Collaboration is not for a “kumbaya” type of thing; done right, collaboration is a tool for speed of response.
We could go on, but I’d like to bring your attention to something else.
Unhelpful agile
The more we explore agile, the more we see industries even in healthcare and aerospace territory blending it to waterfall or using mostly agile approaches. So, I’d say it’s becoming harder and harder to find an industry that isn’t at least curious at trying some agile approaches.
Any time you would wish for faster delivery of value (not necessarily fast speed of development) agile is a good candidate. And agile benefits intensify when you can’t possibly know all your requirements upfront, such as when you want to go for a break in the market before anyone else. You have to develop a bit, show it to customers, and go from there.
Now, the one thing to pay attention to is that in desperation to “be agile”, you may find companies that do the so called Zombie Scrum, or that use new names for old approaches. That confuses their enthusiastic teams that are willing to try something new, but it also frustrates everybody else, because now they don’t commit to this new way of thinking, yet the “old ways” seem to be forbidden territory.
Another anomaly, you still find “business teams” doing discovery, design thinking and whatever else they need closer to the customer, while production and development teams continue to receive a bill of requirements. These might be more relaxed than the older requirements use cases, but we still see the people who actually create the product far removed from the people who seem to want it: the customers themselves. Business an technology still work separate in many organizations. That’s an antithesis to agile approaches.
And worse: while most organizations are ready and used to seek metrics and accountability on production and development because of their waterfall history, very little exist on the business side. Even when a project is delivered on time and with quality, what if no one is truly buying the product? Are the business folks who prioritized this instead of something else held accountable for the lack of business results and benefits realization?
And those are just a few examples, but we could still talk about forcing people to misunderstand collaboration as working closely together all the time. And doing so while lacking a clear direction. That forces a lot of misplaced interaction, amplifies misunderstanding, and definitely frustrates people.
Agile at any cost and agile just for show are two big flavors from this current FOMO (fear of missing out) of “going agile” because everybody else seem to be doing it.
My take? I call it messy agile, and it is where most agile coaches find themselves these days. And that’s why you find frustrated teams, skeptical employees, and a tough space to navigate change. But if you buy into the whole comparison between agile and waterfall, messy agile will lead you to the next point.
Comparing agile and waterfall hides the real issues
Help people see agile is not the opposite of waterfall, early on. Honor people’s past on their waterfall endeavours, which might have been quite successful. Don’t let messy agile spread. Here’s what I mean by it.
Time comes to plan for the quarter in most companies. And in doing so, everybody estimated everything to the best they could. Yet, nobody even seems to take a look and see that capacity-wise, the goals seems rather bold and ambitious, and it will not fit the quarter.
This misstep has nothing to do with waterfall. If this was waterfall, capacity and dates would play a role from the get-go.
Now, say it’s time to “go agile” in the quarterly planning. The quarterly plans are still bold, and it all seems easier now because everything is in story points. Yet, once again, no talk of capacity. And that, my friend, is not agile.
See what’s happening here?
If you get hung up on the agile as the opposite of waterfall you’d be missing the real issue for this company and miss the opportunity to help them make a change that brings the biggest impact.
And what would that be?
The real talk about capacity. How to measure capacity. What they even understand by capacity and what they want to do about it. How will they be using that in planning and in assessing progress? And the talk about capacity will always bring in the conversation about priorities. And that you can’t have 10 priorities, as it’s even against what the name says!
Not addressing that is going blindly into “agile transformations”. This is neither good waterfall nor good agile. It’s maybe what some jokes call “frAgile”.
Is there a verdict?
It’s all a matter of applicability of approaches. In high certainty waterfall will still fare great. In high volatility, agile will work better.
Is agile gaining more ground? Most certainly.
And here’s something else. You might not necessarily see “pure” waterfall out there anymore. Even when people claim they work in waterfall you’ll notice they are adding tools from the agile space, such as stand-ups or sprints leading to milestones.
And you will continue to see a lot of those mixed approaches as companies try to find their own thing. And that’s good!
It gets even more interesting as they add systems thinking, theory of constraints and other useful thinking tools to truly see their problems holistically. Recipes are being abandoned in favor of flavors that suit the organization uniqueness and talents.
So, the whole agile x waterfall thing is a moot point. Agile is not the opposite of waterfall. And in fact, if you think about it, agile continues to evolve as well.
The best thing an agile coach could do?
Effective agile coaches act precisely here, in the space of creating awareness and revealing the unaddressed issues. And it doesn’t hurt that they also bring in expertise on how to solve for those issues!
What do you think on the matter of agile and waterfall?
