BT

"Sprint": a Misnomer?

| by Mike Bria Follow 0 Followers on Nov 05, 2008. Estimated reading time: 2 minutes |

One of agile development's most fundamental concepts is working "iteratively" - running a project by delivering progressively better versions of the product at recurring interim milestones. Each methodology has its metaphoric label for this; the two most prevalent are XP's "iteration" and Scrum's "sprint". Kevin Schlabach talks about how the word "sprint" may be a bad metaphor.

Kevin Schlabach recently posted on how Scrum's use of the word "sprint" often conveys the wrong message to people:

Some people hear the scrum term "sprint" and get confused. They ask, how in the world do we run at full speed all the time and not get burned out?

The sprint metaphor is simply supposed to convey that your goal is so close and visible that you are motivated to put extra energy into trying to reach it...it conveys a heightened sense of awareness and focus allowing you to try and grasp at the goal right away.

It doesn't mean you are supposed to go as fast a possible...For most people, that is the definition of sprinting.

Schlabach goes on to compare agile development to the way a good marathon runner approaches their task. He discusses how it is essential for this runner to check his pace as he goes; the runner must strive to "[paraphrased] hit a 5 min mile on the first mile if they desire to average 5 min miles over 20 miles". Good runners take great care to know whether they're ahead or behind of their goal throughout the entire race; and further, care to know whether they are keeping a "sustainable pace", quite different than the approach of a "sprinter".

Schlabach brings this back to software by using this idea of "pace measurement" to illustrate what he believes to be the real point of a "sprint":

The real point of the sprint is to have a measurement cycle. If you don’t measure progress frequently, you can’t validate that your predictions are working out. By declaring you will take a measurement on a predefined cycle, you can't allow yourself to fall into a deep hole of trouble before realizing you need to dig yourself out of it.

Doug Shimp and Dan Rawsthorne touched on a similar notion in their 'Metaphors of Scrum' article from the Agile Journal:

The Sprint is a "Burst of Energy to Cross a Finish Line"
This is what a sprint is in track and field, and leads to the notion that Scrum's Sprint creates a constant sense of urgency. But do people conclude that they will run out of breath by running as hard an absolutely possible for the duration? What about sustainable pace? We have seen people shy away from this language when they are thinking that work is now going to be a series of exhausting breathless races.

We prefer to think of the sprint not by the speed, but the track. You can see the end line, and you get there in a straight line. The distance is short (30 days or less) that has a clear end point based on the product owner's definition.

"Iterating" at a "sustainable pace" is essential to successful agile development. Does the use of the word "sprint" pull people away from this? Do you have any thoughts or stories to recount regarding this question?

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

re: Sprint by Dave Rooney

I haven't talked to people about issues with the Scrum terminology since yesterday! :)

A scrum is a place where you generally get your head bashed in. A sprint is something that you can only do for a short time and can't do repeatedly.

I do have an issue with using marathon as well. Considering that the first person who ran one died at the end, it probably doesn't conjure the desired feelings and images. Perhaps something more like a 5K or 10K race?

Dave Rooney
Mayford Technologies

Re: re: Sprint by Barrett Nuzum

I agree that the vocabulary can be somewhat misleading, especially to newcomers to Scrum.

My first agile project had a number of retrospectives where members of the team remarked on how they did not find the pace sustainable. I believe Inspect and Adapt should generally help address this issue -- but are all Teams willing to invest the time to learn this lesson? I don't think so, as much as I feel they need to.

A few things I have generally tried is to use the word "Iteration" instead of "Sprint", especially as that implies not only that you are adding on to the solution, but also that it may not yet be finished (that is to say releasable).

Another term I favor is cadence -- which suggests the creation of a regular rhythm, and not so much of an exhausting, draining "run for the finish".

My former colleague Dave Nicolette has a great post today regarding "Equipo docente" -- teaching teams -- which could specifically address iffy interpretations of Scrum Vocabulary. (www.davenicolette.net/agile/index.blog/1853107/...)
I think coaching for newbies is essential to success.

Barrett

Lap by Jim Leonardo

Well, given you plan, execute, release over and over again, the proper track methaphor would probably be a bit more like "lap".

Just like "huddle" would be a better term than scrum, but it sounds less cool.

Re: Lap by Ben Hall

