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.

Projects, #noprojects, language and thought

It's a truism that when you learn a different programming language, you learn a new way of looking at code. The language we use changes our abilities to think about what we're describing. The same principle applies to Orwell's Newspeak, the linguistic battlegrounds of social equality, to the fact that arithmetic is simpler in Chinese than in English.

So it's likely that the language we use to describe our work affects how we think about it and how we perform it. Last year for example a client pointed out to me an emotive stumbling block for participants new to agile methods - he found the standard terminology of Scrum alarmingly negative - sprint, backlog, grooming.

I've had roles with an interesting range of employers, on different types of of work. Real-life examples:

• 'Lift-and-shift' of a website from one web stack to another, with no user-visible changes
• Ongoing feature development of a website and its custom CMS
• Development of a social network application, segueing into product support

All of these have been software development for long-lived products, and we've described all this work as projects.

But only one is a project. And the confusion is harming us, as practitioners and as a community.

Project projects and non-project projects

PMI describes a project:

It’s a temporary group activity designed to produce a unique product, service or result.

Temporary duration to meet scoped business goals. If that annoys you because it doesn't describe your work, bear with me for a minute.

By the PMI measure, my web lift-and-shift was clearly a project.

Ongoing feature development was not a project, and while initial delivery of my social network was a project, the current support effort is not. These efforts have existing descriptors - product development and product support respectively. Together they're sometimes classed as BAU (business as usual), distinguishing them from the one-shot (and disruptive) nature of projects.

Note that I'm not suggesting that one is 'better', 'more legitimate', 'more hardcore' or 'more professional'. Clearly these are all crucial software development activities and the language to tell them apart can help us.

Why does it matter?

Simply because the different types of effort have different delivery and (whisper it) governance needs. For the dev team, BAU and support need no spinning up - there's already a product, a UX framework, an architecture, domain knowledge etc etc. And save for occasional 'major' releases there's probably no need to think much about go-live. This makes them fertile ground for a wide range of fantastic lightweight agile techniques. Projects are harder, and often mean a new team, a new set of stakeholders and business domain, new architecture, a deployment plan, handover, training and so on.

For management - the lovely people paying us to develop software - there's a predictable operating expense to BAU (OPEX - the cost of doing business) to maintain and develop an existing product with known business value. Projects are a riskier proposition. They create change in the business - that's the whole point - which means rocking the boat. They take capital expenditure (CAPEX - investment over and above OPEX). The manager has a fixed pot of money and it might go anywhere - Project X or Projects A, B and C, another server, more marketing or straight into the bank to earn interest. She has to have some reason to believe that Project X is worth the investment, which means some idea of what she's going to get, when and for how much.

How our language harms us

We throw around the 'project' to describe all of these activities, and it harms us as individual practitioners and a community.

As an individuals, the language of 'projects' blinds us to difference between the models. After all, it's all programming (or design, or system development or...). We try to apply approaches suitable for BAU to projects, techniques for projects to support, etc. Or we simply get confused why two pieces of work are shaping up very differently. This is not conjecture - I've seen extremely intelligent and skilled engineers declare 'OK but it's all just projects.'

As a community, we're engaged in a divisive debate between estimates and #noprojects / #noestimates. Each side has its impassioned advocates, and they see each other as variously as hidebound or naive.

But the clue's right there in the name. If you're not doing projects, then the #noprojects paradigm might be an fantastic fit. #noestimates might clear a swath of unnecessary overhead - even enable you to make more accurate forecasts!

If you're doing projects, this doesn't apply. Your investors still need...a project and much that comes with it.

What doesn't this mean?

This doesn't mean that projects are waterfall and #noprojects is agile. It might mean that projects sacrifice a degree of agility for a degree of predictability. How far you end up along the agile spectrum may depend on the appetite of the investor and the deftness of the team.

In similar vein, it doesn't mean that there's a hard-and-fast divide between the models. The team doing a project within a product that they support. The ongoing dev effort managed as mini-projects. There are as many ways to blur the lines as there are individual circumstances.

Where from here?

