Wicked problems

If Scrum were applied to software development, it would go something like this: (…) you form a team by carefully selecting one person from each pool. (…) You then give them a description of the problem to be solved (…), you further 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; STALL, 1990).

As I mentioned in the previous section, Jeff Sutherland and Ken Schwaber cite the article The New New Product Development Game, published in 1986 by Takeushi and Nonaka, as their main source of direct inspiration for creating the Scrum framework (TAKEUCHI; NONAKA, 1986).

However, it was the 1990 book Wicked Problems, Righteous Solutions that introduced for the first time the idea of applying the set of practices described by the two Japanese authors to software development. And it was in that same book, from which I highlighted the excerpt that opens this section, that its authors, DeGrace and Stahl, named this new way of working as “Scrum.”

However, the book doesn’t really offer a minimally detailed or even usable method of putting these ideas into practice. It was Sutherland and Schwaber who created the framework.

DeGrace and Stahl explained why the waterfall model (described in the Scrum is agile section of the chapter What is Scrum?) doesn’t work for software development and offered possible alternatives. Scrum appeared as one of these alternatives.

The book revolves around the idea that software is a kind of problem that cannot be clearly defined or detailed until we offer solutions to it (a wicked problem). In other words, each attempt to create a solution modifies the very definition of the problem.

For my students, I try to demonstrate this concept by asking the following: what almost certainly happens when we offer a new feature to a user? The person probably responds with something like: now that I see this working, I don’t think it should be like this… this I don’t need… that I need… etc. Or, at the very least, the user will probably behave quite differently to what we expected. For this reason, it is not possible to describe in advance, in detail, the features that the software should have to solve the proposed problems. As I already said in the chapter Why Scrum?, the definition of the product emerges over the course of its development and use. Or, as I always like to say, use defines the product.

Jeff Sutherland referred to the book Wicked Problems, Righteous Solutions in at least two articles he wrote during the early days of Scrum. He emphasizes this work as having a great influence on the introduction of Scrum at Easel Corporation. 

Using his own interpretation, Jeff sought to summarize the book’s conclusions about why traditional software development methods don’t work (SUTHERLAND, 2004):

• Requirements are not fully understood before the project begins.
• Users know what they want only after they see an initial version of the software.
• Requirements change often during the software construction process.
• New tools and technologies make implementation strategies unpredictable.

Jeff also highlights the All-at-Once model to describe Scrum as an approach where the team simultaneously does all the work needed to implement working parts of the product from end-to-end.