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):
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 (<figure>) 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 🙂
Before you go, a couple of dates for your diary:
- 20 October, Online, 10:00BST (GMT+1), 11:00CEST:
Free webinar: Good obstacle, bad obstacle (EMEA) - 17-20 November, 8 online sessions (2 per day over 4 days) of 120 minutes each, EMEA-friendly timing:
Agendashift Deep Dive: Coaching and leading continuous transformation
Only a few places left for that first one. For the second, don’t hesitate to ask for a discount if you think you might qualify on grounds of country, non-profit, government, educational, etc. Also if you’d be a repeat participant, of which there have been a good number!
Related articles
- Agendashift as framework (April)
- On not teaching PDCA (March 2016)
- Good obstacle, bad obstacle (September)
What if we put agreement on outcomes ahead of solutions?
Agendashift™: Serving the transforming organisation
Agendashift Academy: Leading with Outcomes | Home | Store
Links: Home | Subscribe | Become an Agendashift partner | Events | Contact | Mike
Resources: Tools & Materials | Media | Books | Assessments
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter
Agendashift 
I agree with some aspects of this:
– Kaizen (as PDCA) is bloody hard to sustain
– In digital the difference between build and Do can be minute – so Do/Act can be the same sometimes
– build-measure-learn as traditional SDLC is much easier because that is closer to what enterprises already do … but it does not mean that it is right in my view. I have a big issue with planning. Though business needs planning, this is also about control in most organisation and this shuts emergence.
Digital/IT sucks at Kaizen. Yet, many automotive manufacturers / aviation manufacturers / etc. are operating Kaizen decently well. Not all Toyota level, but decent.
The reasons in digital are multiple:
– Leadership favouring command
– Inertia for leadership to change, the egos in banks are an issue / those are environment where putting pressure to borderline bullying is a valued trait of management
– work is virtual and invisible to them / this makes it difficult as well to determine how to do the gemba
– favours glass office management and seeing the work from RAG statuses
– Headroom not given to the teams (all their time is consumed by planned work / improvement headroom generally consumed as delivery buffer)
– Technology often considered as a delivery function, not an enabler of business, let alone a profit centre
– etc.
For me the major challenge is that everything has to float through the planning phase.
Any work, improvement, impediment identified has to route through a committee that will decide by ways of planning what it is useful to prioritise. This means that improvements never take a second look because we always prioritise big things / big impact. Overtime, this develops into competency gaps, operational debt, tech debt and plagues organisations.
This also kills autonomy – anything that is identified as worthwhile needs to go through the loop of a supra authority to decide if it is. This is removing autonomy from the teams. Removing autonomy removes critical thinking in standard work and kills emergence.
What we forget to say is that good Kaizen has a major impact on the culture and the team/System psychology of organisations. No Kaizen results in the opposite.
What would we want to happen?
• businesses that can improve from feedback loops
– Hypothesis 1 supporting Kaizen – a business that can improve from its own feedback is a good first step to improving from customer feedback (those are only different levels of feedback loops).
– by extension – A business that cannot improve is a business that cannot evolve and that generally is not even able to operate at its desired standard
– Hypothesis 2 – Allowing headroom for the teams to make improvements is a way to develop better skills / resilience / autonomy / collaboration in the teams that will contribute to limiting debt in standard work, better engagement, better motivation, feeling of purpose, team work, etc. This cultural element of Kaizen is major. It is in fact what most agile transformations are trying to achieve in terms of culture while never addressing the fundamentals of kaizen.
So, my argument is that Kaizen is super hard, but it is also an enabling constraint for getting many of the chips to fall into place. Once you achieve Kaizen, all the rest will align.
It is not because it is hard that you should give up. Kennedy said, we chose to go to the Moon because it is hard! Because it will unleash the best of what the nation has to give. Same for Kaizen.
Substituting it for build-measure-learn, which in most organisation means Plan – build – measure – learn – Plan in my view maintains the dysfunction of organisations that removes autonomy from the teams.
Kaizen is hard and that’s what makes it worthwhile.
Most of the automotive transformations from batch to flow actually had Kaizen as a central piece.
IT / Digital is no different, in fact it matters even more because experimenting is that much easier.
It is only that the Leadership really sucks at it, hence having to work hard from this.
Those are only my thoughts….
thx
p
From: Agendashift
Reply to: Agendashift
Date: Thursday, 8 October 2020 at 10:25
To: Philippe Guenet
Subject: [New post] Still not a fan of the PDCA cycle or the continuous improvement initiative
Mike Burrows posted: “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 cyc”
LikeLike