BT

Is a "Sprint" Detrimental to an Agile Transition?

| by Amr Elssamadisy Follow 0 Followers on Sep 15, 2008. Estimated reading time: 2 minutes |
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?

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

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.

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

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.

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

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?

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?

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!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss
BT