Agile Planning and the Cynefin Model

Many experts in the Agile community know of the Cynefin model. For those who may be unfamiliar with it, Wikipedia has a great summary of the Cynefin model.  I believe that Agile planning can best be understood by using the Cynefin model to provide context.

CYNEFIN DIAGRAM from wikipedia:

https://upload.wikimedia.org/wikipedia/commons/1/15/Cynefin_as_of_1st_June_2014.png

As a consultant, I’ve been aware of this model for at least 15 years. It was actually my father, an artist by profession, who introduced it to me. He was excited when he learned about it, but strangely, I didn’t understand its usefulness at that time, despite being an Agile coach. He really focused in on the difference between complicated and complex. As it turns out, that difference is the one that is critical to understanding the need for Real Agility in general, and what types of work situations warrant an Agile planning approach.

Cynefin and Real Agility

Over the last three centuries (yes, hundreds of years) we have seen, through the industrial revolution and the electronics revolution, more and more work become assisted or automated entirely by our tools. Robots make cars. Computers compute financial statements. The types of problems that tools automate completely are “obvious” or “complicated” for the most part… and many complex and chaotic problems are assisted by these tools.

Recently, in my training practice, I have focused more on aspects of leadership as I discuss Scrum, Kanban and other Agile approaches. A key element of leadership is planning. So over the last year or so, I have developed an approach to illustrating how Cynefin relates to Agile planning principles and practices.

Traditional Planning

The goal of much planning work is to help investors make decisions. By investors, I mean people who are going to pay (someone) to work towards a goal. The people who are responsible for planning are there to make the investors comfortable in starting or continuing to invest. In order for investors to have confidence, they usually expect plans to have a “reasonable” level of detail.

An example of this is planning a family vacation road trip. I’m in London, Ontario, and recently our family has been considering a road trip to Orlando Florida. To plan this trip, we need an appropriate level of detail that we can ensure that our investment (money, time, inconvenience) is going to be worth it, and make the decision to actually do the road trip or not. Part of the planning will be the actual travel: route, duration, stops, etc. and part of the planning will be about the time at the destination: accommodations, activities, reservations, etc. and part of the planning will be about preparation: packing, pet care-taking, emergency contacts, etc. At a certain level of detail, the trip is merely complicated: one can create a plan that has a very high level of confidence in being completed successfully. Once we get on the road, of course there are corrections that we make along the way, but barring major “chaotic” events such as serious illness, or a major natural disaster, the plan can be executed with a high level of fidelity.

This type of planning, which involves a high level of detail in specifying a solution to a problem, is only possible for “complicated” problems. We can analyze, algorithmize, engineer, construct, and execute plans for such problems. These types of problems can be solved with a very high level of certainty. The plans can be made with an almost arbitrary level of fidelity and detail. The “size” of the plan could potentially have millions or tens of millions of activities, but it is still fully-specifiable before execution.

In other words, with complicated problems, one can plan the complete solution. This is not the case for complex problems.

Complexity, Agile Planning and Real Agility

Agile methods such as Scrum, Kanban, Extreme Programming, OpenAgile and others all have in common the observation that complexity introduces a need for a fundamentally different approach to work. The most obvious impact of that change is in planning.

When coaching or training executives or managers in traditional organizations, the biggest mental hurdle is the planning fallacy in relation to complex problems. Most traditional organizations have gone through decades of greater and greater levels of effort, detail, rigour, and process to attempt to “solve” the planning problem. This is most obvious in IT work. Since the 1980’s, the Standish Group’s Chaos Reports have shown traditional planning approaches to result in a 20% (or lower) success rate for IT projects. This is terrible. And traditional approaches cannot change that number despite decades of work. (That’s a whole other article: the sordid history of planning in IT.)

The planning fallacy is that complex problems can have a planned solution. They can’t. Complexity by its very nature makes this impossible, except by luck. Complexity means that we have to explore the solution space… that we have to evolve our solutions… that we must be organic or fluid in our approach… that we cannot expect things to turn out exactly as we hope. At best, we can identify the problem and recognize that it is, indeed, a complex problem.

In other words, with complex problems, one can plan the problem only. The solution cannot be planned.  This is Agile planning.

In any method or approach that can lead us to Real Agility, everyone recognizes and embraces the mindset of complexity. In practical terms, this means that we minimize the amount of time we spend on planning. There are good psychological reasons for this: the psychology of sunk costs and confirmation bias are both powerful forces that will lead us astray in complex environments if we do too much planning. We become attached to our plans. We ignore it when our plans go astray. If we minimize our planning time, then we avoid these psychological risks.

This mindset can still be challenging to adopt. One of the most valuable aspects of our agile coaching service is to help people in an organization adopt this mindset.

The Other Quadrants

The Cynefin model has two other categories of problem: “obvious” and “chaotic”. About them, I will simply add that: 1) for obvious problems, no planning is necessary – we simply act based on habit, ritual, instinct, or memory, and 2) for chaotic problems, no planning is possible! – we simply react until we find our way out of chaos into one of the other problem spaces.

Although agile methods could be used in obvious, complicated or chaotic problem situations, they are ideally suited for the complex space. As more and more of our work gets automated with physical or electronic tools, we will need to become more and more comfortable with complexity.

Beyond Complexity

Complexity is not the only factor that makes long-term planning difficult.  The US Army identified three additional factors that describe aspects of a planning environment: volatility, uncertainty, and ambiguity.  The acronym VUCA was defined to describe these factors.

Is it any wonder that our plans so rarely work out as we initially hoped?

---

 

If you find this useful, please consider contributing with our
“Value for Value” model.