Is a "Sprint" Detrimental to an Agile Transition?

Posted by Amr Elssamadisy on Sep 15, 2008

Sections

Process & Practices

Topics

Agile ,

Adopting Agile ,

Agile in the Enterprise

Tags

Scrum

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?

1. Back to top

   Iterations vs Sprints

   by Chris Rimmer

   This reminds me of an anecdote that Mike Cohn tells of a team that used "sprint" and "iteration" to mean different things. The former was when they worked in an unsustainable way to rush something out whereas the latter was when they had time to do things right. Of course when Mike encountered them they were on their fourth "sprint" in a row.

   Reply

2. Back to top

   Re: Iterations vs Sprints

   by Jason Little

   I think the bigger problem with Agile transitions is the lack of proper knowledge and coaching when making the transition. Calling a cycle of work a 'sprint' doesn't imply work as fast as you can and cram in as much as possible. As far as Scrum goes, quality is not negotiable and it's important for the Scrummaster to coach not only the team, but to coach management.
   
   As far as the comment about velocity, I don't think anyone uses velocity (commitment or estimation velocity) as the sole metric. I know I don't.

   Reply

3. Back to top

   Heijunka

   by Dave Rooney

   Once of the tenets of the Toyota Production System is "heijunka". This means "Level out the workload", i.e. "Work like the tortoise, not the hare".
   
   
   
   To me, the term "Sprint" flies in the face of heijunka.
   
   
   
   Besides, in rugby a scrum is a place where you get your head bashed in on a regular basis. ;)
   
   
   
   Dave Rooney
   
   Mayford Technologies

   Reply

4. Back to top

   Sprints of more than 4 weeks?

   by Rob Ohlsson

   Our Product Owner thinks that reviewing the backlog and have a demo and retrospective every 4 weeks is too frequent, so our sprints are now 8 weeks.” — technical lead working as a Scrum Master

   - from this article When is a Scrum Master (or a PM) Not?.
   
   I think this truly complements your second paragraph.

   Reply

5. Back to top

   mis-agility

   by phloid domino

   re: "new teams adopting Scrum (and Agile development in general), many times get in trouble trying to go too fast."
   
   
   this is a very common and real danger, exacerbated by a tendency for many mangers to regard Agile as a panacea for the pervasively unrealistic scheduling practices in the development world
   
   
   agile has some real benefits, but is quickly being warped into yet more silliness by foolishly regarding short cycles as the central idea, rather than the full spectrum of agile principles, among them realism

   Reply

6. Back to top

   Is Agile going the way of OO?

   by Amr Elssamadisy

   So this kind of thing - the cargo-culting of Agile practices - is becoming more and more common :( I think Joe has a point here, but I think of the "sprint" mentality as only one leak in the boat and we're trying to stuff a napkin to keep from sinking.
   
   I see thought leaders going back to principles and values instead of practices, but I feel that it's too little too late....
   
   There is another interesting article on the Agile Journal (ok, I'm biased, but I did spend significant time reading the articles before publication), that discusses hiring in a large organization. One of the warnings there is be careful of people who tout 'self organizing teams' and think 'we don't need no stinkin PM!' (the colorful language is mine).
   
   Are we doomed to have only a small percentage of us experience the massive improvements and the bulk of us doing the ssdd?

   Reply

7. Back to top

   Re: Iterations vs Sprints

   by Amr Elssamadisy

   
   As far as Scrum goes, quality is not negotiable...
   

   
   
   Easier said than done. If you are doing pure Scrum without any of the technical practices like TDD, how does the team refactor as incremental functionality is added from the backlog? Does this affect quality at all?

   Reply

8. Back to top

   Re: Iterations vs Sprints

   by Jason Little

   Yes, much easier said than done but the team will learn to adopt those practices. The business needs to understand the benefits of taking a 'Quality is not negotiable' stance as well . It the team needs to learn those practices or build better testing framework, it's my job to sell that to management and I'm very blunt about it. I agree adding incremental functionality will cause quality problems and usually the team will learn pretty quick that they need better testing methods. All easy in theory, excruciatingly painful in practice!

   Reply

• Older >