“If Scrum was applied to software development, it would go something like this: (…) you form a team by carefully selecting one person from each [traditional development phase]. (…) You then give them a description of the problem to be solved and (…) unsettle the team by saying that their job is to produce the system in, say, half the time and money and it must have twice the performance of other systems. Next, you say that how they do it is their 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 magazine, 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 titles of the article’s sections, 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. See the excerpt that opens this article. It was taken from the book “Wicked problems, righteous solutions” (1990). It was there where the idea first came up of applying to software development the series of practices described by the Japanese authors in the well-known journal. 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 provide 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 that I see this working, 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 defined problem. We can only create it 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 cross-functional team carries all the work out simultaneously to create parts of the working product, end-to-end.
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?
Read more articles about the framework
Take part in the training Certified ScrumMaster
References:
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.
