Seeking Radical Quality in the Tech Industry

A couple of weeks ago, I attended a kaizen workshop that focused on reducing the lead time for delivering a batch of software features to one of our customers.

At Sipios, we design and code websites serving organizations in the financial sector. For this specific customer, our team delivers new features to end users weekly. The delivery process starts on Thursdays at noon, with an expected lead time of three days. However, for the last few deliveries, it had taken around twice as long, causing major issues for both our customer and our teams, including:

• Skipped or delayed deliveries of critical features.
• Waste due to the quality department having to verify every single feature of the application several times at the final inspection stage.
• Frequent interruptions of software developers working on the next set of features.

The reason for this extended lead time was quality defects, called bugs in our industry. Not only were there many of them, but I was also surprised to see that teams were not prioritizing fixing and learning from those defects and often preferred working on upcoming features.

That kaizen session hit me hard, as it helped me realize that, as the chief technology officer, I was not creating a culture of “Quality First” in the company.

Coincidentally, I had just heard about Sadao Nomura and his Dantotsu method, the radical approach to quality improvement described in his book The Toyota Way of Dantotsu Radical Quality Improvement. Dantotsu allowed Nomura-san to achieve exceptional results in all the Toyota Material Handling factories he supported.

Those of us in the digital industry can compare the Dantotsu approach to Extreme Programming, a set of techniques used to achieve low levels of defects when writing software. As I read Nomura’s book, I became increasingly enthusiastic at the prospect of trying this method at Sipios.

In this article, I share the main lessons I learned from reading the book and how, in my mind, they apply to the tech industry.

Preventing Defect Recurrence

Simply speaking, applying Nomura’s eight-step method means taking every quality defect occurring in manufacturing through a complete plan-do-check-act (PDCA) cycle in just 24 hours. As Nomura-san says: “Speed is the key.” In practice, this means that to fix a problem, you must perform root-cause analysis, deploy the identified countermeasure, and swiftly initiate horizontal deployment through collaboration with the Quality Assurance function.

This approach is very different from the typical one that exists in the tech industry, in which:

• Only high-impact defects (those, for example, causing website outage or preventing the end user from performing basic tasks on the website) are given a thorough analysis, called a postmortem.
• Postmortems don’t include a root-cause analysis and never result in the identification of skill that is missing from the team and that caused the problem in the first place. The countermeasures will usually strengthen inspection by adding automated testing steps to avoid the bug from outflowing again to customers but will rarely trigger the creation of a standard or training for software engineers.
• Postmortems define long-term countermeasures that are typically executed in the coming days or weeks but never on the same day.

Using Visual Management

Nomura-san puts a lot of emphasis on visually managing defects, targets, and defect-related problem-solving exercises. While I’d expect to see this management technique in a lean book, two elements struck me. First, he doesn’t allow using computers; defects are always analyzed physically, notably on a Quality Management board. Second, he divides defects into two categories — those coming from manufacturing and those from the technical department.

Once again, the tech industry does this in a very different way:

• Bugs are usually tracked using software like Jira or Trello — the same tools tech teams use to manage feature development tasks.
• There is no clear separation between engineering and production, even though there are great benefits to be reaped from distinguishing between coding mistakes and software design mistakes (like wrong specifications or choices in technologies).

Preventing Defects in New Generations

A challenge Nomura-san faced was defect prevention when the production of a new forklift model began. At this point in the book, one would assume that quality is always the priority, regardless of deadlines. But, instead, Nomura explains how launching mass production of a new model should take 24 months and that the deadline cannot be missed.

The described strategy to achieve this focuses on prevention, to avoid as much as possible detecting defects during mass production or, worse, when the vehicle reaches the market and is in the hands of the end user.

Nomura introduced Simultaneous Engineering Manuals (SE Manuals) for incorporating learnings from previously introduced models (VA/VE), including manufacturing constraints. The manuals allowed the teams he supported to catch more and more defects at the design stage of the new model.

In the tech industry, too, many bugs are only found once a new website is released. And, unfortunately, the defects are usually the same for each new website launch, including:

• Improperly configured servers.
• Missing edge cases due to rushing the work to meet a deadline.
• The failure to handle a high-than-expected number of end users visiting the website.

The application of an SE Manual is not easy to translate into measures we can adopt in the tech industry, but if we look at VA/VE we can say we should focus on:

• Identifying the sections of the code where bugs are prevalent, which likely means that the features behind it are complex and should be either automated or avoided in future generations of products.
• Taking into account features that are already built into other websites, ideally reusing code whose quality is already “tested and certified.”
• Creating more standards, especially relating to the release of a new website.

In conclusion, I consider Nomura’s method a game-changer because it teaches us that there is no shortcut to reaching high levels of quality. As a CTO, I want to raise the quality bar in the entire tech industry, where we tend to view bugs as unavoidable time wasters. “Zero bugs” is the true way to go!

My team and I have already started to build visual management to try out Dantotsu at Sipios. I hope to write a follow-up article soon to share with you the results we are trying to achieve.

This article was originally published on Planet Lean, with the headline “Is radical quality possible in the tech industry?” on September 9, 2021, and posted with permission.