Changing in the dark

A friend of mine rebuilt his PC. One expensive inclusion was dual SSDs in RAID0 configuration. I asked why this investment was so important. His first reply: “My PC now boots into Windows7 in 2-3 seconds. Isn’t that amazing?”

It is amazing performance.

I felt obliged to point out that he never switches his PC off.

Jim Womack tells a story in “Gemba Walks” of a company that put considerable effort into reducing the die change over time of a press (used for stamping out metal parts) from eight hours to 5 minutes. Turns out the press is only used to make one part, and never needs to change dies.

Making change is dangerous if we aren’t sure that we are getting better. Wasting the effort put into the improvement is bad; screwing with customer service can be fatal to a business.

Having a good idea is great. Please, have many more.

Be sure, before full implementation, that it is a step forward.

The best way to know we are getting better is to decide based on experiments, on actually doing the work the new way and demonstrating that it is better. Test it in a laboratory; prove it in the real process, then implement it generally.

How do we know we are getting better? Easy, we compare the experiment to our current performance. Which means that we must know our current performance in order to improve.

Only stable processes can be improved. Stable processes are processes that can be demonstrated to work the same way every time.

“But we don’t work the same way every time” is the common cry in IT departments.

This is True and Not True.

True: We don’t deliver the same code twice (if you are, then please stop that right now).

Not True: We work very systematically towards delivery of code. In fact, software delivery is a highly repetitive process requiring great discipline and co-ordination between participants, with everyone striving to deliver well to the next person in line.

Agile software delivery emphasises this – discipline is essential when compared to other software delivery methods because the team owns the outcome, and therefore the process. So Agile iterates and learns every iteration, aiming to be better next time.

I suggest that we cannot see the stable, repetitive nature of our processes because we look for the differences, not the similarities.

In case you were left thinking my friend is not so smart, his yardstick for the upgrade was gaming performance, not booting his PC, and SSDs in RAID0 make games blindingly fast. He is very happy with his investment, and is working on saying what he really means the first time. Pity, as I enjoy poking fun at him.

There was no such redemption for the people in Jim’s story. That was time utterly wasted. They tried to argue they had learnt how to reduce die changeover time, but they could equally have done that on a machine that needed it.

Goal!

No, not the Soccer World Cup, but the point of an activity or of a change.

A necessity in avoiding making changes in the dark is to have a goal. “I am changing the way we do this because…” or “I am doing this activity because…”

It defines the context, gives direction, aligns thinking. The goal of “Better relationships with my customers” reveals different solutions to wanting to achieve “Project Definition Workshops that deliver effectively on time”.

This is true when it comes to stabilising processes, and when changing them. Why I am doing something is the foundation for stability. If I don’t know the purpose of my process, I cannot make a good decision on the best way to achieve the outcome. If I don’t know why the change is necessary, I shouldn’t be making it.

A gentle hint: If value to a customer isn’t the core of your Why, have another go.

Don’t change in the dark. Understand what happens now, know why you are changing and make things Better Every Day.

Measuring to know where you are

I heartily support using measures to make effective decisions on change. I hate using measures for the sake of having a measure.

Measures are powerful. They are just as powerful when they are wrong as when they are right. Blindly measuring is dangerous – you are asking for unintended consequences that will powerfully drive you away from where you want to be.

The measure of die change over time went from 8hrs to 5 minutes. The customer benefitted not one iota.

If you cannot find a measure or set of measures that exactly line up with your goal, don’t use them. Look again.

More wisdom, this time from W Edwards Demming – avoid setting targets in your measures. Measures tell you how you are doing, and lose their value when people are gaming them to achieve the target that you set.

If you are really struggling for a measure try the basic Lean measure: cycle time – the time it takes from customer request to customer delivery.

The sweet reasons for cycle time

• Giving customers what they want sooner rather than later will always delight them.

• If I have less time, I have less opportunity to spend, so processes naturally become cheaper.

• With less time I focus on those activities that add value and I eliminate waste.

• Doing things faster frees up time to make changes to free up more time.

• It is simple to measure and understand.

• People love seeing frequent concrete outcomes, both customers and people in the process.

• It creates a virtuous cycle, with improvement leading to improvement.