Late to the party as usual. (With few kids activities for the summer and one child home from university all of a sudden I drive less).
I know David and Mike’s comments about task breakdown sparked controversy. It may not be what David Allen intended. It is what many people implement. (Which isn’t Allen’s fault). Even the next actions strategy can be flawed if the problem in question is far enough up the complexity spectrum (see below). If a problem is Complex - we should ask have I done enough on this item. If it is Chaotic the question might be have I stabilized the system. I wonder how many mis-applied GTD implementations boil down to enough thought about problem type.
Warning - partly in response to @MacSparky and @mikeschmitz comments I wrote an article on a sensemaking framework with an impossible name. This is a bit long for Discourse. Sorry:
Without knowing it, we encounter complexity whenever we’re asked to estimate how long it will take to fix a bug. Or we’re asked how long will take to bring a novel product to market. We don’t know we can’t know.
This is where Cynefin helps. Unfortunately, this theory has a complicated description. Cynefin is a poorly named mental model to help us see that different kinds of problems need different approaches. The word Cynefin is the Welsh word for habitat and is pronounced: kuh-NEV-in. (It took me several years to learn to say it, so you’re in good company if you’re confused.)
Its creator David Snowden calls it a Sensemaking tool, i.e. a tool to help you understand which domain your current problem lies in and what actions to take based on that fact.
That’s a fancy picture with a lot of words.
Clear Domain: (this was formerly called Simple/Obvious). In the world of software development implementing an algorithm that has an existing recipe is an example. Outside of software, it is any activity that is well understood or that you can find a recipe for.
It was Clear what the outcome would be from the start, implementation is a matter of execution. If asked you could have written down the steps involved in the work beforehand. With a high degree of predictability, Estimation is practical and the approach of estimating in terms of hours/days will be more effective.
In the Clear Domain write down the plan and execute it, things will probably go according to plan
Complicated Domain: In the world of software implementing a new feature with at least some acceptance criteria. Or building a new product in an area where the rough needs have already been understood. Outside of software, it is something that someone has done before, you know the problem is solvable, but you don’t necessarily know what the solution is.
From the starting point, you can see the rough end state. You couldn’t write the steps it would take to get to the destination, because they weren’t all known and the destination moved a few times along the way. As the destination and the individual work items aren’t as well understood, the work is less predictable. Relative Estimation, i.e. Planning Poker can be used as a tool to help people sense the volume of work and get a rough idea of which items are bigger or smaller. We often get requests to teams with more accurate estimation, in this domain that is simply impossible.
In the Complicated Domain, create a rough plan, start executing and adapt. In Product Development this is the classical use of Scrum.
Complex Domain: Both our bug and creating a novel product are in the complex domain. When we start they’re ill-understood. No one has solved this bug before. No one has built this type of product before. Outside of software, writing a book in an area that we don’t know well is an example. We don’t know if we can find enough information to describe the area well or even if the area is well understood.
From the starting point, we don’t see anything with clarity. Complexity can stem from the number of variables that affect our problem, the number of sources of information, or worse the number of completely unknown things. In this environment, we have very little predictability. Estimation in this domain is a waste, more useful is to time box an activity, saying “We will for some number of hours or days and see how far we get or what we learned.”
In a Complex Domain: run an experiment, and see what it tells you. When working on a bug, it may now be Clear or Complicated. When doing Product Development work, the experiment will tell us what problem our audience wants to be solved. As the problem is narrowed we can shift to normal Product Development work (i.e. the Complicated Domain). Effectively this describes some of the ideas behind Lean Startup and Lean U/X.
Chaotic Domain: The system we’re part of is off the rails. In the world of software development, this might be a key service that is offline. In the world outside of software, examples might include an oil pipeline that has burst and is leaking.
In a Chaotic Domain: take action and contain the problem. Chaos requires novel solutions and is typically transitory. Once the problem is contained, we want to move the problem to another domain i.e. Complex or Complicated.
Confused Domain: (Formerly called Disordered) We don’t know where we are.
Our job in this domain is to gather just enough information to sense which domain our problem is actually in and then act from there.
Cynefin doesn’t solve any problem for you, it is instead a “lens” to look at the world through. It helps you sense where you’re at with a problem and then make better decisions.
The version of this in our glossary: Complexity and the Cynefin Framework | Agile Pain Relief Consulting has links out to other sources on Cynefin.
