Two big things agile teams get wrong about Scrum

One of my "Head First Agile" readers sent me a question about Scrum. It turned out that his team was getting some basic things wrong about Scrum. Many agile teams make the same mistakes. I turned my response to him into this article to help other teams avoid this very common—and avoidable!—trap.

This originally appeared on Twitter — follow me @AndrewStellman for agile tips, project management, and C# and game development.

I routinely get questions people who have read my books and have questions about agile, project management, and development. A reader recently got in touch with me with two questions:

1. My Scrum Master decided that the team should reassign a task to a different team member. How should we handle this?
2. It's partway through a Sprint, I want to investigate an alternate design approach. Is it okay to ask permission from the Scrum Master to do this?

I've worked with many teams over the years, and I've heard variations on these questions over and over again. Like a lot of people, this reader is on a team that's made two mistakes with Scrum that a lot of teams make.

The truth is, on a lot of teams, disagreeing with the boss or a senior or lead developer can have bad, often job-ending consequences. So team members will try to find "technicalities" in the rules that let them avoid that conflict. These questions can be symptoms of that problem.

So when I'm coaching teams or doing Q&A, folks often ask about asking permission to change tasks, or what to do when someone has an idea that the team—or, more likely, the boss—will disagree with, they're worried that disagreement can cause problems, conflict, and get them fired.

One big symptom of an environment where disagreeing with senior people make your job worse is a team that's supposedly following Scrum, but the person in the Scrum Master role has the authority to assign work or fire people, which breaks the parts of Scrum that protect the team.

Here's how the Scrum Guide describes the Scrum Master role: 

The Scrum Master is a servant leadership role. A Scrum Master helps folks both in and outside of the team understand Scrum, and to help them use it more effectively to deliver valuable software.

So the problem with my reader's questions is that it's not the Scrum Master's role to assign the team work. If the team is asking the Scrum Master for permission to do something, that person might have the title "Scrum Master" but they aren't really filling the Scrum Master role. Those are two big things that this reader's team is getting wrong, and if they're like most teams I've seen that get this wrong, it's making their implementation of Scrum much less effective.

Scrum teams are self-organizing, which means team members decide among themselves who should work on each task, and they make those decisions at the last responsible moment. For many Scrum teams, that means team members assign themselves tasks during the Daily Scrum.

Really effective Scrum teams work together every day to understand the plan and make sure everyone is doing the right thing. That kind of continuous, real-time inspection of the plan is a key part of what makes Scrum work.

Now, to answer the first question. If the Scrum Master—or any other team member—disagrees with a task assignment, that's great! Bring it up at the Daily Scrum when the person assigns themselves a task. The team can discuss it and work together to come up with the right approach.

The Scrum Master may be a leader, but they're not the boss. The Scrum Master doesn't have authority over the team. It doesn't make sense for a team member to ask the Scrum Master permission for anything, because the Scrum Master isn't in a position to grant permission.

So on to the second question. If a team member asks the Scrum Master permission to investigate an alternative design, that's great! It's a perfect learning opportunity. The Scrum Master can help the person understand that it's not up to one person to grant any kind of permission.

The Scrum Master should encourage the team member to bring it up at the next Daily Scrum. They can add it to the Product Backlog, and they can prioritize it in the next Sprint if that makes sense. If it needs to start sooner, the Product Owner can move it into the current sprint.

The important thing is that this is all done in a way that's transparent: the whole team can discuss it, the Product Owner is given all of the information needed to prioritize it, and the team can explain it to the stakeholders at the next Sprint Review. That's how Scrum works.

Have questions about Scrum, agile, project management, or development? @ me on Twitter