Scrum: Working as a Cohesive Unit Through the Product Development Cycle — Skalar

Scrum is a product development methodology. You may have heard of Scrum before, maybe even used it, but where does the methodology come from and what are the ideas behind it? In this series, our product manager Christian Vestre goes a bit deeper and looks at the story behind what today is codified in the Scrum product development framework.

In the first article we talk about the original ideas behind scrum and where the name “Scrum” actually comes from.

Scrum: where it started.

After having studied some of the most innovative companies of the time, Canon, Fuji-Xerox, 3M among others, Takeuchi and Nonaka saw similarities between how these companies organized their product development teams, and how the game of rugby was played. In their paper, a section is named “Moving the scrum downfield”, which later led to the term we know today as “Scrum”.

They observed that instead of following the normal sequential product design and development, as exemplified by NASA at the time, these innovative companies followed a different kind of methodology. They had multidisciplinary teams in constant interaction working together from start to finish on the project. There were no handovers to separate teams for things like feasibility tests or production. Instead teams followed a holistic approach: a single team went the distance and worked on the whole product development cycle as one cohesive unit.

Scrum (or Scrimmage) in the sport of rugby, is a way to restart play. It requires technique and fine interplay and sets off an attack. Takeuchi and Nonaka chose this metaphor to represent what they observed amongst the companies they studied and their holistic, cohesive approach to product development.

“A team tries to go the distance as a unit, passing the ball back and forth.” -Takeuchi & Nonaka 1986 p.137.

The organizational dynamics behind successful innovative product development

  • Built in instability
  • Self organizing project teams
  • Overlapping development phases
  • Multi-learning
  • Subtle control
  • Organisational transfer of learning

Built-in instability

Self organising product teams

Overlapping development phases

Working together closely creates the possibility of miscommunication due to differences in perception, this generates what Takeouchi and Nonaka call “noise” which can build up to bottlenecks. However, due to increased understanding among team members, the group does not get stuck and is able to navigate these bottlenecks better than when following a sequential development process.

Multi-learning

Subtile control

Organizational transfer of learning

In addition to transmitting knowledge throughout the organization by letting less experienced team members learn from more experienced ones. There is also the approach of finding useful processes and institutionalizing them, meaning that successful routines such as retrospective meetings and regular status updates can be adopted in all projects and turned into the way the whole company does projects. A set of useful routines is what was later codified in the Scrum framework by Ken Schwaber and Jeff Sutherland.

For those of you who are interested, I recommend reading Takeuchi and Nonaka’s paper for greater detail of each additional supporting examples.

To summerize

The scrum metaphor came out of what Takeouchi and Nonaka observed with a holistic approach to the whole product development process. The way teams worked as a unit by exchanging information and working together more closely, became more commonplace over time, and led to more success in developing innovative products.

Later on Ken Schwaber and Jeff Sutherland further integrated these ideas, also taking inspiration from other areas such as Advanced process control (APC) to develop the Scrum framework as it is known today. Schwaber and Sutherlands Scrum framework was specifically intended for software development and is more specific to that than the more general observations made by Takeouchi and Nonaka.

In our second part of this article series, we will look at how and why this was needed for the methodology to become popular.

Want to get the latest updates from Skalar, simply subscribe to our email list to never miss another article.

Sources:

Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard business review, 64(1), 137–146.

Schwaber, K. (1997). Scrum development process. In Business object design and implementation (pp. 117–134). Springer, London.

Originally published at https://www.skalar.no on August 25, 2021.

--

--

Smart digital products, the skalar way. | www.skalar.no.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store