Mapping Cynefin to the GDS agile delivery phases
What kind of situation is this?
That’s the question that David Snowden’s Cynefin framework seeks to answer, along with a follow-up: “And how should I act?”
If you’re not familiar with Cynefin, I really recommend watching Snowden explain it himself.
Recently I’ve been thinking about how these 4 types of situation map onto the GDS agile delivery phases.
In the Discovery phase, things are chaotic. There are lots of unknowns and even unknown unknowns. We need to remove any constraints on our ability to understand what’s going on and really delve into the whole problem area. (I’ll say more about Discovery further down.)
In Alpha, the situation is complex. We’ve got a good understanding of the problem, but not yet a solution that we’re confident in. In other words, the solution is emergent. We’re still learning, trying things out, and iterating. (Probe-sense-respond.)
In Beta, it’s complicated. We’re starting to get a sense for what good looks like, but we’re not quite yet there. We’re gradually scaling up, which gives us time to track issues, analyse them and make changes in response. (Sense-analyse-respond.)
When a service goes Live, solutions to problems become Obvious. (Or least they should do, if it’s gone Live at the right time.) We’re still tracking issues, but the nature of the issues we have now are recognisable to us. You could also call this phase “Business as usual”. (Sense-categorise-respond.)
The cliff between simple and chaotic
Snowden says that things move around the Cynefin diagram in a clockwise motion, which helps with our analogy because that’s of course also what happens with the GDS phases.
Well, really the situation doesn’t move itself around those phases. Organisations move the situation from Chaotic round to Obvious as it gets better at solving the problems it aims to.
But then there’s the “cliff.” This is what Snowden calls the space between Obvious and Chaotic. Of course, nobody wants things to get Chaotic, but they will because we get complacent and become exclusively set up to solve problems we understand, so we fall off into the realm of the Chaotic. At this point, you need to move fast and fix problems immediately. There’s no time for strategising, it’s action stations and short-term fixes. Act-sense-respond.
This is why the Discovery phase is so hard. They often happen when things have gotten so bad that it’s basically chaos, so everyone is calling for you to just deliver something quickly rather than wasting time with research.
If we could only ever launch a Discovery phase at the right time, just when the problems are starting to become too chunky and unusual to count as Business as Usual. Think of it like jumping off a cliff with a harness. It does sometimes happen, but it takes real vision to initiate and advocate for.
The important thing here is that things are going to get Chaotic if we get complacent, but to operate at scale we inevitably lose agility as we get comfortable with the nature of what we do.
So the question becomes:
How do we monitor our Live services, so that when the problems move from being Obvious problems to being Chaotic, we know it’s time for a new Discovery?
Unknown areas of disorder
The fifth area of the Cynefin framework is the bit in the middle: The area of disorder. I think it’s useful to mention this, because it’s the space we’re in when we haven’t worked out which area we’re in. I’ve seen loads of government services that don’t really know which area they’re in, or rather, they have a Live service but they’re also testing new bits of it.
Partly, this is down to scope being too narrow — We hardly ever zoom out to the whole service. However, it’s also down to not acknowledging that all 4 phases can be happening at the same time—Especially when we are talking about that whole service as users see it. The D-A-B-L framework was created for projects going through the spend approvals process, not whole services. The more we shift our thinking to services as users see them, the more we see that the way we’ve approved projects in the past means they don’t map to the service lens very easily.
For example, the service as users see it could be “Start a business” and there might loads of projects within that service at Discovery, Alpha, Beta or Live. Which phase the end-to-end service is in is a whole other question, but is also important if we’re to work out what are the most important improvements to make at any given time.
So what do we do about this?
Well, the first thing is to start categorising those services and projects that are in that state of disorder. Which phase does it feel like they are in? I’ve noticed a reluctance to admit that things are in Beta or Live if they haven’t formally passed through Alpha.
This is because you can’t move back a phase. You can throw away what you’ve done so far and start again, or you can ship what you’ve done, move through the following phases and come back round to Discovery. Depending on how much you realise what you’ve made is the wrong thing, either option could be right for a given team.
Once we know what phase we’re in, the key thing is to start getting really comfortable with the cyclic nature of the phases. We’ve got to get really good at moving things into Live, and spinning off new Discovery projects off the back of them. I’ve written before about why this is important.
And one last thing: We’re currently testing an idea at GDS to help Live service teams scope new work and get spend approval more easily. Get in touch if you’d like to know more and we can have a chat about it.
Background reading:
- Mapping maturity by Chris McDermott
- Using Cynefin to Solve Problems While Navigating Uncertainty by Kim Ballestrin
