This is the 3rd article on Performance Teams, see here the category with the other two posts. 🖖
This post is divided into two parts: The first part is a story from the book The Machine That Changed the World written by James P. Womack, Daniel T. Jones, and Daniel Roos, as told by Jeff Sutherland in Scrum: The Art of Doing Twice the Work in Half the Time while the second part shares three cases of procrastination related to Quality, Vision, and Prioritisation in the business world.
Solve it the first time!
In the book The Machine that Changed the World, Dr. James P. Womack – founder and president of the Lean Institute – shares a story about the dangers of rework. 🇯🇵 🇩🇪
Jim and his team spent years travelling across various countries to study the largest manufacturing endeavour humans have ever undertaken: car production. He wanted to understand why some companies produced cars faster and with fewer defects than others.
Nowadays, any rational manufacturer uses what Jim termed “lean production,” but back then, things were different. One of the biggest gaps between manufacturers was in the luxury car market. In Japan, companies like Toyota, Honda, and Nissan spent an average of 16.8 hours producing luxury cars. Parts would enter one end of the factory, and around 17 hours later, a Lexus would emerge at the other end. These manufacturers averaged 34 defects per 100 vehicles. Not bad.
However, in Europe, the story was different. Companies like Mercedes-Benz, Audi, and BMW took 57 hours to produce a car and recorded 78.7 defects per 100 vehicles.
Why did European manufacturers take so long? And why did they have so many defects? BMW isn’t known for making low-quality cars. Here’s why: In a Toyota factory, any worker can stop the production line when a problem arises. When this happens, everyone gathers around the point where the line stopped – not to complain about the person who halted it, but to fix the problem. No one wants the cars to leave the factory with defects to be fixed later. They solve the problem then and there, and it’s fixed for good.
Otherwise, the same defect could end up appearing in hundreds of vehicles.
In European luxury car factories, production worked differently. At the end of the production line, dozens of workers in white coats would move around fixing all the defects. They made sure the BMW’s door made the distinctive click when closing, or that the engine purred just right. They ensured all the components fitted together perfectly. They didn’t see themselves as manufacturers but as artisans creating something beautiful.
This approach works well when you’re producing a small number of cars. But when you’re manufacturing millions of vehicles, these costs become too high. Womack states in his book: “In other words, the German plant was expending more effort to fix the problems it had just created than the Japanese plant required to make a nearly perfect car the first time.”
That’s right. The Germans spent more time fixing a newly produced car than the Japanese spent building one. Toyota became the world’s number 1 car manufacturer for a reason: they got it right the first time.
Cases of Procrastination
In the following cases, I’ve changed the [company names] to maintain privacy.
Procrastination due to a lack of Definition of Done or Quality Standards
Luiz Duarte, in his book Scrum and Agile Methods: A Practical Guide, mentions that while working at a tech startup in Rio Grande do Sul (Brazil), they were losing clients as quickly as they were gaining them due to countless bugs in their tool. He stressed that a well-defined Definition of Done could have solved this issue.
I had the same problem at [Stallion Security]. The daily bugs were unsettling our clients, and the number of new clients was almost equal to those leaving, meaning we couldn’t expand our customer base because the company didn’t have the budget to hire testers.
The procrastination in this case stemmed from the absence of clear quality standards. Without a well-defined Definition of Done, the team kept pushing incomplete work into production, leading to ongoing bug fixes instead of delivering a stable product up front.
Lesson learned: A good Definition of Done can significantly reduce bugs in production.
Procrastination due to a lack of Vision
At [OnTheGo], we sold software and services. There came a time when the programming language used to develop the software was light years out of date. When the IT heads of new clients asked which language the system was developed in, we hesitated to answer (classic ASP). To soften the blow, we’d say our IT team was working on a new version with a more modern language (.NET), which would soon be available for testing and installation. But that “soon” never came.
The lack of vision in this case led to continuous delays in addressing critical updates. Instead of tackling the problem head-on and upgrading the system, the team postponed innovation indefinitely, resulting in long-term damage.
Lesson learned: The price of innovation wasn’t paid at the right time.
Procrastination due to not understanding Priorities
At [GreenStar], everything was a priority, and we had a small team for so many incidents and issues to handle, and more than one product backlog for the team 😒.
Once, the maintenance team was split to solve three bugs in three different business areas.
A director from another department decided to shut down a system. This system served VIP clients who would be left without information. Ten days before it was shut down, I was invited to a meeting where I found out we would have to develop a new system to replace the one being shut off.
One of the three bugs was chosen as “less of a priority” and was replaced by this new task.
Three points to note:
- The delayed bug was in production and affected more than 60% of users, including VIPs.
- There was no prior planning to shut down the system. As the policy of “Whoever shouts loudest wins” was in place, the director knew he would be heard if he shouted loudly enough.
- The director had already set a shutdown date with the supplier.
Lesson learned: When everything is a priority, nothing is a priority.
Results:
- VIP clients were without the system for 5 days, as it was only delivered after the system shutdown.
- After going live, some VIP clients received 500 error messages. It took us two days to find and fix the bug.
- 60% of users were affected by the delayed bug for two weeks, which was only fixed after the other two bugs were resolved.
Conclusion
These three cases, along with Jim’s story, highlight the importance of addressing problems head-on instead of applying temporary fixes.
By adopting agile practices, defining a clear Definition of Done, prioritizing tasks, and paying attention to long-term innovation, teams can avoid the pitfalls of procrastination and ensure sustainable growth.
In the next article, I’ll talk about my third day in London. You can read the previous two posts here.
Until then, Dear Gentle Readers! 🧐
Precious Abstraction 
Leave a comment