Scrum

Traditional product development is often described as a ‘waterfall’ process: executives at the top give orders, and then designers design, engineers engineer, coders code, and so it trickles down until the program or widget is finally ready for market or manufacturing.1

In 1986, Hirotaka Takeuchi (b. 1946) and Ikujiro Nonaka (b. 1935) wrote an influential article in the Harvard Business Review that compared the typical waterfall process to “a relay race, with one group of functional specialists passing the baton to the next group.”2 They argued that the problem with the relay race model is that it is too slow and inefficient for face-paced markets. By the time the baton finishes its journey by going through one phase after another before finally landing at the bottom of the waterfall, it is either too outdated or bloated to be competitive.

So, instead of a relay race, Takeuchi and Nonaka suggested that a rugby match provided a better model. “Rather than moving in defined, highly structured stages, the process is born out of the team members’ interplay.”3 Imagine product development as a rugby play moving its way down a field: instead of simply going in a straight, linear fashion, the ball bounces and zigzags between different players. This kind of “built-in instability” means all the members are constantly interacting with the product, and with one another, in self-organizing teams operating “close to the edge of chaos to foster rapid system evolution.”4 Furthermore, a scrum allows ideas to percolate between players and across the whole organization, and not just trickle down from the top.

In recent decades, a multitude of ‘agile’ models and theories have proliferated throughout management circles. Agile here generally refers to iterative and incremental development models. Those two keywords, ‘iterative’ and ‘incremental’, require a significant change in mindset from the old top-down waterfall approach. Instead of simply issuing a decree for the minions below to fulfill, agile management means being open to the possibility that every player on the team might have a role to play in adjusting the trajectory of the ball in play. To be agile means to be adaptive. Business buzzwords, trends, and fads aside, this kind of radical adaptability requires a degree of collaboration that does not usually happen in waterfall models, where the baton is simply passed between silos like a hot potato.


  1. Royce, Winston W. (1970) Managing the Development of Large Software Systems. Proceedings, IEEE 26, WESCON, August 1970, 1-9 

  2. Takeuchi, Hirotaka. & Nonaka, Ikujiro. (1986). New New Product Development Game. Harvard Business Review. January-February 1986. 137-146, p. 137 

  3. Ibid 138 

  4. Sutherland, Jeff., Viktorov, Anton., Blount, Jack., Puntikov, Nikolai. (2007). Distributed Scrum: Agile Project Management with Outsourced Development Teams. Proceedings of the 40th Hawaii International Conference on System Sciences – 2007 p. 1 


Cite this page:
Shelley, James. (2020). 'Scrum' (in System Thinker Notebook). Originally published on August 5, 2020. Accessed on October 21, 2020. Licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Permalink: https://jamesshelley.com?p=17170
Additional reference and meta data:
This page is currently a subsection of 'Leadership in Complex Systems' in the System Thinker Notebook manuscript. Structure and document location subject to change. Use https://jamesshelley.com?p=17170 as permanent identifier/locator for this page if linking externally. Share this link on Twitter and Facebook.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.