Troubleshooting Scrum

The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.

It would be lovely if everything just worked as you expect it to perfectly, from the beginning to the end every single time. That doesn’t happen in the real world. One of the advantages of scrum is that it doesn’t pretend that things are always going to be perfect. Scrum has built-in checks and balances to make sure the team is always responding appropriately to changing conditions, and reinforcing scrum techniques to make sure they support their goals.

Scrum breakdowns tend to follow familiar patterns across organizations. Let’s take a look at a few of the aspects of scrum we’ve discussed, to see where issues are likely to crop up, and how to address them.

Undefined Time Boxes

When a team is starting out using scrum, they may not understand how much time to allocate for their rituals. Defining a time box in which the ritual must be completed helps focus everybody’s attention, and shows respect for the team’s time. There’s a temptation for new teams unsure about how much time to allocate to leave the time box undefined for the various aspects of the ritual.

It’s especially important when teams are starting out to define time boxes explicitly for every aspect of a ritual. Sometimes these time boxes may just be guesses, and the team will need to learn by iterating from sprint to sprint just how much time they need. It’s better to propose a wildly incorrect time box and try to enforce it than it is to leave the time box loose. The exercise of proposing and enforcing time boxes demonstrates respect for the team’s time, and respect for the process.

There are some experts who advocate reducing the length of time boxes to the minimum length possible when teams start exceeding their time boxes consistently, and then working closely with the team to help them get through all the stages of each ritual within the very limited time that’s been allocated. This helps establish the importance of defining and respecting the time box for each aspect of the ritual. And if the team mentions at the retrospective that the time box was too short, it can be extended by consensus for the next sprint.

Optimizing for Sprints

There comes a point at the end of many planning rituals when the team is agreeing to a backlog for the sprint. At this stage, the product owner should already have organized into priority order the stories that have been estimated, and considered what would make a sensible increment for the product at the end of the sprint.

As estimated stories get moved into the sprint backlog, the team discusses how much work they believe they can get done that sprint. Often, the last story added to a sprint backlog will not be large enough to bring the team up to their projected velocity based on their historical performance. At that point, the team may try to negotiate with the product owner about the order of the remaining stories, in order to get a story with the optimum number of points added to the sprint backlog so their commitment exactly matches their expected velocity.

This unwise exercise is optimizing for the sprint, and it demonstrates a basic misunderstanding of the point of scrum. The prioritization of the stories, and the purpose of working on them in order, is about adding value to the product, not pushing forward an agenda around optimizing the scrum process. When it comes down to it, the work is more important, not the number of points completed in a sprint.

It’s better to leave that sprint backlog a little short, and agree with the team that they may start work on the next highest priority story once all the stories they committed to in this sprint are done. After the commitment for the sprint backlog is completed, it’s perfectly fine for the team to start working on a story of any size that has the next highest priority, even if they don’t expect to complete it within the same sprint. Ultimately, the team’s point velocity is estimated across multiple sprints, and it will all average out.

Long, Lazy Standups

The purpose of the daily standup is to capture the heartbeat of the team, for the sake of the team. These rituals are kept short in order to respect everybody’s time. One of the first mistakes teams tend to make is to treat the daily standup as if it were a team meeting. This could be played out in many ways, including having the team sit for the daily standup, planning announcements at the beginning of standup, and not limiting cross-talk during standup.

Everybody is expected to stand during the ritual, so that nobody feels inclined to let the ritual exceed its time box. No devices or other distraction should be in anybody’s hands, and nobody should be working on their laptop or talking about anything other than the story currently being discussed.

It’s a slippery slope if you start allowing people outside of your team to include announcements at the beginning or the end of standup. Announcements tend to encourage more discussion, and that can quickly lead to standups that last longer than 15 minutes.

There should only be one person speaking at a time during the standup, and that person should be the engineer discussing what was done since the previous standup, what will be done by the next standup, and whether there are any blockers. Issues will come up that need further discussion, but that discussion needs to be taken off-line for follow-up after the standup is completed. Everyone on the team should feel empowered to support the scrum master in cutting off other conversations and keeping the standup focused.

Work Interruptions

One of the premises of scrum is that the engineers will have the opportunity to plan ahead for the duration of the sprint, without worrying that their work is going to be interrupted by distractions and side projects. The team commits to a sprint backlog, and it’s up to everybody to defend the integrity of that backlog and not allow additional work creep in.

The reality—particularly for web and mobile development teams—is that things come up. Servers go down. Features break. Time-critical announcements happen. Users get confused by new features and they need to be adjusted. Urgent issues need to be addressed that were not anticipated when the sprint began.

In traditional scrum, any change to the stories committed to in the sprint backlog demands that the team stop the sprint, go through a new planning ritual, and establish a new sprint backlog. This is considered a draconian measure, and has been put in place to discourage anybody from violating the integrity of the sprint.

