Yet though we may need to think side-wise somewhat to spot it, there’s also one important catch to continuous-change. Continuous improvement depends on large numbers of small incremental changes; the smaller the change, the faster that all-important feedback/improvement cycle can run. But in perceptual psychology, small changes are invisible – a change has to be of significant size or occur at a significant before it becomes noticeable In a well-designed continuous-improvement process, often the whole point is that each change should be almost invisible, because it can reduce the stress of change, and allows potentially-challenging changes to be introduced by respectful ‘stealth’ rather than in a single overwhelming ‘big-bang’. But the more that the improvement-process succeeds in that task, the less anyone will notice each change – which means that the change-team may appear to be doing no work at all. Which is not a good career-move…

Worse, if no-one notices the change, and no-one seems to notice it, then perceptions of product or service may be stuck at first-impressions – which may be long out of date. As ITWorld columnist Esther Schindler put it, in her perceptive article “Why Users Dumped Your Open Source App for Proprietary Software“:

One thing that became apparent is that the lack of features is a perception that may have dated from a previous version. That is, “I tried it a few years ago, and it didn’t do what I needed then, so I chose something else… and haven’t thought about adopting the [software program] since.” If someone tried your app three years ago, back when it was all raw edges and bare metal, how will she know that it might be time to re-evaluate the options? … [She] may not realize that the version she can download today is far improved. Unless she goes out of her way to look, how likely is she to find out?

Sometimes the classic ‘big-bang’ Waterfall-style projects seem successful because their long release-cycles mean that the step-change introduced with each new release is large to be noticed. To quote Esther Schindler again:

One attribute of commercial releases is that major feature upgrades are announced with a lot of fanfare. That happens with open source applications that are household names (assuming an appropriately-geek household), but it’s rare.

…which means that some proprietary projects look better because they use a less-effective change-process. Not exactly a desirable outcome…

Part of this is marketing, of course: a big step-change gives a good excuse for an ‘event’ that’s much more noticeable than a quiet, continuous, stolid, ‘steady as she goes’. Yet that is a tactic that’s worth adopting in continuous-improvement processes: invent an ‘event’ of your own, to celebrate change and advertise the improvements that have been implemented since the last ‘event’. That way you’ll make the work more noticeable – and more valued.

There’s a subtle trade-off here. You’ll want every change to be noticed, but if you set the spacing of ‘events’ too close together, not only will the events blur together too much to be noticeable, but you actually run the risk of increasing people’s ‘change-fatigue’. A common practice in open-source software-development is set formal ‘release-events’ at six-monthly or yearly intervals, even though there’ll often be many ‘point-releases’ in the intervening period. Another useful tactic there is to use names rather than numbers to designate each major change.

Some typical themes in a ‘release-event’ might include:

• Summary of key groups of changes – keep this list short, no more than 5-7 items
• Acknowledgement of key people involved in inventing or implementing significant changes
• Linking process-enhancements to key performance indicators at the whole-of-enterprise level
• Celebration of the value of change itself

Keep each change and each change-cycle small enough to enhance improve effectiveness every day; yet also ensure that overall change is large enough to be visible and valued. That’s the balance we aim to achieve here.