Why Scrum adoptions fail, and what the failures share

When a Scrum adoption disappoints, the usual verdict is that Scrum does not work here. A closer look nearly always finds something more specific. A condition the framework depends on was never in place, and the team ran the events without it. Diagnosing which condition was missing is the useful skill, because each has a different remedy.

What the Guide assumes

The Guide's description is a list of conditions in disguise. The Scrum Team is structured and empowered by the organisation to manage its own work. For Product Owners to succeed, the entire organisation must respect their decisions. Scrum Teams are cross-functional. An Increment must be usable. Stakeholders take part in the Sprint Review. The Scrum Master is accountable for establishing Scrum in the organisation as well as the team. And the Guide warns that changing the design, leaving out elements or not following the rules covers up problems.

Each assumption is a place where an adoption can fail. The SBOK® Guide says something similar from the organisational side: an organisation planning to use Scrum should fully embrace the framework, be able to commit the needed resources, and be prepared to drastically change its work culture and habits to realise the benefits.

DORA's research on delivery performance finds that transformational leadership, leaders who inspire, support and enable their teams, is among the capabilities associated with better outcomes, which echoes the point that adoption is as much about the organisation as the team.

Seven common causes

1. The Product Owner has no authority. The person in the role relays decisions made elsewhere, cannot say no and cannot reorder the backlog. Sprints fill with whatever arrives. Symptom: decisions wait for a committee. See the proxy Product Owner problem.

2. The team is not allowed to manage itself. Tasks are assigned, scope and dates are fixed above, and the team may not change how it works. Symptom: the Retrospective produces actions that the team is not permitted to take.

3. There is no access to users or stakeholders. The Sprint Review is a demonstration for the team's manager. Symptom: nobody learns anything from outside, and the product drifts from need.

4. The product cannot be released. Code integrates rarely, testing is manual and deployment takes a weekend. The Increment exists in theory. Symptom: "done" and "released" are months apart.

5. The wrong people are on the team, or there are too few skills. Dependencies on other groups stall every Sprint. Symptom: many items blocked on someone outside.

6. Leadership expects the old measures. Managers ask for individual utilisation, fixed-scope plans and status reports, and punish bad news. Symptom: the team games reports and hides problems.

7. The change was announced, not understood. Training covered the events and not the reasons. Teams comply and wait. Symptom: ritual without purpose. See cargo cult Scrum.

Additional causes appear in particular settings: a poor fit between the work and the framework (see when Scrum fits and when it does not), too many projects per person, no time to improve, and an adoption timed with a crisis.

Diagnosing yours

A short exercise helps. For each of the seven, ask a team member to rate it from one to five, and ask for an example.

The lowest scores point to the work. An organisation that scores low on four or five has a bigger task than team-level coaching. The Scrum Master's accountability for helping the organisation, in the Guide's words leading, training and coaching it in its adoption, becomes the main job.

A worked example

This is an illustrative company. After a year of Scrum with six teams, the sponsor says it has not delivered. The Scrum Master of one team runs the diagnostic with her team and with the Product Owner.

Product Owner authority: the Product Owner scores two. Priorities come from a monthly committee. Team autonomy: three. The team chooses its tasks but not its Sprint length or tools. User access: one. Reviews are attended only by managers. Releasability: two. Releases are quarterly. Skills and dependencies: three. Leadership: two. Understanding: four.

The picture is clear. The framework is not the issue; four conditions are weak. She proposes a sequence, not a campaign. First, ask the sponsor to make the Product Owner the decision maker within the Product Goal, with the committee keeping the quarterly check on the goal itself. Second, bring two customers to the next Review. Third, ask the release group for a monthly release trial for this team. Fourth, show the sponsor the cycle time and the waiting time before release.

After three months, the team has a decision maker, two customers attending and monthly releases. The sponsor's next question is not whether Scrum works but how to extend the changes to other teams.

What to do about each

When to stop

Sometimes the right conclusion is that the conditions will not arrive, at least for now. Then a smaller, honest approach, such as short iterations and a regular review without the claim of Scrum, may serve better. The Guide says partial use is possible but is not Scrum. See Scrum-but. Saying so openly protects the framework's reputation and the team's time.

How to practise it

Run the seven questions with your own team and pick the lowest score. Write one specific request to the person who can change it. In the simulator you act in roles where authority, access and autonomy are given or withheld, which shows how much of success depends on them.