The Demotion of Scrum Into Waterfall

Companies compound methods and frameworks, and another waterfall is born.

We cannot deny how popular Scrum has become. It’s often the first choice of companies when they want to work with Agile frameworks. Almost everyone knows the Scrum Events and roles by heart. On top of that, there are more than a million Scrum certified professionals; 684K+ from Scrum.org and 400K+ from Scrum Alliance. With such an abundance of certified people worldwide, Scrum is an obvious choice. Curiously, we still struggle to benefit from true agility.

How often do you observe the following?

• Scrum teams focus solely on implementation and nothing else
• Product Managers define the right thing to do, and Product Owners ensure the thing is done right
• Developers aren’t involved in any step of discovery. They focus exclusively on the execution
• Developers long for well-defined requirements and high-fidelity prototypes
• Product Managers define what to do, UX researches, UI designs, and Devs code. Just like a factory, everyone is responsible for a small part of the product, and nobody cares about the whole

Although many companies strive to do Scrum, some things derail pretty fast. Instead of improving collaboration and benefiting from Scrum, teams fall back to a waterfall working mode. The result is Scrum only in name.

Please stick with me. I will elaborate on why that happens and what could help teams be more Scrumish and less Waterfallish.

What’s a Waterfall Approach?

For decades, software development has used Waterfall as the standard methodology. It’s similar to a factory, where everyone is accountable for a single part. Only once one part is finished can the next part begin.

The main problem of waterfall methodologies is assuming predictability. Unlike assembly lines, software development is unpredictable, and investing too much time upfront on a plan will inevitably generate waste. Beyond that, the time to market is too extensive, and learning from real end-users takes too long.

With waterfall, the longer the project, the bigger the problem becomes.

The following image shows typical phases when teams use a waterfall methodology. As you can see, disciplines were separated; the process was rigid, and each stage couldn’t start until the previous one had concluded.

Compared to a waterfall method, Scrum has many differences. The most relevant are:

• Self-managing teams: Scrum members organize their work towards Sprint and Product Goals. They don’t need anyone telling them what to do; they will figure that out independently because they have all the required skills to do the job
• Incremental delivery: Sprint by Sprint, the team strives to provide value to end-users and business
• Cross-functional teams: Scrum teams should have all the required skills to transform ideas into meaningful solutions

In theory, Scrum will help teams uncover hidden opportunities to create value. That may happen when the organization masters the Scrum game, which is often not the case. Teams often use a kind of “Scrum but,” and that’s when things get ugly and derail from what Scrum intends to achieve.

What’s Happening with Scrum Teams?

The most common and lamentable situation is using Scrum solely for execution. Scrum members evolve into factory workers shoveling coal to keep the machine running. They are unempowered to make decisions and must follow what was previously defined. Doesn’t that assimilate with waterfall? 

In my experience, organizations get excited about agile frameworks but slowly default to a waterfall approach. The following image shows what I commonly observe:

It’s comfortable to feel in control and waterfall methods give a false sense of that.

Unfortunately, it’s easy to misuse excellent methods and work as we used to four or five decades ago. All the methods mentioned above are great when the whole team collaborates and becomes accountable for the end result. But these methods will be pointless when different teams start handing over tasks to other teams.

What drives me mad is the assumption that Scrum teams should focus on execution and let other teams do the rest of the work. That’s the perfect way of creating another waterfall. Nowadays, a common scenario would be:

1. Product Managers, Business Analysts, and UX Designers work from the beginning of a product to create a business model and value proposition
2. As the business model is established, Product Managers and UX Designers run experiments to validate assumptions and learn from end-users
3. The learnings generated from experiments lead to the business model and value proposition changes
4. As Product Managers and UX Designers learn enough, a UI Designer comes into the picture to create high-fidelity prototypes
5. After all the previous stages, Product Managers handover execution to Scrum teams who join the party and start the implementation

The more handovers teams have, the more confusion they face.

Limiting Scrum to execution is a massive misconception, and that’s how Scrum becomes another waterfall method.

How Could Teams Be More Scrum and Less Waterfall?

Scrum is all about empiricism and collaboration. It’s not hard to understand. The problem is Scrum will only work well once teams can embrace uncertainty and are empowered. Until then, it will be just another “Scrum but.”

Traditional management believes that controlling and managing teams is how they avoid undesired results. The fear of uncertainty forces people to create processes and limit responsibilities. I believe the more processes you add, the more you restrict creativity.

Here are my learnings from the failures I faced:

1. Don’t limit Scrum teams to execution: Scrum teams will have no chance of succeeding when they follow a plan instead of solving problems that matter. Empowerment is key. Amplify the Scrum team’s voice by involving them in the entire process.
2. Use Scrum to produce knowledge beyond features: Cross-functionality entails the team having end-to-end responsibilities. Such responsibilities shouldn’t be shared between different groups. Teams should use their time to uncover opportunities and create value.
3. Don’t get obsessed with output: More features means nothing if you’re flying blind. Before getting busy writing code, you need evidence that it’s the right thing to do. More importantly, the same team should figure out the right thing to do and how to do it right.
4. Simplicity over complexity: Search for opportunities to make it simple instead of adding more complexity to your work. For example, instead of adding handovers, give the responsibility to the Scrum team, and empower them to deliver results.
5. Accept failure as a step towards success: Failing hurts; we all know that. However, when teams do everything to avoid failures, they also end up avoiding innovation. I believe failure should be seen as an inevitable step to creating something outstanding. Instead of blaming teams for failures, encourage them to move out of their comfort zone and learn from their mistakes.

“Failure isn’t a necessary evil. In fact, it isn’t evil at all. It is a necessary consequence of doing something new.” - Ed Catmull, Pixar Co-Founder

Final Thoughts

New frameworks are born when people get mad or frustrated with known Agile frameworks. Perhaps you heard about Shape Up, Scrumban, Lean Development, Crystal… the list keeps growing. The point isn’t changing the framework when things get hot, but stepping back and understanding why the framework doesn’t work. In my experience, the problem is often our mental models and not the framework we use. We easily fall back to known behaviors and transform Agile methods into a waterfall.

Waterfall methods should rest in peace; we should not revive them. 

I’ve come to understand that teams will have better odds of standing out when they:

• Aim for simplicity over complexity
• Focus on maximizing opportunities instead of minimizing risks
• Strive to solve problems instead of avoiding them
• Embrace uncertainty instead of trying to make plans to create an illusional predictability
• Have leadership empowering them to take ownership instead of applying command and control

“When it comes to creative inspiration, job titles and hierarchy are meaningless.” - Ed Catmull, Pixar Co-Founder

‍