In an article in the September issue of the Agile Journal, Joe Kreb's, Director of Program Management at AOL, says that the term "sprint" in Scrum is detrimental to successful Agile transitions. He says that software projects are more akin to marathons than sprints:
We assume that software projects have a scope which requires projects to be longer than 4 weeks in length. Therefore they cannot be seen as a series of sprints in an athletic sense, but need to be seen as time-boxes or mile-markers for long-distance racing.Therefore, when teams try to go full-speed and "sprint" in every iteration, sloppiness, exhaustion, and errors creep in:
In the same way an athlete would become sloppier in the execution of the sprint over time, an agile team would introduce defects and workarounds to keep the pace as high as possible. Eventually the execution will be so limited, that the team won't be able to sustain the pace either. At that point, the team is burned-out, the technical debt high and the team morale low. Even though the team had an amazing start, it fell behind only after a few iterations. Although we hope our agile team is self-managed and will push-back and manage the expectations, an agile coach could shield and protect a project team new to agile development against outside intrusion and interest.So, Joe suggests we monitor quality and morale of the team to catch this type of burnout early:
So when we look at organizational agility, we need to measure not only the velocity of the team in early iterations, but also the subsequent iterations making sure we burn-down instead of burning out. To recognize that a team did not find its steady state yet, executives need to visit more metrics than simply velocity. Quality and morale are as important as speed. Quality could be as simple as tracking the open defects, and the morale could be collected as an average vote of the team collected during the retrospective. Especially longer projects will benefit from a moderate but consistent pace in early iterations. Although, "sprinting" may sound like a great motivational pun, it will only carry us for a short period of time. We may hit the wall at the half-way point, as many marathon runners do.Joe leaves us with these words of advice:
On the one side, a sprint may convey the wrong message in an organization among executives and the team alike. It requires, however, little explanation because everyone knows a sprint is short. It could simply mean, we are "fast", but it could also mean "over-time" or "aggressive schedules". Explaining iterative-incremental may not be as intuitive as the notion of a sprint but if you are looking for a long-term and lasting agile impact, perhaps the marathon analogy helps you find your steady state. If you have good reasons to sprint, consider a longer recovery time in between iterations and projects.It is an interesting argument; we know that the word "sprint" clashes with a "sustainable pace" (from eXtreme Programming). It is also the experience of this reporter that new teams adopting Scrum (and Agile development in general), many times get in trouble trying to go too fast. Could this be one of the problems?