Cynefin Complexity - a new perspective on old Wickedness

The Cynefin Framework overlaps with earlier work on Wicked problems. Both have things to say about sophisticated software development, and both point towards agile techniques for delivery. DSDM seems to have a trick up its sleeve to meet the challenges of wicked problems.

Something New

The Cynefin Framework - wikimedia commons

In the past couple of years Dave Snowden’s Cynefin Framework has captured imaginations in the software industry. Snowden proposes that problems and activities exist in one of several domains through which they can be better understood: Simple, Complicated, Complex and Chaotic:

I'm not going to go into the framework in any great detail here. You can find out all about it on Wikipedia, on Snowden's own company, or all over the web.

Snowden recommends operating in the Complicated and Complex domains, and some commentators have suggested that this is the natural mode of software product development. Day-to-day coding sits largely in the Complicated domain, which requires specialists who can apply acquired expertise and perceive Good Practice solutions. Product and project thinking sit in the Complex domain: we make a small change, understand its effect on the product and on users, and modify our plans accordingly. It’s a nice characterisation of agile approaches.

Something Old

Wicked problems were first characterised in the late ‘60s and early ‘70s:

1. The problem is not understood until after the formulation of a solution.
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not right or wrong.
4. Every wicked problem is essentially novel and unique.
5. Every solution to a wicked problem is a 'one shot operation.'
6. Wicked problems have no given alternative solutions.

This is a great description of software dev:

The problem is not understood until after the formulation of a solution.

The delivery process explores its own requirements, and invariably exposes complexities that the client hadn’t considered.

Wicked problems have no stopping rule.

There is such a thing as too little development and too much, and often a large grey zone around 'just right'.

Solutions to wicked problems are not right or wrong.

Any business requirement has multiple legitimate solutions. Some will be better than others.

Every wicked problem is essentially novel and unique.

Otherwise an off-the-shelf solution would already exist and the work would be unnecessary.

Every solution to a wicked problem is a 'one shot operation.'

If we fail, (as an internal team or a contracted consultancy) the client won’t have the money or the time to try again. And if they do, it certainly won’t be with us!

Wicked problems have no given alternative solutions.

No off-the-shelf solution.

A Cynefin perspective on wicked problems

It feels like Snowden’s Complicated/Complex boundary has things to say about wicked problems:

The problem is not understood until after the formulation of a solution.

Emergent characteristics of the Complex domain.

Wicked problems have no stopping rule.

Probe - Sense - Respond applied to stopping as well as to continuing.

Solutions to wicked problems are not right or wrong.

Beyond the domain of Best Practice, into Good Practice and Emergent Practice.

Every wicked problem is essentially novel and unique.

Hence the need to Probe - Sense - Respond.

Every solution to a wicked problem is a 'one shot operation.'

Big Design Up Front is dangerous - again why we prefer to Probe - Sense - Respond.

Wicked problems have no given alternative solutions.

Hence no established Best Practice.

A new representation of old observations can be fruitful - Mendeleev’s arrangement of the periodic table is a classic example. I generally find Cynefin frustratingly vague, and Wicked problems provide it with a concrete context that I can understand. The Probe - Sense - Respond approach partially dismantles Wicked Challenge 1 (problem not understood until after the solution) and Challenge 5 (one-shot operation). Of course this is part if the core of the Agile paradigm.

Cynefin also nicely characterises what clients hire consultancies for. Simple problems they can manage by themselves. The Complicated and Complex domains encompass activity where specialists can add expertise and value. Even the Chaotic domain has value for innovation spikes.

Wicked projects and DSDM

Agile approaches meet Wicked Challenges 2-6 very well. They generally address Challenge 1 only in iteration - The problem is not understood until after the formulation of a solution. This is fine for ongoing product development, but perhaps insufficient for projects with a discrete start (and end).

Waterfall methodologies have a partial solution. PRINCE2 has an Initiation Stage with a go/no-go gate preceding full delivery. At the end of this, the team should have given due consideration to the problem space and to alternative solutions. But PRINCE2's up-front approach to planning, with an expectation of minimal engagement, makes it fragile to unexpected change. It doesn’t Probe - Sense - Respond.

DSDM has a nice trick here - an agile method with an 'Enough Design Up Front' mentality. It directly addresses Wicked Challenge 1 with explicit Feasability and Foundations phases. At the same time, its principles of ongoing client collaboration, iterative delivery and flexible, prioritised scope retain the responsiveness required in the Complex domain.

Wicked problems and #noprojects

In my previous post I suggested that there are three equally legitimate modes of software development: projects, product dev (which I aligned with #noprojects) and support. How do these modes support Wicked problems?

When clients hire consultancies, it is almost inevitably project work. A start date, a fixed budget and therefore an end date. We'd better hope then that projects can satisfactorily address them - I've made a case above that by combining up-front preparation with ongoing agility, they can.

Product dev teams operating in the #noprojects mould are ideally placed to engage with Wicked problems. On the ground on an ongoing basis, they can continue to Probe - Sense - Respond and keep improving the solution. This may make #noprojects a better fit than a project or an external agency, if the company can afford and manage its own team devoted to the product.

Support mode is a poor fit for Wicked problems. A team focused on support is trying to address discrete issues as they are raised, and is unlikely to give a Wicked problem the all-round consideration and the iterative attention that it requires. We've all seen support teams continue to fix point problems without addressing the underlying root cause. Once they step back and recognise a Wicked problem, the team often drops out of support into one of the other modes - project or product dev, whichever suits them best.