Total quality in tech startups to sustain hypergrowth

Bugs in the digital world are not a fatality! They demonstrate a great lack of agility of a company: its ability to deliver its products and services quickly and efficiently, whatever the problems its employees have to face every day. As Cecile Roche says in her interview with Scrum Life, Agility should not be confused with Agile. True agility is based on a strong problem-solving culture throughout the company. That's really what you're looking for in order to achieve rapid and sustainable growth.

In the software development world, I often hear people say that it is not possible to have a bug-free product. That zero bug is a utopia: that it's better to go fast and then fix it. This is not true. Fixing costs more and takes more time. Non-quality is present everywhere in the company and considerably slows down its growth: every time a customer complains, a piece of code crashes, a test doesn't pass, I have to redo a task, a spec is incomplete, etc... it has an impact on the deadlines and the teams' productivity. Ultimately, this impacts customer satisfaction and therefore sales. It also has a strong impact on operational costs and therefore on the company's profitability.

Many startups break their teeth on this false idea every year. They get into a vicious circle where they don't have enough cash to cover all the development costs because they are stuck in non-quality. They can't convince funds to invest in their company because sales aren't growing fast enough. These same investors are becoming more and more demanding and also ask startups to prove their ability to generate cash (between 24 and 36 months of runway). But to generate cash, you need to be able to deliver quality products and services quickly.

It's surprising that many developers don't consider quality to be their primary responsibility: building digital tools and quality code is much sexier than fixing our mistakes all day long! When we buy a new TV set, we expect it to work perfectly. The seller doesn't ask us to create a Jira ticket if we discover a bug. He doesn't ask us to take the time to fill in the ticket, describing all the symptoms with a screen printout to help him solve the problem. And then he doesn't leave us in the dark for months or years about the resolution of the problem. But that's what we do in IT.

We have even created concepts to avoid being really interested in quality: the bug backlog and technical debt. The bug backlog is where we park the problems that we look at from time to time. The technical debt, that is to say, the poor quality code that we have created in a hurry and that slows us down more and more, and that we never have time to deal with because we have to deliver features.
Bugs and technical debt are not inevitable: you just have to make non-quality your battle horse, starting by setting an ambitious goal of defect reduction, then visualizing all types of defects, teaching each person to solve them immediately as a team, and improving work standards. In other words: improve quality by developing people to accelerate delivery and sustain growth.

The concept of total quality is not new to the industry and some startups are really getting into it. Here are two examples of CTOs of digital startups who were inspired by a fascinating book on the topic, and started a total quality practice within their teams: Thomas, co-founder and CTO of Hokla specializing in digital product development in healthcare, and Flavian, CTO of Ocus, specialists in digital visual content.

The Toyota Way of Dantotsu Radical Quality Improvement

In this book, author Sadao Nomura taps into his decades of experience leading and advising Toyota operations in a wide variety of operations to tell the story of radical improvement at Toyota Logistics & Forklift (TL&F). While this book is about industrial operations, CTOs of tech startups are finding ways to apply its insights to software bugs

Find on Goodreads

Thomas first set up a visual system allowing each developer to spot quality issues as early as possible in the development process, all the way to the end user. He defined 4 types of bugs according to the Dantotsu method presented in the book. Each type represents a quality problem and the place where it was discovered:

• Type A bug: a bug discovered by the developers themselves on their own code in real-time, i.e. from the first unit test. The idea is not just to avoid passing a defect to the next step, but the developer himself wants to learn from his mistakes and share his lessons with his peers (wow!)
• Type B bug: a bug discovered internally by someone downstream of the process in which it was created, such as a bug generated by a developer and discovered by a Product Owner, or an error in a UX model and discovered by a developer
• Type C bug: a bug discovered at the last step of the process before the product is handed over to an end user, such as an internal or external QA team
• Type D bug: a bug discovered by a user, i.e. at the very end of the process

He aims for zero type D defects of course, and to achieve this he works on drastically reducing type A bugs. It has therefore set itself the goal of getting closer to zero type A defects. Each new bug spotted by the developers is immediately resolved by the team itself. Every week, they share their problem resolutions to learn and agree on the right ways to build quality code. Beware: quality code is not "sexy" code, it is code that meets the customer's needs and also avoids the famous technical debt. As a result, its teams of developers know how to produce quality code, well above industry standards. In the book "Code Complete" by Steve McConnell, the standard is between 10 and 50 bugs per thousand lines of code. At Hokla, developers generate only 3 bugs per thousand lines of code. Not zero yet, but real achievement. Thomas says it's a daily job. His next challenge: to convince ALL developers to work this way. The converts say they can't go back.

Flavian started his total quality practice by tackling the bug backlog. The team is conscientious and makes sure to insert bug fixes into their workday.  But the backlog keeps growing, and some bugs have been around for months or years. The team finds itself in a vicious circle. The problem is that fixing bugs is not enough: you also have to learn from mistakes and improve development practices. Otherwise, the bug backlog is a dead end. Flavian wants to make this activity a university rather than a hospital: not just fixing but learning from each defect and improving design and development standards.

He first set a goal of reducing the bug backlog by 50% over 6 weeks, which corresponds to solving 2 bugs per day. He created two key indicators, visible to all, which constitute the North Star: the number of unresolved bugs in the backlog, and the maintenance of the resolution rate of 2 bugs/day. Like Thomas, he classified the bugs by type and decided to tackle the many D-type bugs first, to protect the customers. Each bug must be the subject of a QRQC (for Quick Response Quality Control, which insists on both quality and speed), a practice that guides the developer in the investigation and resolution of the defect: today they choose to attack the most critical bugs to start the process, but the goal is to close all bugs. The QRQC allows them to put forward several hypotheses for a problem and to specify whether there is a development standard for the corresponding operation. This already pushes the developer to think about his method and not just to fix the bug.

Flavian spends a good third of his time facilitating these activities, and reflecting with the developers on their QRQCs so that they don't jump to conclusions. He tries to discover the developers' "misconceptions" (false ideas created by our inherent biases) and his own: it is the only way, according to him, to eliminate certain bugs permanently.

In addition, every week, lead developers present solved QRQCs to the others and to the Ocus bosses. The goal is to spread knowledge in the company, but also for Julien, co-founder, to better understand where the weaknesses are in his enterprise system.

What about you? When will you start your total quality practice?