Agile continual improvement
Pursuit of improvement can hurt innovation. Agility is not how fast you can go, it is how fast you can change. So endless optimisation through continual Improvement can misdirect you
Doug Tedder is one of a group of ITSM writers who write good sense. He writes:
- Is there a point where you should no longer invest in being “faster, better, cheaper”? At what point should you focus more on innovation and experimentation and less on continual improvement?
...and cites Henry Ford's loss of the market as an example.
Continual improvement needs to be understood as not just incremental, and not just improving work.
It is about disruptive step change as well as increment, (but as seldom as possible: if you use the Toyota Improvement Kata you should track changing goals more smoothly with less disruptive change).
More importantly it's about improving how you work more than the quality of the work you produce (though both matter).
And most of all its about improving your business model too.
To use the Ford example, it's about improving what market you chase and what cars you make, not just how you make cars, and certainly not just improving the quality of the cars.
You need to completely rebuild the factory occasionally, and completely redesign the product other times, while most of the time you can change one work station at a time.
We like to imagine continual improvement as a smooth staircase of small increments, and I always counsel clients to evolution not revolution, but sometimes you need to burn stuff down.
We should disrupt our own business occasionally, in order to innovate. You have two choices: you can think of continual improvement as inclusive of all forms of improvement:
- incremental
- step change
- disruption
Or you can think of it as only the first one, but if you do that, make damn sure all three are still coordinated and connected.
And most of all, don't head off into the sunset in endless quest for better and faster tweaks on a frozen business.
Made in New Zealand 
