What is it?

If you’ve been a tester in an agile team you’ve probably experienced Scrummer-fall like behavior. The challenge is to how best describe it. One way is to look at your activity chart. If on day 1-8 of a 10 day sprint you’ve been largely idle and waiting for code to “show up” for testing. Then on day 8-9, suddenly and magically everything arrives on your doorstep for testing. And you rush forward testing all of the teams’ output…only to fail to have sufficient capacity to get your job done. Then you’ve experienced Scrummer-fall.

Basically, it’s applying waterfall process behaviors within the confines of an agile iteration. On the outside, you’re agile. But it’s only a façade. On the inside your team is still subscribing to waterfall principles & behaviors, which means that testing is always done after the developers are completely done with their work and they throw it “over the wall” for testing. It also means that feedback, either on defects or functional acceptance, is occurring quite late as well.

Some Indicators

You can actually tell in Sprint Planning whether the team is scrummer-falling or not. If the developers are planning larger tasks, that take nearly the entire sprint to complete, then you’re probably in Scrummer-fall. You’ll hear lots of grousing about the complexity of their work, how it can’t be broken down any further, and how complex it is.

If you ask to test it during the work, you’ll be rebuffed. If you’re lucky you’ll get something to test when these tasks are 80% complete. If unlucky, you’ll need to wait until the very end, which usually butts up against the end of the sprint.

Another indicator is simple collaboration. There really isn’t any. Developers grab their stories & tasks in the beginning of the sprint and the testers grab theirs. After that, it’s every person for themself. Sure, you make ask if you can help the developers by testing during the sprint, but you’ll be rebuffed. The work usually collides during the final 1-2 days of the sprint. Usually the developers consider their part done—as they throw the work over for testing.

From a burndown chart perspective, it really shouldn’t burn down during Scrummer-fall as the work really doesn’t get ‘done’ until the very end. This back-end loading dynamic is very typical of the anti-pattern.

Another indicator of Scrummer-fall is too much work-in-progress (WIP) during each sprint. Again, I alluded to it earlier. If you have a team of 10 individuals, then each of the ten might pick up a User Story and be working it alone or separately. This sort of individualism is very counter to the work alignment we want to encourage in agile teams.

Simply put the individuals go back to their desks and do their work. No teamwork, no collaboration, and very little shared work or responsibility for each work item / story.

What are some things you can do?

First of all, you need to point it out to your team. I’d start by pulling aside your Scrum Master or Agile Coach aside and tell them about the behaviors your 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 teams’ behavior and workflow.

In the end, I believe it’s the job of the Scrum Master to reinforce solid agile practices and behaviors. And Scrummer-fall is NOT a mature practice. It’s a façade that gets in the way of true agile performance on the part of the team. So, partner with, but also put some pressure on the Scrum Master to address it. It IS an impediment.

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. When you bring it up, speak in terms of the impact to the team, to the product quality, and to the teams’ agile value commitments. Don’t individualize it or make it personal to any one person on the team. I also think it’s appropriate and can be powerful if you speak about the personal impact it has on you.

For example: Because the majority of the testing is only possible on day 8 of a 10 day sprint, I have to work 12-15 hour days in order to try and keep up my part of the bargain in delivering our sprint goal. While I don’t mind doing my part, this is clearly skewed and I’m struggling to sustain that pattern. Is there something the team can do to help me create a more balanced workload within the sprint?

I think that’s a fair discussion to initiate in the retrospective.

A final action starts at the beginning. And to be frank, it’s probably my favorite approach to minimizing Scrummer-fall type behavior. And it’s called, ta-da, planning. Now I know what you’re thinking, there is little to no planning in agile teams outside of the Product Backlog. Well, I sort of disagree with that – as I mentioned in this POST. I think the Sprint Planning meeting is the idea place for Scrummer-fall to be avoided, because this is where it’s inherently created.

You see, Scrummer-fall is not an accident. It’s intentional. It’s planned for. It’s the way the team envisions executing their sprint from the very beginning. Now that is sort of sad, but it also illuminates some “good news”. If you can plan for it, you can also plan against it.

Let me tell you a story…

The Genesis of Scrummer-fall

I was coaching an organization recently on improving their agile practices. As is my practice, I usually start by attending team meetings to get a feel for how things are done. I attended Sprint Planning for one team and this was the first planning session I’d attended in this engagement. I was looking forward to it, because you can get quite a lot of direct and indirect insights from planning.

The room was filled with people. I could clearly tell who the Product Owner was because he was presenting the current backlog to the team. He was standing, pointing out stories, fielding questions, and generally setting the stage for the next sprints’ content. Good start I thought, an engaged Product Owner is always a good sign.

I noticed that there were two distinct clusters of folks in the room—at separate ends of the table. As we began reviewing the body of work for the Sprint, I could tell that the larger one of them contained the developers on the team and the other, a couple of testers on the team. As we progressed into planning the sprint, each group would have quiet discussions amongst themselves as to the work for each story. You could clearly see the developer’s game planning their work and the tester’s theirs. Only at the end, would the two groups decide how to “glue” their work together and they would move on.

There was no planned collaboration or pairing within or across the two groups. Essentially all of the work was planned in a serial fashion from skill-set to skill-set and individual to individual. Individual work and hand-offs were clearly the order of the day.

As the team completed their Sprint Planning session, I realized that they’d set themselves up for a Scrummer-fall based sprint. You could literally “smell it” in the air. As we left the room, I made a note to myself that this was an area that I needed to seriously coach them towards improvement.

And in follow-up:

• Yes, the resulting Sprint followed a Scrummer-fall pattern
• Yes, everyone threw their work over the walls to each other
• And unfortunately yes, they Sprint failed to deliver on its Sprint Goal…even though the team worked incredibly hard as individuals.

What a sad story indeed…

Wrapping Up

You might be asking, what’s the big deal about Scrummer-fall? What harm does it cause? I’m glad you asked. On the surface it might not seem to be that harmful. Especially since everyone on the team seems to be working so hard. But if you look below the surface, it undermines quite a few basic Agile principles:

• It undermines collaboration and teamwork. Instead of a team ‘swarming’ around the work, individuals that are functionally aligned are focusing on “their piece” of the work.
• It undermines productivity. It turns out that individual hand-offs are very wasteful. And the delayed feedback further slows things down. So, working serially, handing things off, and waiting for feedback is incredibly unproductive.
• It often undermines delivery of business value. Often teams will miss delivery of key, high priority User Stories because they attacked them in a serial fashion.
• It can also undermine quality as teams rush to finish things at the very end of a Sprint. Quite often, a teams’ Definition of Done is compromised in their rush to try and deliver on their commitments.

As a tester on your agile team, I hope I’ve inspired you to avoid Scrummer-fall and given you some ideas on how to do that. I find that it’s a choice a team makes. So please help guide your teams towards collaboration / teamwork / swarming and subsequently towards delivering results that will rock your customers.

Stay agile my friends,

Bob.