There has been much discussion on the forums about complex adaptive systems, agility, “all processes are design processes,” etc. This triggered a thought about the ability of agile methods to address “wicked problems.”
The concept of "wicked problems" in design was originally proposed by H. J. Rittel and M. M. Webber (1973, “Dilemmas in a General Theory of Planning”) in the context of social planning. They pointed out that in solving a wicked problem, the solution of one aspect may reveal another, more complex problem. Rittel and Webber suggested that the following rules define the form of a wicked problem: So what’s the problem here? The answer is wicked problems possess attributes that make them difficult to manage in a “top down” manner. And what’s does this mean an agile project manager? First is to recognize that problem solving is opportunity driven not plan driven. The challenge then is to create the opportunities. In plan driven processes, plans by their nature create the road on which to drive. “Plan the work, work the plan,” is a euphemism. From PMBOK, inputs to the planning process include: historical information, policies, constraints, assumptions. These result in a “plan” for the project. But this plan represents the fictional promise of those who built the plan in the absence of any tangible evidence that the plan can work. Sure there is experience, past performance, even assurances from all parties that they can delivery on their promises. In the end though it’s still fiction. Truth only comes during the “driving” phase. Criticism of the “Wicked Problems” Paradigm
The ten points listed above are not without their critics. First “wicked problems” share many of the attributes of “ill defined problems.” Ill-defined problems have no clear goal in mind. Finding the solution requires further definition of what the problem is. These problems belong to a class of problems called “Learning by Design (LBD).” As well they belong to the “group knowledge” domain. This connection is not obvious at first but hopefully I can make this connection without too much pedantic hand waving. The primary critisim of what’s to follow is likely to be – this is too soft for any real project management to deal with. How Humans Approach Wicked Problems
The first attempt to remove the ambiguity present in wicked problems is usually to produce “artifacts” of the goal, the planned progress toward the plan, and activities that are performed along the way to the goal. The result is usually documents of some kind. These documents represent specifications, agreements, assessments, more plans. “Plan in depth” is a phrase I remember from my distant aerospace days. In this artifact oriented world most of the work is focused on the production and review of these documents. In the vernacular of Rummler-Brache (Improving Performance: How to Manage the White Space on the Organization Chart, 2nd Edition, Jossey-Bass, 1995) the failures appear when there is no means of supporting the messy, informal processes that are described these documents.
The first approach when encountering a wicked problem or project is to jump to our tried and true reductionist techniques: The next approach is to apply some kind of methodology against the problem that may be non-traditional. This is we find agile methods – either development or project management. Both these approaches (reductionist and agile) fail to recognize the fundamental difference between wicked problems and hard but ordinary problems. Wicked problems are primarily “issues” problems not “solutions” problems. They are “creation” problems rather than “assembly” problems. Solutions to wicked problem arise through intuitive processes rather than logical processes.
Here’s where the standard – read traditional, linear, structured, normative – approaches get in trouble … Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them – Laurence J. Peter It’s the decidability aspects of the problem that create the trouble. There has been some discussion in the forums about the differences between hardware and software. I contend the primary difference is the number of indeterminate states for software is larger by many orders of magnitude than hardware. This creates a “decidability” issue – “when is the software actually working?” This in turn leads to the wicked problem type of project. Which is tied to the determinacy and decidability attributes of the problem. Summary
There are four strategies for coping with wicked problems. Notice the term “coping” rather than solving.
In the end the three (3) approaches to wicked problems mentioned at the top of this post have now come full circle, but now with four elements. So what does this mean for us agile project management types? First is to understand when we have a “wicked problem,” and when we don’t. When we do resist applying the reductionist and normative approaches in search of a solution. Finally the tenants of agile match closely with those of “wicked problems.” More connections and discussion is likely to prove useful.
