Resistance to Scrum: listen first, then respond

A manager folds her arms in the training session. A senior Developer says, with a smile, that he has seen this before. A Product Owner nods and then ignores the backlog. These are three kinds of resistance, and each is easy to misread as opposition when it is closer to information. The skill is to hear what it says before deciding how to answer it.

What the sources say

The Scrum Guide gives the Scrum Master a role with the organisation that implies this work. They serve the organisation by leading, training and coaching it in Scrum adoption, planning and advising Scrum implementations, helping employees and stakeholders understand and enact an empirical approach for complex work, and removing barriers between stakeholders and Scrum Teams. All four verbs assume people who do not yet understand or have reasons for doubt.

The wider field of change management studies how people and teams are affected by organisational change. It treats the support and preparation of the people involved as a core part of any major change, which includes restructures, process changes and new technology. Resistance to change is a standard subject of the field, and a common finding is that it is less about the change than about its effects on the people.

The SBOK® Guide notes the scale of what is being asked: an organisation planning to use Scrum must be prepared to drastically change its work culture and habits to realise the benefits. A request that large will meet reluctance.

Six common reasons

1. Loss of status or role. Managers whose job was to assign and track work, and specialists whose role was to be the gatekeeper, may see the framework as a reduction of their position. Their concern is real: the roles do change.

2. Fear of exposure. Short cycles, visible boards and open Reviews show what was hidden. People who relied on vagueness feel the risk.

3. Past experience. Someone has lived through a change initiative that was announced, abandoned and replaced. They are protecting themselves from another round.

4. Doubt about fit. "Our work is different." Sometimes this is true. Sometimes it is a rejection in the language of reason. See when Scrum fits and when it does not.

5. Extra work. Meetings, a new tool and a new vocabulary on top of a full workload, with no benefit yet.

6. Loss of control. A Product Owner told they must order the backlog by value, a team told to manage itself, an executive told to wait for the Review. Each gives up a form of control in return for a different kind.

Sometimes people also have concerns about fairness, such as who will be rewarded in the new model, or about competence, such as whether they can do what is now expected. These are worth asking about directly.

Responding to each

The principle is the same throughout: understand the concern, take it seriously and offer evidence or a way to test it.

What not to do

• Do not argue the concern away. "That is not how Scrum works" ends the conversation.
• Do not treat resistance as disloyalty. The person is often protecting something valuable.
• Do not mandate and move on. The Guide describes a team empowered by the organisation, which a mandate does not create.
• Do not skip the managers. Their support decides whether teams can change.
• Do not wait for everyone to be convinced. Start with the willing and let results speak.
• Do not hide the costs. Admit that the first Sprints are slower and that roles change.
• Do not label people. "Blockers" and "laggards" become self-fulfilling.

Resistance as useful data

Some resistance is right. A worker who says the release process cannot support Sprints is pointing at a real obstacle. A manager who says the team lacks a skill is describing a dependency. A Developer who notes the Retrospective is unproductive may be correct. The Scrum Master can sort the comments into three groups: concerns about the change itself (legitimate obstacles to remove), concerns about how it is being done (a fair hearing and adjustment) and concerns about personal impact (support and clarity). Each needs a different answer.

The Guide's invitation, "try it as is and determine if its philosophy, theory and structure help to achieve goals and create value", is itself a response to doubt. It does not ask for belief. It asks for an honest trial.

A worked example

This is an illustrative case. A department head, newly told that his teams will adopt Scrum, tells the Scrum Master he doubts it. He fears missed deadlines and a loss of visibility over who is doing what.

The Scrum Master asks him to describe his worst experience of a project. He tells her about a launch that slipped because a risk was reported late. She notes that the Sprint Review and the board show progress every two weeks, and she asks what he would need to see to feel in control. He says a weekly view of what is done, what is blocked and what the dates look like.

She offers him a one-page summary after each Sprint: the Sprint Goal, whether it was met, the top risks and a forecast range. She also invites him to attend the first Review. He comes and asks a sharp question about a dependency that the team had not raised. The Product Owner adds it to the list. After three Sprints he tells a colleague that he now knows about problems earlier than in the old model.

Nothing in his concern was dismissed. His need for visibility was met in a form that fits the framework. It took one conversation, a summary and an invitation to the Review.

The Scrum Master's stance

The Guide describes Scrum Masters as true leaders who serve. In resistance work that means listening before explaining, asking before telling, offering experiments, being honest about costs, and sharing credit when it goes well. It also means patience, since change in organisations takes longer than anyone plans. And it means knowing when to ask for help: a sponsor who can make a decision stick, or another Scrum Master who has done it before.

How to practise it

Think of the person most doubtful about Scrum in your organisation and write down, in their words, what they are afraid will happen. Then ask them if you got it right. In the simulator you deal with a Sponsor who has views on scope and pace, and how you respond shapes how much trust you keep.