Don’t Let Your Agile Sprint Become a Mini-Waterfall Project

By David Hawks | Dec 13, 2017 |  Scrum,  Team,  Video

Scrum sprints can be tricky. Agile teams often fall into the trap of turning their Scrum sprint into a mini-waterfall. In other words, they take on work and save testing until the end of a Sprint, which tends to create more carryover than truly done work. Learn how to combat the mini-waterfall pitfall and save your Scrum sprint by swarming as a team, breaking work down, and tasking effectively.

David Hawks lays out his tips and tricks on escaping the mini-waterfall and achieving “Done Done” as a team in this video. Read more about mini-waterfall warning signs with our article, Your Sprint May Be A Mini Waterfall If… (…)

Video Transcription (has been slightly edited for brevity and clarity):

Mini-Waterfall, A Common Problem

Hi, my name is David Hawks with Agile Velocity, and today I want to talk to you about a common problem that we see with Scrum teams. The notion is that we don’t want our sprints to be a mini-waterfall. And we see this a lot. Let’s say we had a team that was 4 developers and 2 testers. We planned a sprint and pulled 4 user stories into our sprint. We’re doing a 2-week sprint and over that 2 weeks, we’re trying to get these 4 user stories done. The common trap that teams fall into is they have user story1, user story2, user story3 and user story4—what’s the most efficient way to assign this work? They say, “we’ll assign developer 1 to take the first story. Then developer 2 will take the 2nd story and developer 3 will take this story.” Developers kinda like this because developers don’t really like people—kidding—but developers like to go off and work and knock something out and put on their headphones and get something done. It’s kinda nice to be able to say, “I’m gonna go work on this, they’re gonna go work on that. I’m not going to be interrupted for eight days. At the end of the 8 days, I’m going to throw it over the wall to my QA person. QA 1 will take 1st two stories and QA 2 will take the 2nd two stories.”

How do you think this will end up at the end of this sprint? QA starts working on this and finding bugs and gets to the end. What are the chances this will carry over and not get everything “done done”? Will we have all the bugs addressed in this sprint? There’s a high likelihood that we will end up carrying over some of this stuff. If we look at a burndown chart for this sprint of stories complete, it would be flat until the very end and maybe we get something signed off and maybe we have a gap of not getting everything done. So while this is better than working on something for 3-4 months, the idea here is that we are shrinking it into two weeks which is better, but this isn’t how we want to work.

How to Avoid the Mini-Waterfall Trap

This isn’t what we want teams to do. We want to get teams out of their silos and into more swarming. In order to swarm, we have to break down into smaller chunks. We might want to break User Story1 into UserStory 1A, IB and IC and figure out as a team how to task this out into small parts where developer 1 and 2 work on that. How can we get testing involved earlier? Maybe it’s automated testing? What can we do to get it done earlier so that we can get something signed off earlier in the sprint not waiting for the last day? Which means we might have a swarming with developers 3 and 4 and QA 2 on something and trying to get it done. The question we’re challenging our teams with is what would it take to get something singed off by like day 3 or day 4? Then we’re going to continue to work on smaller things along the way but we’re swarming. We’re trying to get as many people to get user story 1 as a whole signed off, how can we do that? In our burndown chart, we’re seeing a little bit better progression throughout our sprint and reduces our risk of finding everything late and running out of time and gives us better predictability throughout our sprint. it also reduces the risk that the highest value item will carry over and reduces the risk of carry over all together.

That’s the challenge that we’re trying to push our teams to: How do you get out of a mini-waterfall? The skills here are how to break work down, how do we task and how do we swarm?  Hopefully this will help you become more successful with scrum.

2 Responses to “Don’t Let Your Agile Sprint Become a Mini-Waterfall Project”

  1. randall

    The whole problem with scrum and with the scrum consultants is that neither takes into consideration how businesses work (news flash! developers work for a company with business goals and requirements), how developers work or basic human behaviors. The concept of “swarming” is great for certain problems but many code bugs and changes are easily done by one person and assigning more people to the problem just to create “swarming” or force people to team on a simple problem thereby taking longer. Also there are a lot of human nature considerations (eg. types of personalities, experience level, educational background, etc.) that scrum does not take into consideration. Its just “do it this way and you’ll be great”, nonsense! I trust scrum consultants about as much as I’d trust the Fox guarding the chicken house! Both have an interest! Finally, scrum consultants are “dreaming” if they think developers can decide what to work on and how much work they will take on. Management decides based on business needs. That’s business folks! Yes scrum has created mini-waterfalls with huge meeting overhead. Our daily “standup” lasts 45 minutes with people giving very detailed status – basically justifying their time for the last 24 hours. Its that way everywhere I have worked. Scrum is not a “one size fits all” solution. I can see its benefits for certain types of projects and teams but ALL COMPANIES are using it for ALL projects because they can micro-manage the developers and pressure them with daily status reports and very short measurable goals. I cannot take training or have time to try something new because I MUST complete the amount of “story points” expected.
    Most of the scrum masters and scrum consultants I know the history of, have not done development work for at least 10 years if ever. Most are people who worked a couple years as developers then jumped to “project management” to make more money. They really don’t understand the needs of developers to produce. They are just metrics gathers and extensions of mid-management.

Leave a Reply

Your email address will not be published.

< Back