A Tester’s Guide to Dealing with Scrummerfall
If you’ve been a tester on an agile team, you’ve probably experienced “Scrummerfall” behavior—a cross between Scrum and waterfall.
You can actually tell in sprint planning. If the developers are planning larger tasks that take nearly the entire sprint to complete, then you’re probably in Scrummerfall. You’ll hear lots of grousing about the complexity of their work and how it can’t be broken down any further.
There isn’t really any collaboration. Developers grab their stories and tasks in the beginning of the sprint, and the testers grab theirs. After that, it’s every man for himself. If you’re lucky, you’ll get something to test when the tasks are 80 percent complete. If you’re unlucky, you’ll need to wait until the very end, which usually butts up against the end of the sprint. The developers consider their part done, then they throw the work over for testing.
Another indicator of Scrummerfall is too much work in progress during each sprint. Each person in the team might pick up a user story and be working on it separately. This sort of individualism is very counter to the work alignment we want to encourage in agile teams.
What can you do?
First of all, you need to point it out to your team. I’d start by pulling aside your ScrumMaster or agile coach and telling them about the behaviors you are seeing. Try to determine if they think it’s problematic, and, if so, ask what they’re trying to do to improve the situation. Don’t do this in an adversarial way, but instead as a partner. Speak in terms of what you can do to help them influence positive changes in the team’s behavior and workflow.
Another approach is to bring up your concerns to the team in your sprint retrospective. This might require a bit more courage than the last idea, but you will be taking a more personal approach. Speak in terms of the impact to the team, to the product quality, and to the team’s agile value commitments. Don’t individualize it or make it personal to any one team member. It also can be powerful if you speak about the personal impact the lack of collaboration has on you.
To be frank, probably my favorite approach to minimizing Scrummerfall-type behavior is—ta-da—planning. I know what you’re thinking: There is little to no planning in agile teams outside the product backlog. Well, I sort of disagree with that. I think the sprint planning meeting is the ideal place for Scrummerfall to be avoided, because this is where it’s inherently created.
You see, Scrummerfall is not an accident. It’s intentional. It’s planned for. It’s the way the team envisions executing the sprint from the very beginning. That is sort of sad, but it also illuminates some good news: If you can plan for it, you can also plan against it.