As a software delivery professional, my role is to create clarity and shared understanding. Part of that is agreeing a shared language. So I propose the following.

Within the class of Software Delivery we have three (maybe more) subclasses:

• Projects
• Product Development
• Support

Because they are all Software Delivery, some aspects of all three are very similar.
And because they have different technical and management requirements, techniques that are suited to one are not appropriate for another.

And perhaps we can re-frame the #noprojects debate. Rather than pushing dogmatic points on two 'sides' that now appear illusory, we can ask when are #noprojects and #noestimates approaches beneficial? What new tools can #noprojects and #noestimates thinking add to the seasoned software pro's armoury? And framed like this, might they even find applicability in the projects domain?

Naked Lunch and the shared backlog

The title means exactly what the words say: naked lunch, a frozen moment when everyone sees what is on the end of every fork"

William Burroughs, Naked Lunch

A minor incident ordering coffee

So I've noticed this lovely little coffee shop with an intimate atmosphere, comfortable seating and wifi. Win! I have to make a meeting after lunch, but there's no queue so I order my coffee and take a seat. Ten minutes later and still no coffee - it turns out that they'd taken a large order just before I walked in. I end up pouring my cup out into a takeaway cup and running back to the office. Luckily the client is later than me.

How did this go wrong? I expected usual coffee shop dynamics to apply, with a visible queue as a rough indication of how long I'd have to wait. But with table service, no queue...

A minor incident ordering takeaway

My wife and I are in a mood for takeaway. We spot a local Nepalese restaurant on a local online service, order and pay. It comes back and tells us that our food will be delivered in 1 hour. Damn. Normally I'd ask how long it will take before placing my order, but the website has removed that step from the workflow. And we're hungry!

Your project should be a Naked Lunch

Both times the assumptions that I use to regulate my order were violated. In the coffee shop, no visible backlog. On the online order form, no delivery time information. It worked out well for the suppliers - an order when I wouldn't have otherwise. But it's a very short-term win - I won't order takeaway online again and I'll be more cautious next time I visit that lovely little coffee shop. I need clear information to make an informed decision, to have confidence in my supplier.

It's almost facile at this point to suggest that the same applies to your project and your stakeholders. If you want your client to come back, they have to be confident that you're sharing the information they need to make informed decisions. And that means sharing openly. Backlog, risks, delays - the good and the uncomfortable. They have to see exactly what's on the end of every fork.

Fear and Learning

An interesting news story emerged this week: A fifth of hospitals are under-reporting mistakes that lead to avoidable patient deaths. To address this the government has launched a microsite on Patient safety in the NHS ranking hospitals by their safety data. It includes a category of 'Open and honest reporting'.

Increased openness - A great idea?

In 2005 Martin Bromley's wife died in hospital following a routine minor operation. Drawing on his experience in the airline industry, Mr Bromley managed to instigate an investigation with a focus on learning rather than blame. As a result, the investigation uncovered 'communication problems' that initially appeared to be within team, but were in fact a systemic issue across the healthcare system (sounds like they did a great job of popping the why stack).

Mr Bromley went on to found the Clinical Human Factors Group, a charity campaigning to prevent exactly the kind of avoidable deaths that are being under-reported. The BBC's Today programme interviewed him (go to 01:09 - available in the UK until Tuesday 1 July), and Mr Bromley's thoughts on the new website are worth quoting at some length:

My concern is that what we're trying to develop...is a culture of learning...where you balance learning and accountability. My concern here is that we might be naming, shaming and by implication blaming. What we really see is in organisations that do have a strong learning culture is a genuine desire to hear the bad news, a genuine desire to learn and I'm not convinced at the moment that simply naming, shaming is going to bring out the best.

Opening yourself to criticism makes you vulnerable. You have to overcome an emotional cost, and there's a risk of losing face in the organisation. Even critiquing a colleague can feel risky. In the NHS it can only be harder, where simple errors can have grave consequences. Mr Bromley fears that this new site raises the stakes, so makes open internal reporting less rather than more likely.

However taking and giving criticism are also some of the most powerful skills you can learn.

And so to Agile

