Scrum by Example – Is Your Scrum Team a Victim of Scrummerfall?

February 27, 2024 by Mark Levison Leave a Comment

Is your Scrum team struggling with questions about who owns quality? Is testing way behind development? Are team members claiming no time for retrospective because they’re focused on delivery? They might be victims of what some call Scrummerfall, or Mini Waterfall. Let’s use our fictional World’s Smallest Online Bookstore (WSOBS) Scrum team to explore what this Scrum anti-pattern is and the damage is causes.

Analysis

Some team members have completed their work for this Sprint so they are working ahead on the next Sprint. Great, right? No idle workers, and all that. The organization is all about speed, and the team all need to be seen being busy.

Except it’s the exact opposite of great. Because while our developers moved on, the testers can’t get everything tested by the end of the Sprint. So starting the next Sprint, they’re still testing the last Sprint’s work. The Product Owner is scrambling to stay ahead of the devs and still keep up with the rest of their responsibilities. On top of all this, the team is being pressured to “maintain” velocity. Even worse, the Sprint Review becomes a fiction because, instead of reviewing completed work that can be delivered to stakeholders, the review is of partially completed work that will have unknown defects.

The simplest thing to say is that this resembles a mini waterfall. However, that doesn’t help our team. In practice, the team have created what’s called Scrummerfall.

Why is Scrummerfall (or Mini Waterfall) in Scrum a problem?

First and foremost, because quality suffers in Scrummerfall. The longer the time span between finding a problem and fixing it, the harder it is to fix well. When a defect is found with work done in a previous Sprint, the developers might be reluctant to go back and fix it right away, claiming this is slowing them down. This is especially bad in an environment where teams are focused on velocity. The bug was already hard to fix because it was found later, and delays in fixing it just make the problem worse.

Handoffs harm quality (e.g. from BA -> Dev -> Test). Every handoff from one person to another causes a loss of information, which increases the likelihood of a bug.

Working ahead of the rest of the team also affects cycle time. Cycle time is the time from when work is started on an item to when the customer gets the value. In the case of our Bookstore Team, this is going to be at least two Sprints (4 weeks), because items are delayed waiting for testing and aren’t truly ‘Done’ and deliverable.

And that’s even assuming that deployment is instantaneous and there are no defects – neither of which is likely to be true. Cycle time matters because it is what the customer sees. They see the team has started work on the item and they see when they get the item. They don’t care what order the work was done in or who did which part. They care whether or not they waited an eternity and if their feature works as expected on delivery.

What Causes Scrummerfall?

How did our team end up doing this Scrummerfall version of Scrum to begin with? This is where, if you dig down, you’ll find the underlying issues (Hint: this is the Start of Systems Thinking which we cover in our A-CSM). In this case it often stems from a mindset issue within the organization:

• An assumption that Scrum is like the traditional approach, only faster.
• An adversarial relationship between development and test.
• A focus on throughput or velocity above all else.

Assuming we agree that Scrum isn’t just the traditional process done faster, we need a better approach. What is a more effective way of working?

Better Ways to Work Than Scrummerfall

• Introduce Cycle Time as a measure so we can see what we’re improving. In the short term I would expect the Bookstore Team to focus on reducing their cycle from 4 weeks to 2 weeks. This is guaranteed to reduce their velocity. Since velocity is a dangerous measure and often not even a good forecasting tool, we need to wean people from its use. Cycle time is a better measure because it challenges us to optimize getting the value to the customer sooner.
• Consider another measure like “Defects that Escape the Sprint” as being a proxy for quality. This will help us understand what happens to our quality over time. Our eventual goal is zero defects that escape the Sprint. Even if we never get there, it challenges the team to focus on quality over nominal speed.
• Reset the relationship between Dev and QA. QA isn’t trying to find bugs, so their performance shouldn’t be measured by the number they find. QA is trying to prevent bugs. Many teams have an adversarial relationship between Dev and QA because they see it as critiquing and looking over the shoulder of each other’s work.
• Encourage collaboration. Since QA, Dev and BAs are all attempting to build the best quality, they should start the Sprint by collaborating on getting the detailed acceptance criteria for the User Stories, with a strong preference for examples (aka Behavior Driven Development). They might even pair-program with the Devs to create automated tests for the acceptance criteria. Collaboration on acceptance tests, BDD, and test automation are all longer term steps that increase quality. As collaboration becomes more natural, it would be a good opportunity to run a cross-skilling workshop.
• Encourage cross-skilling. As team members start to collaborate more, some cross-skilling will start to happen naturally. You can’t help but learn more about other disciplines when you spend time working together every Sprint. Cross-skilling strengthens relationships and morale, and significantly reduces bottlenecks.
• Support the team to grow into Pair-Programming and the whole host of other Agile Engineering Practices.

Scrummerfall happens when team members stay stuck in traditional patterns and roles. Scrum (and all flavours of Agile), expects us to continually reconsider how we work and ask what small changes we can make next.

When some or all of a Scrum team goes to the Scrum Master and resists the basic framework of Scrum, don’t force the issue. Instead, use it as an opportunity to look deeper for what’s really happening. If you find problems like the team feeling they have no time for a retrospective or no interest in holding one, don’t solve the surface problem by canceling or replacing the retrospective or, much worse, forcing them to attend. Instead, dig into the why to find the deeper problem.

The Scrum framework leaves a lot of wiggle room to adapt it in unique ways to best suit your own team’s needs. But don’t abandon the basic structure (like retrospectives) when something isn’t convenient. All of the Scrum events serve a critical role in the overall effectiveness of Scrum.

Related: 
Scrum by Example – The Story of an Incomplete Sprint
Quality Assurance in Scrum