Where Scrum came from, from a rugby metaphor to the Guide

Most people meet Scrum as a set of meetings and job titles, and assume it was designed by a committee for software companies. The real story is shorter and more interesting. It starts with a question about manufacturing, not code, and it explains why the Scrum Guide is so insistent on a handful of rules.

A relay race and a rugby team

In 1986 a business journal published an article on how some of the most successful companies of the time developed new products. Its authors noticed that these companies did not hand work from one specialist department to the next, like runners passing a baton. Their teams worked on the whole problem together, with overlapping phases, passing the ball back and forth as they moved forward as a unit.

The authors called this a holistic, or rugby, approach. The SBOK® Guide traces the framework's name to that article and to the rugby formation in which a group of players packs together to restart play. The point of the metaphor was not aggression. It was that a team with a shared goal, and the freedom to organise itself, moves faster than a chain of handovers.

That idea is still the heart of the framework. The Scrum Guide describes a Scrum Team as a cohesive unit of professionals focused on one objective at a time, with no sub-teams or hierarchies inside it. If you read what Scrum is after this, the one-team design will make more sense.

The early 1990s: building it

The Scrum Guide says Scrum was developed in the early 1990s. It names the companies where it was first tried and proven: Individual Inc., Newspage, Fidelity Investments and IDX, which is now part of GE Medical. These were product and software organisations facing the same problem. Long plans written up front kept being overtaken by what the team learned while building.

What emerged was a way of working in short, fixed-length cycles, with a single ordered list of work, a small team, and regular points where the people building the product and the people paying for it looked at the actual result together. The names and exact rules took years to settle.

1995: the public debut

The Guide records that the two people who developed Scrum first presented it together at a major object-oriented programming conference in 1995. It describes that talk as documenting what they had learned over the previous few years and making public the first formal definition of Scrum.

This matters because it shows Scrum began as a description of what worked, not as a theory looking for a use. The first definition was also small. Much of what people now call Scrum, including user stories, story points and the three-questions stand-up, was added by practitioners later and is not part of the framework.

2001: the Agile Manifesto

In February 2001 seventeen practitioners met at a ski lodge in Utah, with the stated aim of finding common ground between lightweight approaches to software development. According to the Manifesto's own history page, the group represented several methods, including Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Pragmatic Programming. They wrote the four values and twelve principles that became the Agile Manifesto.

Scrum is one of the frameworks that fits under that umbrella, and it did not create the umbrella. This is worth remembering when someone says "Agile" and "Scrum" as if they were synonyms. The longer comparison is in Scrum and the Agile Manifesto.

2010 onward: the Scrum Guide

The first Scrum Guide was written in 2010 to help people worldwide understand Scrum. The authors say they have evolved it since through small, functional updates, and that they stand behind it together. The version in current use is the November 2020 edition, which made several changes you can see in its wording:

• the Product Goal, Sprint Goal and Definition of Done are described as commitments tied to each artifact;
• the Developers, Product Owner and Scrum Master sit together in one Scrum Team without a separate "development team" inside it;
• the Guide speaks of self-managing teams, not self-organising ones;
• it is shorter than earlier editions.

The Guide also says that the framework is free and that its authors consider it immutable. Implementing only parts of Scrum is possible, but the result, they say, is not Scrum.

A worked example: why the history shapes the rules

Here is an illustrative situation. A company builds a ticketing app. In the relay model, a business analyst writes a requirements document, designers produce screens, developers build, testers test, and operations deploys. Each group is accountable only for its own stage. When the testers find that the screens cannot be built as drawn, the work goes back along the chain, weeks after the original decision.

Now apply the rugby idea. One team holds all the skills to design, build, test and release a small piece of the ticketing app in a month or less. The Product Owner keeps one ordered list of what is wanted. At the end of the Sprint a stakeholder sees a working increment and says whether it solves their problem. The same questions get answered in days that the relay took months to answer.

Every part of Scrum that feels strict, such as a fixed-length Sprint, a cross-functional team and a Definition of Done, is a way of keeping that rugby team intact.

Where the SBOK fits in

The SBOK Guide came later and has a different job. Its Fifth Edition says that the original SBOK Guide appeared in 2013 and that later editions refined it using feedback from practitioners and trainers. It also traces the name Scrum to the 1986 article. It describes how to run a whole project with Scrum, as processes in phases, while the Scrum Guide defines the framework itself.

Common mistakes about Scrum's history

• Treating Scrum as the Agile Manifesto. The Manifesto came in 2001, after Scrum existed, and it covers several methods.
• Thinking the Guide is old. It was written in 2010 and revised through 2020, and the people who wrote it say they still stand behind it.
• Assuming rugby means chaos. In the metaphor the team is highly disciplined. What is removed is the sequential handover.
• Crediting practices to the framework. User stories, story points and burndown charts were added by practitioners. The Guide says such patterns are described elsewhere because they depend on context.

How to practise it

History helps most when you test it against your own work. Ask whether anything in the way your team works resembles a relay, with finished work passed over a wall. In the simulator you can feel the difference: you take a role in a small team and make the decisions that a rugby-style team makes together.