Not Taking the Initiative

Scrum Master:

Is everybody busy enough today?

Developer:

I’m waiting on some feedback from the tester before I do anything else.

Scrum Master:

Grab another item from the sprint backlog and start working on it. We all have to stay busy.

If this conversation sounds familiar, you’re not alone: Todd has done this too and he’s not proud of it. It’s a trap that can happen in any sprint when we, as Scrum masters, view ourselves as task masters whose job is to keep everybody busy. This often results from outside pressures—frequently from management trying to make sure everyone is working at maximum capacity. It’s common for management to think that sprints are about getting as much work done as possible, and that the most effective way to do that is to keep everyone as busy as possible. But as you know, the outcome of a sprint isn’t about that: It’s about the development team creating a done and potentially shippable product increment.

So what should a designer do if they finish their work halfway through a sprint? What should coders do while testers are validating that everything works, especially toward the end of a sprint? And what should testers do at the beginning of a sprint?

Scrum doesn’t recognize specializations in title. Everyone on a development team has the same title: developer. That’s not to say that various members of the dev team don’t have specialized skills—they will and should. But they should always be willing to pitch in to help achieve the sprint goal, even if it requires doing things that aren’t in their areas of expertise. Not doing so can cause all kinds of headaches. For example, if the coders are getting ahead of the testers every sprint, eventually the coders will be a full sprint ahead and the testers will be a full sprint behind. If coders try to start work for an upcoming sprint instead of lending a hand with testing, they risk creating waste. The team can’t predict the future, and technically the next sprint hasn’t been planned, plus they don’t have feedback on the current increment. Because we don’t know what the customer wants, there’s no way to “get ahead,” so trying to do so just wastes time and effort.

As we’ve said, collaboration is critical to a development team’s success, and lending a hand wherever necessary is a great way to foster collaboration. If a development team doesn’t collaborate, they run the risk of excluding experts from different domains when decisions are being made about the product. For example, if designers work in a box, not sharing the reasoning behind their design, the architecture might not be capable of supporting their design. And if coders “work ahead” while the testers work on their growing list of tasks, then testers aren’t part of the decision-making process. Perhaps they’re even being excluded from estimation, which means the team misses out on their valuable insights into ways the team could perform the work.

As we discussed in the “Everyone for Themselves” section earlier in this chapter, limiting the amount of work in progress and having conversations about managing the flow of work can help to bring these bottlenecks to light during a sprint. It’s important that all domain experts on a team work hand-in-hand. Could one area of expertise hand off pieces of work earlier to another one? And can the team coordinate the handoffs to make them smaller and create less of a backlog? Or better yet, can they work together simultaneously on something? Often the answer is “yes.’’

Even if the development team has minimized the handoffs, made work as collaborative as possible, and fully integrated their work with systems and other teams, at the end of the sprint—whether that’s the last two days or the last week—everyone on the team can and should help with any work that needs to get done to achieve the sprint goal.

While no one should do work for the sake of looking busy, there’s always work that team members can do, even if it’s not the type of work they normally specialize in. The whole development team is accountable for the increment at the end of the sprint. No one person gets the credit for success or the blame for failure—we succeed or fail together.