Scrum outside software: what carries over and what changes

The word "Developers" makes Scrum sound like a software method, and the first thing a marketing manager or a lab lead hears is that it is not for them. The Guide takes the opposite view. It says the authors are humbled to see Scrum adopted in many domains holding essentially complex work, beyond software product development where it has its roots. It says developers, researchers, analysts, scientists and other specialists do the work, and that the word "developers" is used not to exclude but to simplify: if you get value from Scrum, consider yourself included.

Where the roots are

Scrum did not start in a code editor. The 1986 article that gave the framework its name was based on case studies of product development in manufacturing industries, including automotive and office equipment. The rugby image was about how a team making a physical product could work as a unit. The software world adopted it in the 1990s. So when someone applies it to a hardware team, they are partly going home.

What carries over unchanged

Most of the framework does not depend on the type of work.

• A goal for the product. The Product Goal, a future state that the team can plan against, works equally for a campaign, a research programme or a service.
• One ordered list. The Product Backlog is an emergent, ordered list of what is needed. Items can be experiments, assets, decisions or deliverables.
• A small, cross-functional team. The Guide's requirement that members have all the skills necessary to create value each Sprint holds anywhere. A marketing team might include a writer, a designer and an analyst.
• A fixed cycle. A Sprint of one month or less with a Sprint Goal.
• Regular inspection by the people who care. The Sprint Review and Retrospective do not depend on technology.

What needs translating

Three ideas need a translation.

The Increment. The Guide defines an Increment as a concrete stepping stone toward the Product Goal, additive to all prior Increments, thoroughly verified and usable. For software that is a working build. For other work, ask what a usable stepping stone looks like. In a campaign it could be a launched channel with measured results. In a lab it could be a completed experiment with analysed findings. In a policy team it could be a drafted, reviewed and tested proposal that a decision maker can respond to. The test is the same: could a stakeholder use it or react to it, and does it meet an agreed standard?

The Definition of Done. It is the formal description of the state of the Increment when it meets the quality measures required for the product. In non-software settings, the measures differ but the function does not. For a research team the definition might say that findings are documented, the method is reviewed by a peer and the data is stored in the shared repository. For a content team it might say fact-checked, edited, approved by legal and published. See Definition of Done.

The cost of change. Software is cheap to change relative to a physical object. A team casting metal or printing a book cannot revise as freely. The Sprint Goal can still guide the work, but the team needs thinner slices, such as prototypes, simulations, mock-ups, test batches or sample runs, before committing to expensive steps. The Guide's advice that shorter Sprints limit risk applies with more force when change is costly.

A worked example: a marketing team

This is an illustrative team of five that runs campaigns for a software product: two writers, a designer, a data analyst and a channel manager.

The Product Goal is to double the number of trial sign-ups from a particular audience within six months. The Product Owner is the head of marketing. The backlog holds items such as "a comparison page for the audience", "a three-email onboarding sequence", "test two headline variants" and "analyse why trial users drop out on day three".

In a two-week Sprint the team's Sprint Goal is to learn which of two message themes brings more qualified sign-ups. The Sprint Backlog holds the items needed: copy for both themes, two landing pages and tracking. The Definition of Done says each asset is edited, approved, tracked and live. At the Sprint Review, the team shows results to the sales lead and product manager, who note that the second theme draws a different audience than expected. The Product Owner reorders the backlog.

Everything the Guide requires is present. Nothing in it is about software, and the team's work is still complex, because nobody knows which message will work.

A second case shows the translation at a slower tempo. A small research group studies how a new material behaves under heat. Their Product Goal is a validated model of that behaviour. Backlog items are experiments and analyses, ordered by how much each would reduce uncertainty. A Sprint of three weeks ends with a Sprint Review where colleagues from the funding body see the data, not a slide about it. The Definition of Done requires a recorded method, raw data stored and a second person's check of the analysis. The group learns in each Sprint what to try next, which is exactly the inspection and adaptation the framework is for.

What to adjust

A few cautions help when moving outside software.

1. Check the cycle against the feedback. If results arrive only after six weeks, a two-week Sprint cannot close the loop on its own. Choose goals that the Sprint can finish, such as launching the test, and use the Review to look at partial signals.
2. Watch for the part-time team. Many non-software teams are made up of people who also have operational duties. The Guide expects a team focused on the Sprint, so ring-fence time or accept a smaller scope.
3. Rename carefully. Changing "Developers" to "Team Members" does no harm. Changing the accountabilities does.
4. Resist importing software terms. Story points and velocity are not required. See how velocity gets misused.

Common mistakes

• Declaring that the work is "too creative" for Scrum. The Guide's definition rests on complexity, and creative work is a typical case.
• Treating the Sprint Review as a status meeting for managers.
• Measuring non-software work with software metrics, then gaming them.
• Skipping the Definition of Done because "quality is subjective". A short, agreed list does more than a long argument.

How to practise it

Pick one piece of non-software work, write a Product Goal in one sentence, list five backlog items and write a Definition of Done with four lines. If you cannot, the gaps are what to work on first. The simulator's projects are software, but the decisions, such as scope, quality and stakeholders, apply to any team.