A learning culture isn't directly part of the Agile Manifesto but it is a very congruent value. Of course it's embodied in Scrum's retrospectives. Retrospectives endeavour to create a safe environment for continuous improvement by focusing on the team rather than individuals. Scheduling retrospectives at fixed intervals, not in reaction to a crisis, makes them a routine learning opportunity rather than an investigation (with inevitable overtones of blame), and creates an opportunity to address small weaknesses before they become big problems.

The issue of vulnerability as a blocker to learning is also highlighted by Liz Keogh in her blog entry on How to run Safety Checks. If you don't know the technique it's worth a read. The bottom line: people can only open themselves up to this kind of learning if they feel safe.

Do we feel good about this?

Agile development is better at fostering a learning culture than healthcare? Yay us!

Wait a minute. That's 20% of hospitals under-reporting errors, ie 80% doing a faithful job. When we get to figures like that in IT, we can start thinking about feeling smug...

Bruce Lee and the Agile spectrum

I've been lucky enough to have practiced a range of the published Agile delivery methods: XP, Scrum, Kanban and now DSDM. And I've been doing this for 10 years now. Time enough to form some opinions.

Right now I feel that these techniques sit on a spectrum of Agility:

Winging it Too few controls Delivery at risk	more Agile <-----	Agile	-----> less Agile	Not agile Too many controls Delivery at risk
Co-hacking	Kanban	Scrum & XP	DSDM	Trad PM
Intimate communication Shared commitment Inexpensive Unconstrained Uncontrolled	Foster a Co-hacking-like work-style Owned externally to the delivery team 'Bottled lightning'		Agile-friendly governance Work-style-agnostic	PRINCE2 &c
	Focus on rapid delivery of highest priorities	Focus on inspect-and-adapt continuous improvement of product and team

Co-hacking

Hacking is a complex knit of ideas. Getting things done. Rapidly. Dirtily if necessary. On the one hand unconstrained sparks of genius. On the other, spikes that become rabbit holes and technical debt. Doing it your own way. No constraints, no controls.

At its best hacking is a beautiful sweet-spot for any creative professional. It's what Picasso did with his brilliantly innovative lithographs of bulls, an act of creative discovery without a known end-point. Co-hacking is simply my term for two or more practitioners working together - a pair of coders, throw in an IA etc. It sounds the team developing BBC Playlister worked this way.

Co-hackers have the Agile Manifesto almost down to a tee. Individuals and interactions - check. Working software - check (we hope). Responding to change - these guys can pivot on a dime. Customer collaboration? The customer's probably part of the team, so can't provide an independent steer. Even if there is an independent customer, she may not have much pull with the team

So as sweet as that spot is, co-hacking is not Agile. It's not controlled to deliver business value. But it is an important part of the spectrum.

Kanban

I was a Scrum practitioner when I first learnt of Kanban. It scared me. I understood the value of single piece flow. I appreciated the tremendous flexibility for the product owner in on-the-fly re-prioritising. But no fixed points? No obvious planning horizon? No opportunity to take stock? Challenging stuff!

Of course this places huge reliance and trust in an ongoing conversation between the customer and the team, and it engages the team to find their own feedback mechanisms. All this while letting the customer to re-prioritise at will.

So Kanban is perhaps unbeatably agile - more so than the rest of the spectrum.

More agile. Not necessarily better.

Scrum & XP

When I moved from XP to Scrum, they were already pretty similar. They've only got closer over time. Scrum teams routinely adopt XP technical practices - chiefly TDD but also pair programming. XP, which started with 3-month 'short' iterations, has converged on the Agile 2-week de facto standard, and has adopted retrospectives.

Scrum bills itself as a general-purpose Agile project technique suitable for all types of project, though you'll be hard-pressed to find it used outside the software industries. XP is explicitly intended for software delivery and includes technical practices. So it makes sense to consider XP a software-specific specialisation of Scrum (or vice versa - I don't mean to imply any precedence here).

Scrum & XP foster a co-hacking environment, with just enough governance to ensure that they keep delivering value. "Go make me some of these. Come back in 2 weeks to show me how well you've done." They're the 'bottled lightning' version of Co-hacking lightning, harnessing it to meet product goals.

