Still not a fan of the PDCA cycle or the continuous improvement initiative

I’ve just finished the first decent draft of chapter 3 of the Agendashift 2nd edition and its segue into the more operational part of the book. Choosing my words here quite carefully: you can take this post as warning that I won’t be praising the PDCA cycle or the continuous improvement initiative. There, I said it. Heresy?

Last week I posted this question on LinkedIn:

Ask LinkedIn: Why does Lean Startup’s build-measure-learn loop seem often to sustain itself but the continuous improvement loop (PDCA) that inspired it typically run out of steam quickly? I’ve written on the PDCA problem more than once before and I have plans to do so again but I’m curious to know what people think [source]

36 comments and several good answers later, the one that best gets to the issue is this from my friend Patrick Hoverstadt:

My suspicion Mike is that this is structural – PDCA works ON the process, whereas build-measure-learn IS the process. If you stop doing PDCA, the work still goes on, product still gets produced and shipped and paid for, but it just stops improving. If you stop doing build-measure-learn, then the build part stops, so no product, and the business stops. PDCA shouldn’t be, but often is seen as an extra. [source]

The Agendashift book’s strapline is Outcome oriented change and continuous transformation, so I do need to get beyond just identifying the issue. Here’s how the new chapter 3 begins to tackle it (and for context, here first is the patterns picture):

[image error]

The […] myth is that change happens naturally in cycles. You plan an experiment. You do the work of the experiment. You check the results of the experiment. You act on those results. Rinse and repeat, one experiment leading to the next. The PDCA cycle () in other words.

Replace PDCA with another improvement cycle and the brutal fact remains: one experiment does not inevitably launch another. Improvement cycles are not perpetual motion machines; they do not sustain themselves. If ever you have wondered why continuous improvement initiatives seem to run out of steam so quickly, perhaps instead you should be wondering how they last any time at all.

Let’s look at two places where experimentation does seem widespread:

At the high tech startup
At Toyota, the inspiration for Lean

Size-wise, they’re at opposite ends of the scale. So what do they have in common? It can’t be the technology – many of Toyota’s experiments are remarkably low-tech. Common (and I would say glib) answers such as “leadership”, “sponsorship”, or “culture” don’t help much because their respective cultures are so different. There is a grain of truth to them though, and I believe the lesson is this:

Experimentation is sustained where these two things are true:

The learning that it generates matters to people
When that learning isn’t happening, it gets noticed

If you’re not a startup it would be inauthentic to pretend that your situations are equivalent. Even if genuinely you’re in a fight for survival, your organisation most likely has (or at least had) some viable business at its core; the startup lacks even that anchor. And don’t expect to magic up Toyota’s kaizen culture overnight – it took them generations after all.

Agendashift’s answer:

Experiments flow from meaningful outcomes and their measures of success (not rationalised the other way round), each experiment framed to ensure that learning will happen regardless of how it turns out
Experimentation is conducted in the full knowledge that multiple levels of learning will be accounted for in forums that matter

My advice is to abandon the notion of the cycle and to keep separate the framing of individual experiments, the day-to-day management of your active experiments, and the harvesting of learning. Of the three, the last is by far the most important; with the right focus on it, the other two fall into line behind it.

Hence the pattern Right to left strategy deployment, the right to left part signifying the working backwards from meaningful outcomes, the strategy deployment part a reminder (among other things) of ­the importance and relevance of the work. Solving problems just because they are there will no longer do.

A reminder of those three aspects to keep separate:

Framing experiments
Managing your portfolio of active experiments
Harvesting the learning

They’re covered across the final two chapters. The first two of those are well understood and the 1st edition covers them well. For the last one, which really means building a learning organisation, I’ll be pulling out all the stops, integrating (as Agendashift has done consistently for a long time) ideas and experience from Lean-Agile, organisation development, and strategy. Chapter 5 won’t be just the wrap-up chapter, it will be the climax, and I’m really excited about it. Happy to report that doing a 2nd edition is no drag