Web and mobile development teams need to incorporate a certain degree of flexibility into their process, due to the dynamic nature of their work. It would be very impractical if the team had to start a new sprint every time a broken form needed to be fixed, or a press release needed to be edited. But there’s a balance that must be maintained. It would be just as inefficient if part of the team had to drop everything and start working on a new, urgent feature every time an executive or a client got a brilliant idea for a new feature.

It’s the nature of web and mobile work that the team needs to be flexible enough to deal with emergencies, but they also need to be strict about what constitutes an emergency. This is something the scrum master, the product owner and the team should define explicitly as part of the team’s scrum contract.

Any new work pulled into a sprint should be expected to reduce the team’s velocity. That additional work should not be estimated, since it was not part of the team’s sprint backlog commitment. If the team starts allowing new stories to creep into a sprint on a regular basis, that will pull them away from their backlog commitment, and will be reflected in their velocity.

Making time to address urgent issues is essential, with the understanding that urgency is a concept everyone on the team needs to agree on. If the integrity of the sprint seems to be broken too regularly or too casually, it’s something the team should definitely be discussing during the retrospectives.

Loose Demos

Every team needs to come up with a clear definition of done. Part of that definition should always include meeting all of the story’s acceptance criteria as it was written. This gets tested during the demo. It’s important to be consistent about the way stories are accepted at demos, and not to allow the standards to get too flexible.

Tne common issue that comes up is teams that allow stories to be accepted when the acceptance criteria are not fully met. Sometimes, stories are accepted into a sprint, but the work on them lingers into the beginning of the next sprint, because they were “almost done.” This confuses the end of one sprint and the beginning of the next, making it more difficult to say clearly what was done in one sprint, what needs to be done in the next one, and what the team’s real velocity is.

It’s also vital that teams come to demos prepared to demonstrate all the work they did in the sprint. Frequently, teams find themselves sitting around waiting while the developer finishes deploying code, or adjusting the staging environment for the demonstration. While it’s reasonable to expect that there are sometimes emergencies that get in the way, it’s the responsibility of the developer who worked on the story to make sure it’s ready to demo, and that the product owner knows how to walk through the demonstration.

Some teams take a very strict approach to this, not accepting any story that isn’t an exact fulfillment of all of the acceptance criteria and ready to demonstrate at the start of the demo. While that may seem harsh, the important thing to remember is that getting things into the sprint is not as important as getting the work done.

Teams can be as severe or as lax as they like around their demo acceptance criteria, as long as they’re consistent. There’s nothing wrong with erring on the side of being severe, and making sure that what was done in the sprint was completed within the sprint. The critical issue is to make sure everybody agrees to the process and understands the importance of following it.

Problem Solving During Retrospectives

Without retrospectives, scrum doesn’t have the opportunity to learn from its mistakes, or benefit from its excesses. Retrospectives also serve a strong team-building function, in that they allow the team members a chance to share what’s on their mind with their colleagues. While the most common problem teams have with retrospectives is not holding them at all, next on the list would be trying to resolve the problems that come up during a retrospective at the ritual itself.

Retrospectives are an opportunity for everybody on the team to bring up anything they think went well or didn’t go well during the previous print, and to discuss how to address the issues going forward. This touches on potentially sensitive topics, and can bring a lot of emotions to the surface. For people who feel they may be on the negative side of a discussion, there’s a strong impulse to try to resolve the problem then and there.

• Some issues may involve too many of the people in the room, and may require more consideration before everyone can agree to a solution.
• Not everybody is going to feel comfortable talking openly at the retrospective about some issues that may be sensitive, and that might be better addressed in smaller meetings.
• It’s also easy for people who have louder voices or stronger opinions to take over large group discussions, negating opinions that might be easier to recognize in a less open form.
• In addition, trying to solve a problem that doesn’t affect everybody in the group is a waste of some people’s time.

It’s up to the scrum master to remind everybody that the retrospective is not an occasion for solving problems, but rather for recognizing that they exist, and for then committing to solve them during the upcoming sprint.

It’s reasonable to allow the conversation around a problem to go on for a little while, so that people have the opportunity to fully understand all sides of an issue, and commit to finding a reasonable resolution during the sprint. But if that discussion gets too deep into the details of how to solve the problem, it may be time to cut the discussions short out of respect for everybody’s time.

Summary

In this chapter, we’ve gone over some of the steps that a company may want to take as it starts to implement scrum.

We talked about getting buy-in across the organization, both from within engineering and outside. We discussed how to get the team trained, and what a trainer should be expected to do for the team. We talked about the staffing issues, and how the people who already work in the organization can adapt to take on the roles of financial process. And we talked about the importance of tracking and measuring the effectiveness of scrum. We also dug into some of the problems that can come up as a team gets used to scrum, and how to work around them.

In the next chapter, we’ll get back in touch with the people we met in Chapter 2, now that they’ve been working for a while in a scrum environment, and find out how well their concerns have been addressed, and how they’re adapting to the scrum process.

Frequently Asked Questions (FAQs) about Troubleshooting Scrum