Scrum didn’t start as a project management framework. It started as a metaphor borrowed (somewhat awkwardly) from rugby.

The term was first used in a 1986 Harvard Business Review article called The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka. The authors studied high-performing companies like Honda, Canon, and Fuji-Xerox and noticed something important: the best product teams didn’t work like a relay race.

They didn’t pass the baton from marketing to design to engineering in a straight line. Instead, they moved together as a unit with cross-functional teams solving problems, overlapping tasks, and constantly adjusting course as they went.

In other words, they behaved more like a rugby team advancing the ball downfield.

Rugby’s unusual for a collision sport in that it accommodates just about every shape and size on the field. There’s a role for everyone, from lightning-fast runners to tiny little game managers and fridge-sized weapons. Each of them runs, kicks, passes, and drives the ball forward, using whatever strength or guile they’ve got.

That’s what the article was pointing to: teams with varied skills working together to achieve a shared goal, not in sequence, but at the same time.

Unfortunately, someone (probably an American) latched onto the word scrum—which appeared only once in the article as a section heading—and decided that would make a good name for this team-based approach.

Ironically, the scrum is probably the most static, slow-moving part of the game. It’s the bit where the big units stop to smash heads and push in a heap until the ball dribbles out. Not exactly the flexible, adaptive team play the authors were talking about.

But Agile does love a dramatic buzzword, and Scrum definitely sounds cooler than “continuous collaborative iteration.” So the name stuck.

Despite the unintended branding, the real takeaway from the article was this: teams do better work when they’re trusted to organize themselves, take ownership of problems, and adjust based on what’s happening, and not when they’re micromanaged through a rigid plan.

Here are the key traits the authors observed in successful teams:

• Built-in instability – Give the team a broad goal and let them figure out how to get there
• Self-organizing teams – Let teams choose their own process based on their skills
• Overlapping development phases – Work on things in parallel, not in sequence
• Multilearning – Learn individually, as a group, and as an organization
• Subtle control – Guide teams with light touch, not rigid rules
• Organizational learning – Share what you learn across the business

These were more of the ideas that shaped the evolving methodology of Agile and led to the emergence of Scrum as the framework it is today.

If you’re curious, you can read the full article here: The New New Product Development Game – HBR

It’s about giving smart people the freedom and structure to do good work together.

Kind of like this: