Dienstag, 27. Dezember 2011

Kaizen and Snails

For me Kaizen is the core of Kanban. And as a model for Kaizen, I still find Deming‘s PDCA Cycle very useful. Many people out of the Kanban community find Boyd‘s OODA Loop more suitable. One reason for this is that PDCA comes from the production world and when dealing with Software Kanban, we often have the problem of justifying ourselves why we use models from the production, although we operate in the domain of knowledge work. The other argument for the OODA Loop is: PDCA focuses rather on the past while OODA is more focused on the future. I think the old saying applies here as well: "All models are wrong. But some are more useful than others." Depending on the context, one might find the one or the other model more useful. And in my opinion, it is crucial that we have at least an idea of how to achieve a culture of continuous improvement – and what obstacles we need to remove in order to get there. Whatever model helps us here, should be welcome!
One phenomenon that sometimes can be observed as an obstacle to such a Kaizen culture can be called the PD-Snail. And to show and discuss this phenomenon, the PDCA cycle is very useful.
The basic idea of PDCA is that we first agree upon the next small step for improvement (Plan). We then try this out (Do), check the results and reflect on them (Check). After this we decide in the Act step, whether we want to roll out and standardize the results (however this standardization may look like in detail), if we want to change something in our experiment, or whether we want to abort the whole expermient and try something completely different.


So far so good. In practice, however, we sometimes observe something different: We make a plan (P) and begin to implement it (D). But instead of checking the results seriously (C) and adapting to our new findings (A), we immediately start making a new plan (P ') and implementing it (D'). C
' and A' are again not taken too seriously (yes, it is not always very much fun to go through the whole cycle), so that even the next plan (P'') is formed, etc. The result is the PD Snail that looks like this:


The advantage of this visualisation is that you have a basis to discuss various aspects of improvement:
  • Does the PD-Snail look familiar to us?
  • If so, what does that says about our focus?
  • Is it a good thing to start more more and new improvements, without ever bringing them to the point that we can at least learn something from it? Or is this pure waste? (This is a rhetorical question)
  • Do we really have to deal with this snail? Should we perhaps limit the number of current improvements?
  • What else can we do to become better at improving?
  • ...

And there‘s another big problem with the PD-Snail (thanks to my colleague Markus Gärtner for pointing this out): According to the Satir Change Model, any change will lead to decreased performance and a state of chaos. If we (as indivicuals, teams, or organisations) are not capable of stabilizing, then we won’t improve, but instead we will harm ourselves. In order to stabilize, we often need a long breath (and probably a lot of small adjustments). But the PD-Snail does not have a long breath. It “jumps” (okay, snails cannot really jump) from change to change without ever completing something. So in the long run the PD-Snail might lead to poorer and poorer performance, although it was aimed to do the complete opposite!

Without a doubt, the PD-Snail is as a rather unpleasant fellow. But it gets even worse! May I introduce: The
P-Snail. Here, the C-aspect of the improvement is also omitted. Instead, a great plan after another is thrown into the room: "We have to do A." "Yeah. And we could also do B." "Good idea. And how about C?" This phenomenon is known as paralysis. And in another context we call it the students‘ imperative: "Someone really should clean up the kitchen " (general consent among all room mates before everyone gets himself another beer and disappears towards the television set).

Another relative is the D-Worm - also known as
blind activism. Here we act over and over again, without ever planning even the smallest bit. That wouldn‘t be bad in itself, because in some situations it may indeed be quite useful to try things just to see what happens (according to the Cynefin Framework, this would be be a reasonable approach for the chaotic domain). However, this activism seems to be of little help if there is no reflection on the outcome afterwards.

At the end we should briefly mention the
Retrospectives P-Snail: This means, we‘re only whining about lost chances: "We should have done A.", "Yes, exactly. And if we only had tried B!" Of course it is helpful to regularly look to the past and think about what opportunities we may have missed. But if it never results in ideas and actions for the future, then we should probably do something more useful instead.

For some teams, the idea of the PD-Snail will hopefully be useful. Others might find it silly. I think it's a useful little tool to discuss and reflect on improvements. And it's a good way to show that improvements cannot simply be established on the fly, but that often hard work and patience are needed.
Please leave a comment, tell me what you think and share your experiences with different types of snails!

Keine Kommentare:

Kommentar veröffentlichen