BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or get video-only pass to recordings.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Is a "Sprint" Detrimental to an Agile Transition?

QCon San Francisco (Oct 2-6): Learn what's next from software leaders pushing the boundaries.

Is a "Sprint" Detrimental to an Agile Transition?

This item in japanese

Bookmarks

Sep 15, 2008 2 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more
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
Style

This content is in the Agile topic

Related Topics:

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.

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

Community comments

  • Iterations vs Sprints

    by Chris Rimmer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

    Back to top
  • Re: Iterations vs Sprints

    by Jason Little,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

    Back to top
  • Heijunka

    by Dave Rooney,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

    Back to top
  • Sprints of more than 4 weeks?

    by Rob Ohlsson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

    Back to top
  • mis-agility

    by phloid domino,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

    Back to top
  • Is Agile going the way of OO?

    by Amr Elssamadisy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

    Back to top
  • Re: Iterations vs Sprints

    by Amr Elssamadisy,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    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?

    Back to top
  • Re: Iterations vs Sprints

    by Jason Little,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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!

    Back to top

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

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

BT