It’s uncanny how easily tradition trumps common sense. Just recently I had a chat with a friend. He told about how he had started in the telecoms industry. He worked in a factory making infrastructure devices.
One of their customer requirements for a specific circuit board was called the ‘burn in’ process. The units were powered up and put in a large thermal chamber where the units would go through a 24-hour process of heating and cooling. The units were tested before and after this process before they could be delivered to the customer. The idea was to stress test all of the solder joints to reveal defects before the units shipped.
This ‘burn in’ phase took up a huge amount of resources and added over 24 hours to the production time. It was a profound productivity trap. But what could they do? The customer is always right, and they demanded it. This was the way it had always been done and so it must be in the future too. Right?
Tradition trumps common sense.
Luckily, my friend was one of the few renegades who wasn’t convinced. Something had to be done so they set out to demonstrate why the burn-in test was a residue of the previous century. They secretly put in the extra hours to collect the data of 200 units from both before and after the burn-in.
It turned out that the results barely changed in the process. The tests were completely unnecessary.
By going the extra mile and questioning the status quo, the team successfully shaved more than 24 hours off the throughput of the production line. That kind of time-saver can easily be worth millions of dollars in a factory.
In software testing, I often see a similar setting. There are test sets and testing phases similar to the burn-in process and it hasn’t occurred to the team to question the status quo. Tradition trumps the common sense.
Only twice I’ve met with a software testing team that had seemingly endless resources. Other one worked in the aviation and the second one was involved in the medical devices. Human lives were at stake. But for the rest of us, there will always be a limited amount of resources. And in testing, the resources usually are minimal at best.
The only way to make good use of the scarce resource is to constantly question which phases of the process are the burn-in and which are the absolute must. If you need of a good rule of thumb in questioning and prioritizing, the Pareto principle could be a perfect starting point.
20% of the activities contribute to the 80% of the results. My approach is to choose that most important fifth of the activities and then double down on them.
Don’t let the tradition trump common sense in your team. Don’t insist on doing things right but instead focus first on doing the right things!