Agile Software Development: Wicked Problems
 
Mary Poppendieck has an interesting article, Wicked Problems, in Software Development magazine, May 2002. She notes that SCRUM is an excellent adaptive project-management approach for wicked software development projects. In fact, Degrace and Hulet's book, Wicked Problems, Righteous Solutions, Prentice Hall, 1990, was one of the inspirations for the invention of the SCRUM software development process.

An enlightening aspect of this article is documenting who coined the phrase, "wicked problems," i.e. Rittel, H and Webber M. Dilemmas in a General Theory of Planning. Policy Sciences, Vol. 4. Elsevier, 1973. A wicked problem has these characteristics:

1. Wicked problems have no definitive formulation. Each attempt at creating a solution changes your understanding of the problem.
2. Wicked problems have no stopping rule. Stakeholders, political realities, or resource issues change the end game.
3. Solutions to wicked problems are not true-or-false, but good-or-bad. No definitive formulation and no stopping rule means the only success is when the stakeholders "feel good enough."
4. There is no immediate or ultimate test of a solution to a wicked problem. Any solution generates a wave of unpredictable consequences.
5. Every implemented solution to a wicked problem has consequences. Unanticipated side effects are the norm.
6. Wicked problems don't have a well-described set of potential solutions. Stakeholders have different views of what is acceptable.
7. Each wicked problem is essentially unique. The art of not knowing too early what solution to apply is critical. Decision making must often be delayed until the last possible moment to allow for changing requirements and technologies to assure success.
8. Each wicked problem can be considered a symptom of another problem. Changing constraints and interlocking issues are embedded in a social context.
9. The causes of a wicked problem can be explained in numerous ways. Stakeholders have varying views on what the problem is, who or what is causing it, and how to resolve it.
10. The planner (designer) has no right to be wrong. Scientists formulate hypotheses which may be tested and found wrong. Designers are not allowed to be wrong. They must get it right the first time.

I've been a VP of Engineering or CTO of nine companies. The goal for me at every company was to solve a wicked problem. That's why SCRUM was invented and why it has been used extensively in the last five companies.