[QUESTION] Why Do Scrum Teams Call Agile Iterations “Sprints”?

The Scrum Guide tells us what a “sprint” is and gives best practices around duration and timing, but it says nothing about why scrum teams call iterations “sprints” in the first place.

phgaillard2001 | le depart | flickr

phgaillard2001 | le depart | flickr

This question actually came from a podcast that I listen to called This Agile Life.

John Sextro, Craig Buchek, Amos King, Jason Tice, and Lee McCauley publish this weekly podcast about life as agile coaches and developers.

On This Agile Life episode #64, the topic was Giles Bowkett’s blog post – How Scrum Should Just Basically Die in a Fire. I recently blogged about this same post, but did not comment on Mr. Bowkett’s disagreement with Scrum calling agile iterations “sprints”:

Scrum’s an agile development methodology, and one of its major goals is sustainable development. However, it works by time-boxing efforts into iterations of a week or two in length, and refers to these iterations as “sprints.” Time-boxed iterations are very useful, but there’s a fundamental cognitive dissonance between “sprints” and “sustainable development,” because there is no such thing as a sustainable sprint.

The This Agile Life crew zeroed in on this criticism and mused about asking Jeff Sutherland why he decided to call scrum iterations “sprints”. Fortunately, Mr. Sutherland has a new book out called Scrum: The Art of Doing Twice the Work in Half the Time AND he answered this question:

And so my team embarked on what we called “sprints”. We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and stop to see where we were.

With the origin story in mind, the “sprint” label makes sense for scrum teams:

  1. The goal is intensity:  Scrum teams are laser focused on a sprint goal and work diligently on their sprint backlog items to turn their stories in to working software.
  2. Scrum teams take time to catch their breath: At the end of each sprint is a sprint review meeting. During the sprint review meeting, scrum teams stop to examine the sprint activities, the latest increment of software the team delivered, and the product backlog. The scrum team also conducts a sprint retrospective to examine how the team got to where they are and how they can do things better during the next sprint.
  3. Sprints are short for a reason: Mr. Bowkett is correct when he says that there is no such thing as a sustainable sprint. But short (2-4 week) sprints with time taken to inspect and adapt the work IS sustainable. Not stopping at the end of the time box jeopardizes sustainable pace as does going past the 1 month maximum sprint length.

Inspecting scrum is a great way to become a better agile practitioner. Podcasts like This Agile Life and blogs like Mr. Bowkett’s are great places to help you think about scrum and deepen your understanding about the practices that you use every day. It’s a tip that I’ve given in the past, but I cannot stress it enough as a great way to improve.

In this case, we learned that the label “sprint” is meant to give teams a sense of urgency, but with the intention of taking rest after the intense work it takes to turn sprint backlog items in to increments of software.

Question: What do you think about the term “sprint”? Does it express the right intention, or is it time to go back to “iterations”? You can leave a comment by clicking here.

[QUESTION] Can a Scrum Master Force an Increase in Velocity?

The Scrum Master is demanding a higher velocity during the next sprint. Does the scrum development team have to listen or has the scrum master overstepped?

Beat Kung | Emc2 | Flickr.com

Beat Kung | Emc2 | Flickr.com

No, the scrum master has overstepped.  The scrum master is a member of the scrum team – not its manager. The Scrum Master can ask the development team to increase velocity, but cannot force it.

The Scrum Master can only ask because increasing velocity means adding more work to the sprint backlog. The development team owns the estimates and they also decide how much work they can take on during a sprint. Any increase in work – even to increase velocity – must be approved by the scrum development team.

Yes, the development team could deflate their estimates to achieve the same thing. But let’s assume that the scrum master would catch on to that scheme pretty quickly. Let’s also eliminate the possibility of increasing the length of the sprint to increase velocity. The math works, but it’s also an easy gimmick to spot.

Scrum teams are self-managing and self-organizing. The concept of force does not play well in this context.

Let’s pretend for a moment that a scrum master could demand a higher velocity from the development team. Here are possible outcomes:

  1. Decrease in quality:  A team that has an imposed metric is forced to cut corners to meet the new demands. Quality is the first thing to go in these types of situations. It becomes very easy for a team to decide that in order to meet an unrealistic date they must stop writing unit test. Or even worse, that they should stop testing all together.
  2. Increased technical debt:  A scrum team that is under the gun is not likely to make the right decisions. Over time, a series of compromises in quality and architecture will lead to increased technical debt. Ironically, additional technical debt will reduce velocity in the future as the system becomes too fragile and complex to change easily.
  3. Demoralized Team:  Scrum is a developer play. At its core is the empowerment of the development team. Self-organization and self-management remove the traditional command and control levers from software development. Add those back in by forcing an arbitrary velocity and you’ve taken away the scrum development team’s ability to own their work. And along with that their morale.

The scrum master in this example was not acting as a servant leader. Remnants of a command and control structure are still present in this situation. More likely, this is a case where the development cannot do their best work due to impediments that still exist in their organization.

If the scrum master believes that a higher velocity is possible, he/she should ask the team: What can I do to help you be faster?

Question: Have you worked on a scrum team with a “command and control” scrum master? How did that impact you? You can leave a comment by clicking here.