Scrum Teams Today are Nothing Like Rugby Teams

Scrum Teams in 2023 are nothing like the Rugby teams that inspired the creation of the Scrum Framework. Rather than having a rugby-style team working together with a single team focus, most Scrum teams today are comprised of individuals working asynchronously using online tools as a clumsy substitute for face-to-face communication and collaboration.

How exactly did we get here?

A Brief History of the Creation of the Scrum Framework

The creation story for Scrum has two parts. First, there was a research paper by two Japanese researchers at Harvard University. Hirotaka Takeuchi and Ikujiro Nonaka were Harvard professors who studied some of the best practices used by new product development teams. The paper they wrote in January of 1986 was called The New New Product Development Game.

The key to their research was the finding that those teams that used a linear, sequential development process that resembled a relay race were slower and less creative than teams that used a newer approach that they dubbed the rugby approach:

Instead, a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.

— Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game

The term “Rugby” is used eight times in the paper to describe how the best development teams succeed.

Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish. Rather than moving in defined, highly structured stages, the process is born out of the team members’ interplay (see Exhibit 1).

— Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game

Later in their paper, the authors use the term Scrum as it is used in Rugby in the subheading for a section of the paper, Moving the Scrum Downfield. The Scrum in Rugby is where the players lock themselves together in an attempt to get control of the ball and move it downfield as a unit.

They also described the following six characteristics of teams that used this approach:

1. Built-in instability
2. Self-organizing project teams
3. Overlapping development phases
4. “Multilearning”
5. Subtle control
6. Organizational transfer of learning

Less than 10 years later, Scrum co-creators Jeff Sutherland and Ken Schwaber were inspired by the findings of Takeuchi and Nonaka. They wanted to avoid the problems with the popular linear, relay race approach that was used for most software development at that time (aka waterfall). They started to experiment with some of the ideas from the paper and then formalized their findings in a presentation at the OOPSLA 1995 conference.

The rest, as they say, is history.

The current Scrum Framework as described in the 2020 Scrum Guide still holds true to those same ideas.

So what is the problem?

Most Scrum Teams Today are Nothing Like Rugby Teams

Unfortunately, our current Scrum Teams are nothing like the Rugby Teams that inspired the Scrum Framework. Just watch a Rugby game and you will see:

• Players constantly communicate with each other
• In a Scrum, players literally lock arms and legs to form a single unit
• Team members work together to quickly build human pyramids to enable them to take control of inbound passes
• Players working closely together to move the ball downfield

Let’s contrast that with a typical team using Scrum today:

• Team members don’t sit together and communicate in a face-to-face way. This is partly the result of the COVID Pandemic which permanently shifted to remote work. This cannot be entirely blamed on COVID though as even prior to 2020 only about one in four teams were co-located.
• Communication is mostly asynchronous and individuals may work at different times.
• The idea of moving the ball downfield by working together as a single unit is non-existent in Scrum. In fact, there is very little collaboration or working as a team. Instead, people learn their task assignments from the online tool and work independently on the tasks assigned to them.
• Many Scrum Team members work on multiple Scrum Teams. So they are unlikely to be in the same mind space as their colleagues. Work is handed off from person to person in a sequential fashion, just like the waterfall approach that the originators were trying to avoid.
• Some teams go so far as to build workflow and automation into their Agile Lifecycle Management (ALM) tools so that those handoffs are automated. That way, team members don’t have to talk with one another.
• For those teams that do a Daily Scrum (not all do), team members take turns providing the progress of “their work”. There is little or no concept of the team’s work, the Sprint Backlog or the Sprint Goal. Usually there is a Scrum Master or Project Manager collecting that status; it is not intended for the other team members who don’t really care because they have their own pile of work to focus on.
• Teams are not self-organizing. In nearly all Scrum Teams, there is someone giving the orders. This is either the department manager, a project manager, a “Scrum Master” who is driving the team, or someone else.

Most Scrum Today is Waterfall Disguised in Sprints

The way that the Scrum Framework is used today is a lot more like the waterfall-style development that Takeuchi, Nonaka, Sutherland, and Schwaber were striving to avoid. At best, Scrum is used as a work assignment and tracking mechanism used to monitor team members and their performance. At its worst, Scrum has become oppressive, squelching creativity and self-organization in favor of managerial control and oversight.

Even though teams use Sprints, they often don’t complete the work of the Sprint. No problem, they will simply carry it over to the next sprint. Someone even created a macro in our online tool that automates the carry-over process.

Other “teams” use the output of one team’s “Sprint” to hand off work to another team. This could be a Test Team running a lagging sprint. Some teams are not cross-functional and at the end of the sprint, they have an interim work product that is handed off to an entirely different Scrum Team who creates the end deliverable.

Even teams that are cross-functional and able to deliver end-to-end still leverage handoffs within the team. The tool handles the handoffs as assignments and obviates the need for team members to talk. Each team member can just do their own thing.

Retrospectives are often skipped and frequently ineffective. Poor facilitation and lackluster participation have made this important Scrum activity a dull and lifeless exercise that most team members would prefer to avoid.

ALM tools which became necessary to support remote work are now the main focus of Scrum Teams. Managers are happy because of the automation and because the tools help them to track tasks and monitor team member productivity.

It does little good to blame the tools though. The tools were created to meet the market needs for control and oversight. The real root causes are more complex.

What Would An Ideal Scrum Team Look Like?

An ideal Scrum Team would look different the typical Scrum Team today:

• Team members would collaborate to solve issues.
• Team members would coordinate their work to maximize the team’s effectiveness.
• Team members would pair or mob together to take backlog items to “done”.
• You would likely find team members gathered around a whiteboard in an informal design session.
• Scrum teams would orient to the Sprint Backlog and Sprint Goal every day at the Daily Scrum and discuss what they need to do to stay on track and deliver the outcomes they planned.
• Scrum teams would be self-organizing without external interventions. Teams would take full ownership of their outcomes.
• Team members would leverage the Retrospective to go beyond surface issues and understand the root causes of the team’s performance.

Bottom Line

Scrum Teams today are oblivious to the origins of Scrum and the ideals that the Scrum co-creators had in mind. When the COVID pandemic hit in 2020, the vast majority of teams went remote and became tool-centric. This allowed team members to work independently and asynchronously with little or no face-to-face communication. The tools also allow managers to closely monitor individual team members.