When Scrum Becomes Stale

Scrum seems to be a bit like bread: When it is fresh, it is very tasty, and everybody likes a slice of it. But after a few sprints doing the same routines for planning, daily scrums, reviews, and retrospectives, Scrum may turn stale.

The sprint planning meetings deteriorate into task-assignment sessions, the daily scrums turn into status reports, the products are not always demonstrable anymore, and therefore the sprint reviews are used to rewrite the stories as a way to convert the unfinished work into new stories. And the retrospectives? If they are not abandoned altogether, sprint after sprint the same issues are voiced, most likely outside the power of the team to resolve them.

If a team does not watch out for signs of scrum going stale, its performance will suffer. Its development will stagnate or, even worse, go into a downward spiral. What can a team do to avoid this? Are there early warning signs indicating that the team may not be on its way to top performance? From my experience with many scrum teams, I have found recurring indicators that a team is not reaching its full potential and will soon be lagging behind.

Repeated, unresolved issues in retrospectives

Probably the clearest indicator of a team falling behind? Retrospectives that raise the same issues repeatedly. If the voiced impediments cannot be removed, the team will not improve. Good retrospectives are actually quite hard, but once the team starts getting used to them, it will become easier, and even fun, to think of new ways to improve.

Remedy: The team selects only one task and commits to resolving this issue during the next sprint. They also track it during and at the end of the sprint. To continue improving, this issue needs to be the highest priority for the upcoming sprint; otherwise, it will be down-prioritized sprint after sprint.

Stories are not demonstrable

Some teams have a hard time holding a live demo of all the stories in the sprint review. "There is no user interface," "This is only a technical story," or "The story was only to write a concept" are only a few of the excuses.

I observe this pattern mainly in companies with a strong waterfall project management culture. The project manager splits the project scope into work packages (incorrectly called stories) that are assigned to team members according to skill or availability.

Keeping a strict focus on the business value, the team can always demonstrate each story to the customer. The story is completed (done, really done, no further work needed), and the system meets the quality level that means it can go into production if the product owner wishes.

Remedy: The team decides during the sprint planning how the story will be demonstrated. When a demonstration seems to be difficult, it is likely that the story is not small enough or not split in the best way to ensure maximum business value. So the team needs to split the story into smaller, demonstrable pieces, or change the story altogether so that the focus is on business value.

Unfinished stories are split and carried over to the next sprint

It's possible that a story is not finished by the end of a sprint. Then the whole story counts as not finished and is moved over to the next sprint, counting 0 story points for this sprint.

To avoid this, a team may opt to split the story into finished tasks (and counting them somehow), and unfinished tasks that get wrapped into a new story are to be completed in the next sprint.

Remedy: During the retrospective, the team discusses what can be changed so that delivering all stories in a sprint becomes the norm. Depending on the cause, one measure is to split the stories into small, deliverable pieces during sprint planning. Another may be to further remove impediments that hinder the team from delivering.

During sprint planning, tasks are assigned to team members

If you are not collaborating as one team, learning to do so is difficult. The traditional way to work on projects is to have a task assigned and solve it more or less alone. Less experienced teams often develop the pattern that they (or the scrum master) assign the stories and tasks during sprint planning. Then everybody can work independently on their story and have full responsibility for it.

Unfortunately, this reduces overall team performance since the team cannot become more than its individual parts. Collaboration does not take place, team members cannot benefit from their collective knowledge, and improvement is difficult.

Remedy: During sprint planning, do not assign stories or tasks. Rather, let the team pull the most important task that is open during the daily stand-up. As a team, work on finishing the most important story first. Then start with the next-highest priority story. This way, the number of finished stories gets maximized, the team really collaborates, and each team member learns from others. The whole team is responsible for finishing all stories, not the individual who finishes only his or her stories.

Team members are not 100% on the project or are withdrawn from the project

I see this all the time: After a few weeks into the project, team members get pulled from the project (or were assigned to the project on a part-time basis from the beginning). The message is very clear: There are other projects that are more important, even if management tells you, "But they are still available for 20%."

Reducing team members' availability will hurt team performance and predictability. Even more, a person who is available for only 20% is often reducing another team member's performance so that the net benefit is worth less than if that person were not available at all.

Remedy: Don't. As a team, if a team member gets pulled away part of the time, think about excluding them altogether. Make it clear that you want only fully committed team members.

I am sure that there are many more patterns of scrum teams losing their focus, discipline, and thereby their performance. Here I wanted to focus on the ones I consider the most important indicators.

But please let me learn from your experience. What are your strategies to make sure your team keeps increasing their performance?

For more agile tips, go here.