Waterfall: A Primer for the Business Leader

Given the importance of taking an optimal approach for the type of work, it is important to understand what agile, lean, DevOps, and waterfall are and their history. People, historically, have spent very little time thinking about or improving how they do what they do. This is the third in a series of posts adapted from the book Sooner Safer Happier addressing these different frameworks.

What is Waterfall

Most large, old, traditional organizations either used to take, or still take, a waterfall approach in the context of unique change. The word “waterfall” is used as there is a sequential, stage-gate process, where work is completed at one stage before flowing to the next stage and so on. It is one-way, with big batches of work passing by job role. There is big, up-front planning and design, predicting time, cost, scope, and quality at the point when there has been the least actual learning. There is change control on the plan that inhibits agility. “Scope creep” occurs (because people are discovering the unknowable as they go) and is inhibited. Time to value is typically measured in years. The focus is on achieving a predetermined plan rather than on early and often learning to maximize value and the outcome—or to stop working on it early and move on at the lowest cost of failure.

There is sunk cost fallacy (“We’ve invested $100 million already. We can’t write it off. Let’s keep on going.”). Learning is late, with a high-stakes, big-bang implementation and a large impact radius. Late learning delays the realization of value and reduces the likelihood of maximizing value. It also significantly increases delivery risk, back-loading it to when there is the least time to respond. People end up cutting corners to hit a predetermined “deadline” or feel demoralized at slipping the plan (which in reality is the gap between what is knowable and what is unknowable). The later the learning, the higher the probability of being wrong and the higher cost of being wrong. By the time something is delivered, the world has moved on. “IT doesn’t move as fast as the business” is a frequent comment associated with waterfall change delivery.

Engagement is low as employees don’t get to see the fruits of their labor adding value until much later, if they are lucky. People are stuck in role-based silos, with no feeling of or actual end-to-end accountability. People are promoted and incentivized within their role-based silos, leading to finger pointing. “It’s not my problem. I did my bit. The hole is on their side of the boat.” The problem with big-bang, waterfall failures has been described as “the application development crisis.”

Applying a waterfall approach in the context of unique change is a thinking error. It is miscategorizing emergent work (unknowable) as deterministic (knowable). It is taking an approach that came about in the context of manual labor shoveling iron ore or building dam number 57,001 (tasks that have been done sufficient times before to be knowable) and applying it to unique product development (which has never been done before and is unknowable).

In the same category as waterfall is water-scrum-fall. While it is a slight improvement on a fully sequential, stage-gate process, it is not agile. It usually manifests as a waterfall project with big, up-front planning and big, up-front design, the word “sprint” ten times in the middle of the gantt chart, the work for each “sprint” having been pre-planned, and then late learning with big-bang testing and implementation. It does not exhibit agility and does not optimize for outcomes. It is still applying a deterministic mindset to an emergent domain of work.

Winston Royce, one of the first to document the waterfall sequential process, wrote in 1970 that “the implementation described is risky and invites failure.”

When considering the optimal approach to the type of work, it’s not about agile or waterfall. It’s about agile (unknowable, unique) and lean (knowable, repetitive). Waterfall is “Think Big, Start Big, Learn Slow,” for which, in my opinion, there is no excuse. Why would you not optimize for early and often learning, continuous improvement, and the ability to pivot for unique change in order to de-risk and realize more value sooner and improve outcomes? Even construction has adopted agile and lean principles and practices.

As we’ve seen, to deliver Better Value Sooner Safer Happier, it is important to apply the optimal approach to the work based on the type of work.

In the next post, we’ll take a look at the Cynefin framework, which is a helpful way to frame this question.

- About The Authors

Jon Smart

Jon is co-founder and CEO of Sooner Safer Happier. Jon is a business agility practitioner, thought leader, and coach. Jon has been an agile and lean practitioner since the early 1990s. Jon helps large organizations deliver better value sooner, safer and happier through better ways of working. He is the lead author of the award-winning and bestselling Sooner Safer Happier: Patterns and Antipatterns for Business Agility.

Follow Jon on Social Media

• 
•