If Scrum was applied to software development, it would look something like this: (…) carefully choose someone from each team [traditional development phase]. (…) Then give them a description of the problem to be solved and (…) challenge them, saying they should produce the system in, say, half the time and money, and that it should have twice the performance of other systems. Then tell them that how they achieve this is their own business (DeGrace & Stahl, 1990).
Jeff Sutherland and Ken Schwaber frequently refer to the article “The new new product development game”, published in 1986 by Takeuchi and Nonaka in the Harvard Business Review, as the main source of direct inspiration for the creation of the Scrum framework. In this article, the Japanese authors use an analogy with a rugby game to show how development teams for new products (such as cars, printers, photocopiers, and personal computers) were doing their job in the 1980s.
The word “scrum”, which appears in one of the article’s titles, is a formation for putting the ball back into play in rugby. This is how the creators of Scrum named the framework.
However, there are many indications which suggest that Sutherland and Schwaber didn’t tell the whole story. This was taken from the book “Wicked problems, righteous solutions” (1990) and it was here that the idea first came up to use the series of practices described by the Japanese authors in the well-known journal, for software development. And it was in this same book that the authors, DeGrace e Stahl, baptized this new way of working as “Scrum“.
To be fair, it’s important to point out that the book doesn’t give in any way a detailed or usable method for how to put these ideas into practice. It was up to Sutherland and Schwaber to create the framework as such, with its rules, roles, events and artifacts, and get it working.
In the same book, the authors explain why the “waterfall” model doesn’t work for software development, and they offer possible alternatives, among them Scrum. The book revolves around the idea that software is a sort of problem which cannot be clearly defined nor detailed before solutions are supplied (a “wicked problem”). In other words, each attempt at creating a solution modifies the definition of the problem.
I try to demonstrate this concept to my students by asking them: “What are we sure will happen when we put a new functionality before a user?” The user will certainly respond with something like: “Now I see this new functionality, I see that I don’t need it, I need that, and that it should be like this…” etc. So we can’t detail beforehand all the functionalities the software should have to solve the set problem, we can only develop based on hypotheses. The definition of the product emerges during its development and use. Or, as I like to say, use defines the product.
Jeff Sutherland refers to the book “Wicked Problems, Righteous Solutions” in at least two articles he wrote in the early days of Scrum’s history. He highlights this work as a major influence on the introduction of Scrum at Easel Corporation. Jeff also highlights the “All-at-once” model described in the book, showing Scrum as an approach in which the multidisciplinary team carries all the work out simultaneously to create parts of the working product, point-to-point.
When in 2017 Knowledge21 brought Jeff to Brazil for the first time, I spent an afternoon with him and we had a chance to talk about various topics relating to Scrum’s history. But as far as I could gather, neither Jeff nor Ken ever gave due official credit to the authors of the book, or mention its importance with regards the original idea.
In no way am I claiming that Jeff and Ken aren’t the creators of the Scrum framework, since they defined and evolved its rules, roles, events, and artifacts, and put them into practice. But they certainly didn’t have the original idea to apply the approach described by the Japanese to software development, and they certainly weren’t the ones who baptized this Scrum.
Want to know more about Scrum?
DEGRACE, P.; STAHL L. H. Wicked problems, righteous solutions: a catalogue of modern software engineering paradigms. New Jersey: Yourdon Press, 1990.
SUTHERLAND, J. Agile can scale: inventing and reinventing SCRUM in five companies. Cutter IT Journal, v. 14, p. 5-11, 2001.
SUTHERLAND, J. Agile development: lessons learned from the first Scrum. Cutter Agile Project Management Advisory Service: Executive Update, v. 5, n. 20, p. 1-4., 2004.
TAKEUCHI, H.; NONAKA, I. The new new product development game. Harvard Business Review, Boston, MA, USA, v. 64, n. 1, p. 137-146, Jan./Feb. 1986.