I don't think the sprint metaphor is a bad one but it isn't fully understood and it is mixed with other metaphors in the Scrum vocabulary. People think of sprinting as an all out effort, which in the sport of track it rarely if ever is. An oft repeated coaching idiom is "world records are run from a relaxed effort not the all out effort." Sprinting is controlled performance.

In modern track training interval training is a staple in the vast majority of programs at all levels. Interval training is typically something like warm up/run 8 repetitions of 400 meters in 68 seconds each with 2 minutes rest between each repetition/warm down. So each interval has two components- work and rest. The actual "work" being doing is often a sprint. Everything else supports the work efforts. You could also argue that many sprints have multiple rounds at meets. So even when competing you often have to control individual efforts throughout the rounds.

I'm a heavy Scrum proponent but I also feel the application of modern training/performance concepts could be beneficial in software engineering practices. Most college and post collegiate track coaches use a concept known as periodization (see Tudor Bumpa's works on the subject). Periodization basically breaks the year or years into macro and micro phases and manages various stresses across them to get optimal performance for the long term. These concepts are at a level that more directly parallel development efforts. We're working in months, weeks, days, and workouts instead of an extremely granular effort like the sprint metaphor. We're also talking about long term performance management instead of one time efforts, which is where Schlabach still seems to be stuck with his marathon metaphor.

Ben

Fundamentals by Dave Nicolette

Your point about terminology is well taken, but...

"One of agile development's most fundamental concepts is working 'iteratively' - running a project by delivering progressively better versions of the product at recurring interim milestones."

Neither the values nor the principles in the Agile Manifesto mentions the word "iteration." Therefore, by definition it isn't a fundamental concept of agile development. It just happens to be the most common approach at the moment.

The second half of the sentence sounds like a description of incremental delivery rather than iterative development. Incremental delivery is a cat that submits to many modes of skinning.

Now you'll have to excuse me, as I must go and get my head bashed in and then run around in circles at full speed until I die.

Cheers,
Dave

Re: Fundamentals by Dave Rooney

Now you'll have to excuse me, as I must go and get my head bashed in and then run around in circles at full speed until I die.

LOL!! I was a distance runner in high school... running intervals for training sucked! I don't care how much better a runner I was, they just sucked. :)

Dave Rooney
Mayford Technologies

Re: Fundamentals by Mike Bria

Neither the values nor the principles in the Agile Manifesto mentions the word "iteration." Therefore, by definition it isn't a fundamental concept of agile development. It just happens to be the most common approach at the moment.

Dave, true, not a "by the book" value or principle. But, fact is, it's become among the most (if not the most) prevalently accepted of all activities for anyone even slightly "agile". Tis the reason I choose "fundamental concepts" over "documented value/principle/(or even)practice". I tried.
The second half of the sentence sounds like a description of incremental delivery rather than iterative development.

Really? To be picky...I see incrementing as "adding new pieces/components" and iterating as "improving on what's already there". To be fair, I think software dev (well, agile dev) is always a good mix of both. Again why I tried to choose words carefully to state neither explicitly, but rather to say more abstractly "delivering progressively better versions", which implies neither (or implies both, depending on how ya look at it).

Interestingly regarding that, my own personal observation is that the word "iteration" may in fact not be totally correct either, or at least not totally complete, being most often we're doing a little bit of both iterating and incrementing when we run another "agile lap".

Kinda off Kevin's original point that "Sprint" often conjures a negative connotation for many (like it or not), but what the hey! ;-)

Cheers
MB

Re: Lap by Mike Bria

Ben, all good points.

In my opinion though, a metaphor is only as good as it's ability to be perceived unambiguously by those without the "back story". Other words, as you lay out well above, the "Sprint" metaphor is not inherently wrong; Kevin's point is that it's just not necessarily effective, people often picture the wrong thing when they hear it. Like it or not, that just is what it is.

To take this off topic, my personal feeling is that frankly no metaphor tells the who story, and why I think groups newer to agile always need an expert (a coach) to help them understand what all these cute words really mean.
I also feel the application of modern training/performance concepts could be beneficial in software engineering practices
Very interesting. I'm an athlete myself (or at least once was before my inner geek completely took over!). I often use my days as a football player to draw metaphors from when explaining various agile practices to people. That said, I was also a track-n-field guy, and I see what you're hitting on, I might use that in the future. Cool stuff.

Cheers
MB

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