Scrum-but: when parts of Scrum quietly go missing

Almost every team that uses Scrum has a sentence that begins "we do Scrum, but". We do Scrum, but our Sprints are six weeks. We do Scrum, but the Product Owner is a committee. We do Scrum, but we skip the Retrospective because it is a waste of time. Some of these sentences describe sensible adaptations. Others describe the quiet removal of the parts that make Scrum work. Telling them apart is one of the most useful skills a Scrum Master has.

What the Guide says

The Guide is unusually firm. In its opening section it says each element of the framework serves a specific purpose that is essential to the overall value and results realised with Scrum, and that changing the core design or ideas of Scrum, leaving out elements or not following the rules covers up problems and limits the benefits, potentially even rendering it useless. In the end note it states that the framework is immutable: while implementing only parts of Scrum is possible, the result is not Scrum, and Scrum exists only in its entirety and functions well as a container for other techniques, methodologies and practices.

Two distinctions are packed in there. Removing or changing the core is what the Guide warns against. Adding practices around the core is what it welcomes: the framework is a container for other techniques. It is also explicit about what lies outside it: patterns, processes and insights that fit within the framework may be found and applied, but they are context-sensitive and described elsewhere.

The Guide's reasoning is that Scrum is an experiment machine. Each element produces a kind of information or a kind of pressure. A missing element does not simply reduce a benefit. It removes the information the team would have used to see that something was wrong, which is why the Guide says omission covers up problems.

A test for any change

When someone proposes a change, a few questions sort it.

1. Is it an addition or an omission? Adding a practice, such as a team working agreement or a limit on work in progress, sits inside the container. Dropping an event, an artifact or an accountability removes a part.
2. What did that element do for us? Name the purpose. The Retrospective's purpose is to plan improvement. The Definition of Done's is a shared standard of quality. If you drop the element, who now does that job?
3. What problem does the change address? If the answer is "the event is boring", the fix is to change how it is run, not to remove it. If it is "the Sprint is too short for our release process", the fix may be to improve the process.
4. Does it hide anything? A change that makes information less visible, such as a Sprint Review closed to stakeholders, makes problems harder to see.
5. Is it a trial with an end? "We will try X for three Sprints and review" is an experiment. "We have always done X" is not.
6. Who benefits? Changes that serve convenience at the cost of quality or openness should be viewed with suspicion.

A change that is an addition, serves a named purpose and can be reviewed is usually fine. A change that is an omission, serves comfort and has no review date is Scrum-but.

Common examples

Each of these is understandable. The first usually comes from a boring Retrospective, the second from a wish to share responsibility, the third from a feeling that the work is too varied for a goal. In each case the cause is real and the removal does not solve it.

What is not Scrum-but

Many adaptations are healthy.

• Adding practices: pairing, test-driven development, a working agreement, a health check, limits on work in progress. The Guide allows them.
• Choosing a Sprint length within the Guide's limit of a month. The Guide leaves the length to the team.
• Choosing the Daily Scrum format. The Guide gives the Developers the choice.
• Choosing estimation methods, or none.
• Using tools or boards of any kind.
• Adding events around the core, such as a refinement session or a cross-team meeting, so long as they do not replace the five.
• Using SBOK processes alongside the Guide's framework.

None of these changes the accountabilities, events or artifacts. They are decisions the Guide expects the team to make.

A worked example

This is an illustrative team. Its Retrospectives have dropped in quality: the same three people talk, the same complaints arise and nothing changes. One Developer proposes dropping the event: "we are doing Scrum, but retros are a waste, so we'll do them only when something goes wrong."

The Scrum Master applies the test. It is an omission. The Retrospective's purpose is to plan improvement, and if it goes, nobody takes on that job. The problem it addresses is a poor Retrospective, which can be changed. It hides something: problems that never reach "something went wrong" will stay unspoken. There is no review date. The benefit is comfort.

She proposes an experiment instead. For three Sprints, change the format each time, limit actions to one, name the owner and check the previous action first. See when retrospectives go stale. The Developer agrees to try it. After three Sprints, two actions have been completed and a recurring problem with review delays is solved. The team keeps the event and keeps changing the format.

The alternative, dropping the event, would have saved an hour a fortnight and lost the one place where the review delays were noticed.

Responding to Scrum-but

Ask the purpose question rather than citing the rule. "What would that event have told us?" works better than "the Guide says no."

Make the cost visible. Show the data: time lost to defects found late, decisions that waited, the improvements not made.

Offer a time-boxed experiment. People who cannot agree to a permanent change may agree to a trial.

Be honest about naming. If the team chooses to leave parts out, calling the result something else, such as a team-specific method that borrows from Scrum, is more honest than calling it Scrum. The Guide's position is that the result is not Scrum, and using the word sets expectations that will not be met.

Look at the organisation. Many Scrum-buts are forced by the environment: a manager who needs reports, a release process that fixes the dates. The Scrum Master's work with the organisation is part of the answer.

Start with the biggest omission. Do not try to fix everything. Pick the missing element that costs the most.

How to practise it

List every "but" your team uses and apply the six questions to each. Choose the one that costs most and propose a three-Sprint experiment. In the simulator the events and artifacts are all present, which lets you see the information each one produces by taking part in it.