One of the take aways that I really valued from David Anderson’s Advanced Kanban Workshop was the value of selling evolutionary change as a low-risk approach to process improvement. He explained that the standard approach to change management consulting is paint to a rosy future scenario, page perform a gap analysis, page construct and implement a change exercise (training, restructuring, etc.) to bridge the gap, and then plummet into the J-curve and risk being fired before the organisation manages to claw its way out.
David Anderson’s Drawing of the J-Curve Effect
That’s an extreme simplification of a topic that actually required a couple hours of discussion, but it’s sufficient to lead to my next point.
The Kanban method stresses starting with the process you have now. Change nothing, just commit to improvement and implement tools to give you insight into the process, metrics to demonstrate improvement when it happens, and the short feedback loops needed to test ideas and adapt with minimal risk. This, David said, was an easier sell because it is less threatening (no one has their job title and responsibilities changed overnight) and is more likely to succeed.
So, I liked the idea and shared it with the attendees of my last Kanban workshop. One of them, a Scrum coach from Warsaw, asked whether an evolutionary approach could lead us to the same place as the traditional change management approach. Good question. I hadn’t thought about it before, but being an anthropologist by training, my answer was “no” and this blog post is about explaining why I said that.
I’ll enlist the help of a giraffe. His name’s Fred:
Like all mammals, Fred has a larynx controlled by his brain, and Fred is the product of evolutionary change. Fred’s larynx is just inches from his brain, because it’s at the top of his neck and so is his head, as you might expect. Fred’s getting impatient, so he bellows for me to get to the damn point. His brain got impatient first and sent the impulse to bellow right down that nerve to his larynx. A short trip? Not really. Silly evolution decided that the best way to route a nerve between one thing on the top of his neck and another thing on the top of his neck was to wrap it around his aorta first.
Here’s Fred’s laryngeal nerve; it’s about 15 feet long:
Now who decided THAT was a good idea?
That’s where evolution gets you. It’s a hell of a lot better than being a fish, at least from the giraffe’s point of view, but the evolutionary path from fish to giraffe has some constraints. The corresponding nerve in a fish makes sense. A straight line between a fish’s brain and its gills passes the heart, so the nerve crossing behind the heart is pretty sensible. Here’s the thing, though. Evolution starts with the existing processes and systems and changes them incrementally. Re-routing a nerve is not an incremental change; it’s a revolutionary change.
A change management consultant would propose a complete redesign, painful surgery, and a series of risky genetic experiments to redesign that nerve. They might even succeed if the giraffes didn’t object to the pain and risk and all the aborted monstrosities and ploughed through those experiments bravely focussed on the goal, but probably not.
In either case, you can’t step in the same stream twice. Will evolutionary change take you to the same place as revolutionary change? No. Will it be a better or a worse place? You’ll never know. The question isn’t which has a better result, but which has a lower risk of failure. I’d take a working giraffe over a dead fish any day.
Comments on this entry are closed.
This reminds me of the second edition of Extreme Programming Explained.
I remember that, when my friends and I read XPE2, many people objected to Kent “softening his position”, in particular by describing the XP practices as a journey, rather than a destination. It took me some time to see the wisdom in this approach, and looking back, I see it as an expression of the same idea: start by playing the ball where it lies.
Now, I encourage clients to adopt practices in a series of small, deliberate experiments. I suppose this is “kaizen”. I recommend using ideas in Theory of Constraints to identify more appropriate/less appropriate targets for improvement, so that we don’t spend too much time improving parts that don’t lead as directly to increasing re-investable “profit”. I recommend smaller experiments over wholesale change, so that we don’t run out of cash before the profits kick in.