Is Faster Always Better for Process Improvement?
We all know the old adage – if a man who’s bad at DIY is given an electric drill then all he will achieve that day is drilling more holes in the wrong places – process improvement just doing the wrong thing better?
When I started as an engineer I used to program using punched cards that came in a stack a foot high (I know that ages me and makes me look like a dinosaur – but hey, they ruled the earth for millennia longer than we have even existed). So back to the cards, when they were replaced by a computer to type in your code we all noticed 3 things:
- Yes it was so much faster to enter your code and get it compiled as the turnaround time was minutes not hours or days.
- Because it was quicker we relied in the compiler report to spot the spelling errors rather than spending the time to look through the code first and check it.
- As we were not doing that quality check then logic and data errors also went unspotted. The moral of this story is that faster meant quicker (compiling) but lower quality (poor code) and wasted time (repeat attempts to get it right).
No meetings on Fridays
When working for a large organisation in Hampshire, they had a business practice that effectively meant every week was four days of productive work not five. On Friday there was no programming, no client meetings, no hole drilling, just a day spent in reviewing the quality of the results of the week so far and planning what to do next week that would make things even better. This was initially a shock to those of us who were used to five full days of the nose to the grindstone, but this soon showed that
- collaborative teamwork really does work in improving quality and
- pausing and looking at it is much better than charging on regardless
For many years I have been an advocate of having to walk to the other end of the office to get a coffee, and having to wait while it brews. The walk is an amazing way of getting away from the computer and letting those intuitive inspirations bubble past the gale of mind chatter that is usually prevalent. The chatting to others whilst the coffee brews can also allow ideas to brew too.
So back to the opening question: When looking for an improvement is faster always better? Being a quick typist (or engineer, or chef) is better than being a slow one, but it is more important to be doing the right thing and at the right time.
So that then brings in the question of Is it better not to do that thing now at all, and leave it till later, or never? – The short answer is often Yes. Have you noticed that the pile of papers on your desk that never all gets done (or the list of emails that never get below an inbox of a few hundred) will contain items that are so old you have missed the deadline completely? So many things in what we are asked to do (or told are important to do now) are in fact low priority or completely useless to the real stakeholders.
The Agile Angle
All of this has, over the last decade or two, been synthesized into a approaches such as Agile, that encourage collaborative working in short cycle deliveries. But essential to the concept is that
- you define what will be done before you start and
- you have a retrospective when you get to the end of that cycle and see what worked well, and what could be improved.
Not rocket science – but even rocket scientists break large problems down into solvable pieces too.
Time for a short walk and a coffee now.