[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.

Bad Agile Management Burns Scrum Teams

Last month Giles Bowkett wrote a scathing blog post about scrum called: Why Scrum Should Basically Just Die in a Fire. It’s a provocative article that shows how damaging bad agile and scrum can be to a team.

Ms. Glaze | Flame | Flickr

Ms. Glaze | Flame | Flickr

I’m not going to go point by point and argue with Mr. Bowkett about his experiences with scrum. They are his experiences, and they are truly awful. I have sympathy for him and those who have been burned by a botched agile transformation.

With waterfall, teams know what they are signing up for at the start of a project. They know there will be problems and that a death march is likely. They also know that the date set at the beginning of the project is likely wrong, but still they soldier on.

But with agile and scrum it’s supposed to be different. The agile manifesto is a developer play aimed at making the lives of engineers better. Scrum specifically puts the team in control of how they accomplish their work. Everything should be great.

But often, it isn’t.

Mr. Bowkett makes this point by calling out many common scrum anti-patterns that he has experienced:

These are all valid – and unfortunately common – problems on scrum teams. However, the conclusion that he draws from the existence of these problems misses the mark.

In other words, in its best-case scenario, Scrum’s a dog-and-pony show. But that best-case scenario is rare. In the much more common case, Scrum covers up the inability to recruit (or even recognize) engineering talent, which is currently one of the most valuable things in the world, with a process for managing engineers as if they were cogs in a machine, all of equal value.

Rather than cover up individual inabilities, scrum exposes the bad practices of organizations. Quickly. Work becomes transparent, impediments become obvious, and old practices become extra painful.

The culprit here are manager who thought they were getting hyper-productivity for free. They want the benefits of scrum, without having to change.

Mr. Bowkett’s problem is with lousy managers, not scrum.

The agile community is also partially to blame. The tendency is to focus coaching and training on the scrum team. But it is the management team members that we need to be working on the most. Bad scrum cannot take root in an organization that embraces the scrum values from the top down.

Part of embracing the scrum values is accepting the twelve principles of agile from the agile manifesto, which Mr. Bowkett also railed against.

I don’t think highly of Scrum, but the problem here goes deeper. The Agile Manifesto is flawed too. Consider this core principle of Agile development: “business people and developers must work together.” Why are we supposed to think developers are not business people?

We’re not. The intent of this agile principle is the end the “us vs them” mentality between IT and “the business”. With Scrum, the expectation is that the product owner is co-located with the development team and available to answer questions about the product backlog items.

This isn’t a slight against the business acumen of developers. It’s a call for close collaboration between stakeholders and engineers. How else can the development team know if they are working on the most valuable features for the business?

Question: Have you been a part of a poor agile transformation? What went wrong? How could things have gone better? You can leave a comment by clicking here.

Scrum Teams Must Set Goals for Their Agile Metrics

Knowing what you want to find before you start looking seems like common sense. Yet many agile and scrum teams blindly gather metrics without really knowing what they want to learn from the data.

Erika | Target | Flickr

Erika | Target | Flickr

The way that most scrum teams approach agile metrics reminds me of the exchange between Alice and The Cat in Lewis Carroll’s classic Alice in Wonderland.

In this scene, Alice has come to a fork in the road and is unsure which way to go:

Alice: Would you tell me, please, which way I ought to go from here?
The Cat: That depends a good deal on where you want to get to
Alice: I don’t much care where.
The Cat: Then it doesn’t much matter which way you go.

Alice did not have a goal in mind while she was traveling along the road, and neither do most scrum teams when they set out to capture agile metrics.

Scrum teams can quickly become enamored with the amount of data that can be collected during a sprint. Story points, velocity, cost per story, cost per story point, throughput, number of stories per sprint, escaped defects, team health, and customer satisfaction are just a few examples off the top of my head.

Give the wide range and complexity of agile metrics that we could capture, we should accept a simple truth about these calculations:

The agile metrics that scrum teams collect are meaningless unless they are driven by a goal.

Why do you track velocity sprint after sprint? Because a training class said to? Or because you read about it in a blog post? No way!

There should be a problem that the scrum team is seeking to either solve or understand with every agile metric that they are collecting. With velocity, a scrum team could be trying to gauge their sustainable pace. Or perhaps they want to provide a means to help the product owner with release planning.

The actual goal is not as important as making sure that the team has one in the first place.

During a particularly difficult sprint retrospective meeting, one of my scrum teams noticed that they were struggling to deliver all of the stories that they committed to during consecutive sprints.

After some discussion, the team decided to track estimated story points per sprint and velocity. The difference between the two numbers would be called “found work”.

The scrum team decided that the goal of tracking these agile metrics – and particularly “found work” – was to measure changes in effort over the course of a sprint. The team felt that effort increased over time, which cause them to miss their sprint goals.

After a few sprints, the scrum team learned that the estimated effort was significantly increasing. But the numbers cannot tell you where the problems actually are. The root cause could have been one of many things:

  • Perhaps the scrum team was not properly grooming their product backlog items which led to “found work” during the sprint.
  • Maybe the scrum team’s definition of done was too stringent given their level of engineering practices which caused an increase in effort to deliver the stories included in the sprints.
  • It’s even possible that after digging deeper the scrum team learned that the relationship between the scrum product owner and the stakeholders was strained which led to poor communication and incomplete product stories.
  • Progressive elaboration could also have been taking place. The scrum team could simply be learning throughout the sprint and everything could be ok.

With the goal of their agile metric work realized, the scrum team focused on the problem during their next sprint retrospective. They were able to realize the high “found work” metric meant that too many epics were being added to the sprint backlog.

Not grooming their stories and slicing them in to smaller pieces hid much of the complexity that the scrum team was agreeing to take on sprint after sprint.

This particular team added a “3 touch rule” for stories to their definition of done. In order for a story to be eligible to be added to a sprint backlog, it had to be groomed and estimated at least 3 times by the team. This change led to the scrum team being more consistent at hitting their sprint goals.

Metrics are alluring, but they can also be deceptive and more importantly abused. Scrum teams should be intentional about how they collect agile metrics, the goal of the data, and what decisions will ultimately be made. Otherwise, why go to all the trouble of collecting the data in the first place?

Question: Does your scrum team collect metrics that do not have clear goals assigned to them? How are these agile metrics used? You can leave a comment by clicking here.

Scrum: Velocity Measures Story Points, Not Productivity

Scrum teams rely on metrics to inspect and adapt. Taken too far, the metrics tend to lose value and in some cases cause harm.

Robert Donovan | Velocity | Flickr.com

Robert Donovan | Velocity | Flickr.com

Last week I wrote about 5 agile metrics to measure high-performance scrum teams. At the top of the list was the most controversial metric that scrum teams use: velocity. This seemingly simple metric is just a measurement of how much effort a scrum team can complete within a given sprint.

Velocity is – in its simplest form – the sum of the story points completed in a sprint.

The temptation that many organization face is to turn velocity in to a performance metric.

For instance, I was recently asked what I thought about setting an objective to increase the team’s velocity by 10% by the end of the year. My answer: It’s a terrible idea.

  1. Encourages gaming:  An intelligent scrum team will realize that if they gradually inflate their estimates over the course of a year they will hit their 10% objective – WITHOUT delivering more value to the organization.
  2. Increasing velocity is not the goal of scrum:  We are interested in delivering valuable, high quality software to our companies in a sustainable way. How does a 10% increase in velocity get the scrum team there?
  3. Quality suffers as a result:  A scrum team that is forced to increase velocity will have to make tradeoffs to complete the additional stories required to get the numbers higher. Quality inevitably suffers when these types of decisions are made.
  4. Lots of unknowns:  Scrum team members leave the company, they get sick, and go on vacation. An estimation can also be way off – it is an ESTIMATION. If the scrum team learns something new about a story, velocity can dramatically go up or down.

Another idea that managers try is to compare the velocity of one scrum team with another. This is usually an attempt to normalize velocity across multiple scrum teams. It’s a meaningless comparison as scrum teams have different skills, goals, tools, and approaches to estimating work.

Flame wars often flare up over questions like: “Does a scrum team get credit for the story points related to bug during a sprint?”

Some scrum team members say, “Yes! We did the work and it should show on our velocity.” Others say, “No way, you already got credit for that story and are now cleaning it up. No double dipping!”

Mike Cohn did a great job of answering the question here. Essentially, he says pick whichever way makes sense to your team and be consistent. Easy, right?

Questions like these come up regularly and show a general lack of understanding of how velocity should be used.

Velocity is a limited metric that can only tell you what you achieved in the past and could possibly do in the future. During sprint planning it can help a team avoid over committing. During a sprint retrospective an up or down trend in velocity could lead to a discussion about the team’s definition of done or other team practices.

And there is the value that comes from tracking velocity. It is in the conversations that it causes the scrum team to have. These discussions are opportunities for the team to inspect and adapt their practices. The new insights will hopefully lead to more valuable, working software being delivered to the organization.

Which is important because according to the Agile Manifesto, “Working software is the primary measure of progress.”

Question: Which metrics do you use to drive conversations on your scrum team? You can leave a comment by clicking here.

HELP!!! The Scrum Master IS the Impediment!

At the heart of the scrum master role is servant leadership. We are driven by serving our teams as teachers, mentors, and coaches. It’s our job to help the team remove impediments, not to become one.

Brandon Glasley | Facepalm | Flicker.com

Brandon Glasley | Facepalm | Flicker.com

As a newly minted Professional Scrum Master (PSM I), I returned to my team excited and ready to get underway. Unfortunately, I brought back a purist view of scrum and had not fully grasped the concept of servant leadership. In other words, I failed miserably.

The problem started in the daily scrum’s. I took a heavy handed approach and ran the meeting how *I* saw fit. I asked the questions of each scrum team member and asked follow-ups where I felt *I* needed more information.

During a sprint planning meeting, I pressed the team to use the AS AI WANTIN ORDER TO format for user stories. The team came up with their own format that they felt more comfortable with. And still I pressed on.

Why I felt the authority to do so is beyond me. User story formats are not prescribed by scrum. A development team member approached me and very respectfully disagreed with me in many of these areas. Tension grew between us.

After a particularly stressful daily scrum, he stormed out and I was left with a team of amazed developers staring back at me…disappointed. And they were fully justified.

I tracked down the developer that stormed out and after a tense, but respectful meeting I finally started to see the errors of my ways.

Scrum – A Pocket Guide tell us that “The scrum master has no interest in scope, budget, delivery, or tasks but coaches and facilitates the complete ecosystem in scrum to manage them.”

I was still being a project manager. That was no longer my role.

I apologized to the team and they showed me a lot of grace by giving me another chance. We went on to deliver some amazing sprints and managed to bring some real value to bear for the business. But why did the conflict happen?

I struggled with giving up the command and control mentality.

Scrum masters who transition from a traditional project manager role must initially cope with the fact that they are not in control of the team. Scrum masters have no direct authority. We are a servant to our team. Our role calls us to help the team get better at playing the game of scrum.

As coaches, we must be careful to not turn adopting scrum in to people being coerced to follow new practices. People can typically handle change given enough support, but they are universally defensive in the face of coercion.

The developer – who rightly challenged the way I was behaving – embodied the scrum values of respect, commitment, focus, openness, and courage. He had the courage to speak up, the commitment to the team to want to do things better, the openness to air a grievance, the respect to keep things civil, and the desire to focus the team on valuable work.

If you find yourself on a team where the scrum master has become an impediment you have a number of choices:

  1. Do Nothing: Allowing the behavior of an errant scrum master to continue undermines the scrum adoption and disrespects the entire scrum team. This option isn’t really an option.
  2. Address the Issue Privately:  The advantage of this approach is that you give the scrum master the opportunity to realize their mistake without an audience. I appreciated this approach when I had lost my way. If it’s difficult for you to address the issue 1:1 then the next venue is the sprint retrospective meeting.
  3. Address the Issue During the Sprint Retrospective: If the 1:1 approach did not work, the team can bring up the behavior of the scrum master as an impediment during the sprint retrospective meeting. When the team discusses what did not go well or what made them mad/sad the scrum master should be brought up. Done respectfully, this conversation could lead to a positive outcome.
  4. Self-Organize/Self-Manage: The scrum team is a self-organizing/self-managing entity. If the scrum master is not getting the message after multiple attempts, the scrum team does have the right to select a new scrum master. It would be an unfortunate turn of events, but in some cases this drastic step is necessary.

I’m thankful for the developer who challenged me to be a better scrum master. He made me confront my fear of giving up control and helped me become the servant leader that I needed to become for the scrum team to be successful.

Question: Have you ever been on a scrum team where the scrum master was an impediment to the team? How did you handle it personally? How did you handle it as a team? You can leave a comment by clicking here.