We do Scrum, but…
“Scrum is just Waterfall in disguise”
Are you serious? — episode 9
Some people claim that Scrum is Waterfall in disguise. But what do they mean with this? In which context do they make this assessment? What practices of Scrum do these people criticize? I believe there are multiple layers here. And I think I can discuss a lot of them by taking my journey in understanding Scrum as an example.
I have been part of projects that followed the following structure to deploy new functionality:
- A Business Analyst created the Business Requirements.
- Then an architect created a High-Level design.
- The High-Level Design and Business Requirements were used to determine the amount of work required and as a result budget required. The Project Manager could now write the Project Plan.
- When the plan was approved the work was sliced into stories that could be picked up by the Scrum Teams. Based on the velocity of the teams it could calculate how many Sprints it would take to deliver all the code.
- The Scrum Teams would now work on the code and the Project Manager would regularly request for updates and then report this to the steering committee.
- At the end of the development phase, there would be QA Sprint to test the code.
- When QA was completed a User Acceptance Test was conducted.
- Lastly, the code was deployed to production.
To tell you the truth: I managed these kinds of projects. We said we used Scrum. And we believed it. We had a Scrum Master and a Development Team after all. Some teams even had a Product Owner! And the teams were able to self-organize!
Sure, it took very long to deploy something to production (which equalled everything in the scope of the project) and we had delays on top of that. Not to mention all the issues with changes to the scope that led to a lot of rework. And then, when we got it deployed, we got the avalanche of additional work of things forgotten or misinterpreted.
You could say that this is an extreme example. That can be, but I lived in this world! We truly saw Scrum as a means to help us manage projects. This practice has nothing to do with Scrum. We didn’t even have true cross-functional teams! Developers and QA didn’t work together despite being on the same team.
So we decided to tackle that. Developers and QA’s were working together to get something completed. We established cross-functional teams. Not only in name, but also in daily practice.
But still, we worked on items for several Sprints before we delivered something. This also has nothing to do with Scrum. People that believe this is Scrum are wrong.
This is the moment where we decided that we would embrace Scrum. We dropped traditional project management and instead adopted true Scrum to deliver software. We invested time to teach everyone in the organization about Scrum. Management needed to change their style towards servant-leadership. And we made sure we had a Product Owner for every product and a proper product backlog.
We also made the move towards smaller items that we could finish within a Sprint. We sliced a product into quite a several stories and then prioritized them. We inspected every Sprint if what we delivered was in line with expectations: we introduced empiricism (transparency, inspection, adaptation). We still did create road-maps based on the average velocity which resulted in having a deadline for the project.
This is still Waterfall disguised as Scrum. Slicing the stories upfront (Big Design Upfront) and mapping them into a road-map is just that. This is not fully adopting empiricism.
We decided to tackle this as well. We did NOT slice all stories upfront but worked on one epic at a time, creating value as of the first delivery. We still communicated expected end-dates, but now as a forecast. Based on the expected number of items to be delivered and historical data on throughput we could determine possible end-dates with a probability. We would say: there’s a 50% chance that we deliver February 2nd and an 85% chance to deliver March 2nd.
This solved a lot of our problems. But we still had to deal with issues during a Sprint. A story typically was picked up by a developer who created the design, then someone created the code, another did the review, then we did QA. QA was always struggling at the end of the Sprint. You can argue that we did mini-Waterfall inside a Sprint. This is not an optimal situation. You may wonder if the team is taking responsibility for the items as a team. There are several ways to tackle this:
- A team can decide to work on one item at the time. The whole team is focusing on this one item to complete and when done the team moves to the next item.
- Test-Driven Development or Behavior Driven Development can enable the team to work closer together and has many other benefits.
- Pair Programming and Mob Programming are techniques to work together.
Bottom line
When someone says that Scrum is Waterfall in disguise than this can mean many things. More often than not it is referring to anti-patterns while working with Scrum. It is very important to note that Scrum:
“is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.” — SG
This is as far away from planning and designing upfront as can be. Planning more than one Sprint ahead comes with significant risk as you normally don’t know what you will stumble upon that would change your insights. There are ways to project timelines, like probabilistic forecasting. These do however approach delivery date totally differently than classical planning does. For more info here is a piece about probabilistic forecasting:
Scrum Teams are self-organizing and cross-functional. The teams determine how they are going to create a working increment. There are best-practices though that focus on working together on an item, owning an item to avoid teams from falling into the trap of mini-waterfall within a Sprint.