And on the spectrum? They both provide time-limited iterations. Opportunities for the client to feed back and re-prioritise, and for the team to retrospect its own performance. For all the reasons that Kanban initially scared me, this structure provides a safety framework that is inherently a little less Agile.

Less agile. I didn't say worse.

DSDM

DSDM takes a very different approach to Agile. The other methods foster an Agile work-style with minimal governance, DSDM creates Agile-friendly governance but is agnostic about work-style.

Uniquely on the Agile spectrum, DSDM offers an up-front project timescale and cost. Just Enough Design Up Front and Timeboxes based on MoSCoW prioritisation (DSDM's approach to flexible scope) enable DSDM to offer the business a high-confidence timescale and cost, and fail-fast discovery if these are at risk.

Any responsible business considering a new project needs some confidence around cost and time to assess project value (Glen Alleman reiterates this point on his blog Herding Cats, and in doing so does us all a good turn). If you're offering software services as a third-party consultancy or agency, you'll definitely need some way to generate these figures.

But this confidence comes at a cost: a plan.

Yes there is still a Prioritised Requirements List (Backlog to the rest of you). Yes, the client still owns the priorities. But the very fact of having a project-length plan creates a resistance to changing that plan. Particularly the introduction of new high-priority capabilities, which will violate the plan. Then change control comes into play, something mercifully absent in the rest of the Agile spectrum.

So DSDM is distinctly less agile than Scrum, XP and Kanban. But not worse.

What about Bruce Lee?

Bruce Lee originally studied Wing Chun. By 1960 he was disillusioned with the artificial boundaries imposed by the martial schools so he founded a martial art philosophy: Jeet Kune Do.

I have not invented a "new style," composite, modified or otherwise that is set within distinct form as apart from "this" method or "that" method. On the contrary, I hope to free my followers from clinging to styles, patterns, or molds.

So you use the right tool or technique for the task. This kick exists in Kung Fu but not Karate? Use it anyway. You need a grapple from Hapkido? Go for it. It seems like the simplest wisdom.

Applying this view simply to the Agile spectrum: pick the methodology that best fits your project. Your customer has fluid requirements and a high level of engagement? Kanban may be just right for you. They need to know a cost and a date before they can commit funds? DSDM may be a better fit. Neither is inherently better and it doesn't matter which is more Agile - they're each a better fit in different cases.

Jeet Kune Do projects

The PM and/or Agile methodologies present themselves as 'whole'. XP is a great example, with a range of practices that support one another: unit tests, refactoring. If you don't employ them all, XP warns that you're heading for disaster (Matt Stephens entertainingly parodies this as a ring of poisonous snakes). Similarly with most methodologies, if you're not following enough of their directives you're not 'doing' Scrum/DSDM/whatever/delete as necessary. You're headed for the rocks.

This is good advice for neophyte Agile practitioners. Each methodology presents a coherent project delivery toolset. If you follow the teachings of a well-reputed school, you'll probably come out OK and start learning how it all fits together.

But this approach also encourages experienced practitioners to pick a school and stick to it. This is clearly nonsense - the existence of multiple successful Agile schools proves there's more than one way to skin a cat. Any given school is probably not a perfect fit for a given project situation, so we should expect more of the experienced practitioner.

Jeet Kune Do projects mix it up. Your client requires up-front commitment? Give them DSDM Foundations. They need an MVP in 3 weeks? Re-configure as a Scrum backlog and use some appropriate tool to track progress - burn-up perhaps. The team wants to operate with WIP limits. No problem. Minimum quality guarantees? Use a Definition-of-Done, or a defined Quality Level or Pair Programming or...

A JKD project practitioner makes herself aware of what the project needs from moment to moment. She knows the teachings of multiple Agile schools, of various Masters both great and small (Fowler, Keogh, Uncle Bob etc), perhaps even schools outside the Agile family (PRINCE2 et al). She understands what each tool gives her, which others support it and where to let go.

And one day, if I work hard, I'll be as good at Agile project delivery as she is.