Who should decide about changes in the process - Scrum Master or the whole Scrum Team?

Question

I need some clarification about how the changes should be introduced within the process in a Scrum Team and how a Scrum Master should approach it.

By changes in the process I mean for example: changing the length of a sprint, introducing some practices such as limitting Work In Progress, pair-programming etc.

My considerations:

Scrum Master manages the process. Mike Cohn's webpage states:

ScrumMaster has no authority over Scrum team members, the ScrumMaster does have authority over the process.” (...) ScrumMaster can say, “I’ve decided we’re going to try two-week sprints for the next month.”

He also compares Scrum Master to a personal trainer:

The trainer cannot make you do an exercise you don’t want to do. Instead, the trainer reminds you of your goals and how you’ve chosen to meet them. To the extent that the trainer does have authority, it has been granted by the client. ScrumMasters are much the same: They have authority, but that authority is granted to them by the team.

On the other hand Scrum Guide says:

Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

During the retrospective, the whole Scrum Team (including SM) decides about improvement in the process they will introduce.

Question(s):

So is it like this that :

1.Scrum Master decides that a change will be applied (becuase he has the authority to do so - authority granted by the team). And the team members follows this change, because they trust SM and have respect to SM role. So SM says: “I’ve decided we do this and that”

or

2.Scrum Master just proposes the change and then the team makes the decision that they commit to introduce this change? SM says: “What do you think if we try to do this and that?”

And what if they do not want this change - he cannot force them to do so, and he can “only” remind of goals and try to convince to follow a change?

Answer 1

In a proper Scrum, it's definitely option 2. It's the team as a whole who decides about process changes. The Scrum Master is a servant-leader, not a command-and-control style leader. So even if she is convinced that a specific change in process is necessary, she shouldn't (and can't) force it to the team: she has to convince them, or preferably explain the situation, the problem(s) she sees and the available options to resolve it, then let them come to the decision themselves. That's one of the biggest challenges of being an SM, to keep one's mouth shut and instead just wait and listen to the team :-)

Note that even if the SM is perceived by the team to have the authority to make process changes by herself, if the team members don't fully accept such a change, it won't work; they will have buried resistance which may very well sabotage the process and eventually even break the team if not handled properly.

Exceptions

are always possible, of course :-) So the above is not to say the SM can never, ever impose process decisions onto the team. I can imagine situations when e.g. the team is undecided for some reason (they are new to Scrum, and/or they are not accustomed to be a self-organising team so they need some hand-holding), so the SM has to make a decision on their behalf. However, she should still coach and support them towards becoming independent as soon as possible. Or if the proposed change is small and experimental, like "let's try the Boat Retrospective this time for a change".

But by and large, these should be rare and limited exceptions rather than the norm.

Answer 2

TL;DR

The Scrum Master is a full member of the Scrum Team with an assigned role within the framework. The Scrum Master can therefore recommend changes in the process to the team without being wishy-washy about it, but should not dictate processes or practices unless that authority has been specifically delegated by the Scrum Team or by the broader organization. Even then, such delegated authority is likely a "project smell" that indicates a team or organization is not yet truly agile.

The Scrum Master as Process Referee

Your question quotes a blog or wiki post from Mountain Goat Software. With all due respect to the author, "process owner" tends to lead readers into a common trap because the phrase connotes authority rather than stewardship. In my experience, effective Scrum teams know that the Scrum Master is a process referee. That means that the Scrum Master doesn't own the process; rather, the Scrum Master:

• evangelizes the framework;
• calls "framework fouls" when the team or the organization doesn't follow the tenets or principles of the framework;
• educates the team and the organization about Scrum; and
• facilitates communication within the team, and between the team and the rest of the organization.

To the extent that teams or organizations delegate authority to the Scrum Master to manage the framework or other processes, the Scrum Master may be able to make unilateral decisions, but that is certainly not a given.

Agile Principles Lead to Recommendations, Not Dictates

Assigning authority beyond the basic role defined by the framework is something that should be carefully weighed against the core principles behind the Agile Manifesto. Specifically:

• The best architectures, requirements, and designs emerge from self-organizing teams.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The framework itself defines a number of core responsibilities for each role, but the transfer of responsibility away from the team as a whole (including the Scrum Master and the Product Owner) and to a single individual fundamentally undermines the ability of the group to continuously improve their own processes.

Therefore, the Scrum Master would be within the scope of the role to point out that recent Sprints had fallen short of the quality required by the definition of done. As a member of the Scrum Team, the Scrum Master could then suggest that other teams have solved similar problems through changes to Sprint length or by introducing pair-programming practices.

The Development Team also has a voice, though, co-equal with the Scrum Master's and the Product Owner's. They can't simply dismiss the recommendations of another member of the Scrum Team, but they are also welcome to veto, amend, or improve upon those recommendations.

As long as the Scrum Team as a whole is routinely meeting their mutually-agreed Sprint Goals, how the team gets things done is entirely up to them. However, if the Scrum Team is frequently not meeting its agreed-upon Sprint Goals, then the Scrum Master is certainly expected to call a "framework foul" and insist that current processes (including the Scrum process itself) be inspected and adapted to address the impediments to success.

Answer 3

As part of Scrum the improvements/changes to scrum process are made as part of Scrum Retrospective which is a team exercise. Scrum guide says that:

"Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint."

Role of the Scrum Master in the retrospective is to facilitate and teach the scrum team how to conduct the retrospective and to understand its purpose. Scrum guide states:

"The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process."

But the improvements in the scrum process is a collective exercise as scrum guide states the following: "By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint."

For the teams which are new to scrum should start with SU level of Sprint retrospective which includes three questions: 1. What went well with this sprint? 2. What could be improved ? 3. What will we commit to in the next sprint?

Scrum team should collectively create Retrospective Improvement Backlog , order it and select from it each sprint one or two things that they'll work on improving in the next sprint.

Sprint Retrospective is teams commitment to quality and continuous improvement which can never happen if development team members don't commit to these decisions.

Answer 4

In my experience, the ScrumMaster should be working collaboratively with the teams to first devise recommendations and experiments based on some patterns being experienced or issues that come up via retrospectives. The whole team should then determine if the new practice should be a part of the teams working agreements.

For example, if you wanted to switch to 1-week sprints from 2-week sprints, first work with the team to help understand what problems you are trying to solve, what questions need to be answered, how you long your experiment will take place and what is a successful outcome. Once the experiment time box has closed, the team should determine if this should be part of their working agreements.

You can apply these basic principles to any new process but making it a team decision will ensure the ideas stick!