Waterfall to Agile Transition Challenges: Combating Scrummerfall

Many are still struggling to grasp the concept and learn the ways of agile. It’s a common trend for companies to fall into Scrummerfall when transitioning from Waterfall to agile testing contexts. Zenergy’s agile experts, Bob Galen and Shaun Bradshaw discuss ways to combat Scrummerfall, as its behaviors are risky and can potentially set up sprints for the entire team to fail.

“There is a natural Scrummerfall that happens in agile testing; for example, testing doesn’t happen on the first day of the sprint before you’ve written any code. There’s little, mini waterfalls that are natural. The problem is – not letting them fill the sprint and deferring testing till the last 2 days of the sprint.” – Agile expert, Bob Galen

When working with an agile team transitioning from Waterfall, Shaun warned them to take caution and not to fall into the rut of Scrummerfall. An example of this would be if a team were to do a 2-week sprint focused on requirements, a 2-week sprint focused on design, 2-week sprint focused on development, and a 2-week sprint focused on testing.

In efforts to implement agile into this organization, the correct way, and help the team move away from their Waterfall habits, Shaun had asked the team divide up the tasks for the next sprint. The ending result was a list of tasks which were further divided into the silos mentioned previously (requirements, design, development, and testing). Yet, another prime example of Scrummerfall; which sets the sprint up so that each individual silo’s tasks (i.e. design) must be completed before the next silo can begin (i.e. development) and that silo must be completed before moving to the next (i.e. testing). In this scenario, all the testing tasks are saved until the end making the entire process more time consuming, costly and potentially sets the entire sprint up for failure. In other words, in order to avoid Scrummerfall your goal should be to try to break down work and/or push some of the later tasks earlier into the sprint.

1. WIP Limits– limit your work in progress (this forces the team to complete specific tasks before moving to the next)
2. Lay out 2-week sprints– Start putting tasks up and then analyze where the tasks fall. Are your tasks overloaded in one area/or silo? Which tasks have dependencies on others? Can multiple people tackle or help each other complete certain tasks to help expedite the sprint?
3. Visualized Planning – encourage testers to speak up if they feel that they are overloaded in one area or know that they are “biting off too much to chew” within a given sprint. Once you learn your teams WIP limits you will be able to progress and increase the team’s efficiency. The point is to complete a sprint and complete it correctly – you won’t accomplish much by pointing fingers and blaming each other for not completing sprints on time. So, learn to bite the “right” amount.

>> Subscribe to Zenergy on Youtube for more videos