Blog
My thoughts on how to build better, more robust, more maintainable, more humane, and greener software.
Reading time: 5 minutes
Most organizations have some sort of system in place for making software. It's been tweaked over the years, maybe even designed by expensive consultants with the assurance that it will produce the results the organization wants. Everyone is expected to follow the system so that consistency is achieved and people's performance can be assessed fairly and accurately. So why are so many organizations struggling with delivering software late, and with too many defects despite having quality as an OKR?
This experiment was originally devised by Dr. W. Edwards Deming to illustrate how the system is responsible for variation, rather than the people following it. Here is a video demonstrating it (albeit with poor audio. If you find it hard to understand, see this one instead).
I recommend watching either video but if you can’t, here is a summary: a company makes a product from glass beads of two different colors. The final product’s quality depends on its color purity: having as little red beads as possible in the final mix is the objective. Workers are taught a specific and detailed way of scooping 50 beads at a time from the mix of beads and aren’t allowed to deviate from the method. An inspector then counts the number of red beads in the scoop, and anything above an arbitrary number is deemed unsatisfactory. As time goes by, the company struggles with quality issues from too many red beads. To try and improve things, the company introduces incentives like firing the worst performers, bonuses for the best performers, company swag and posters encouraging everyone to meet the quality objective, etc. As quality doesn’t improve and there are still too many red beads in most batches, the company eventually goes bankrupt.
As an outside observer, it’s rather obvious that the outcome is 100% determined by the system and not by workers’ skills. The overall number of red beads in the scoops will be a direct factor of the ratio of red beads in the original mix. And yet, management believes the workers are the main driver which it tries to influence with various coercive and encouragement techniques. As absurd as it looks, most organizations still work in this way: they devise a system that pretty much guarantees failure and waste. Workers are aware of it but aren’t allowed to speak up or make suggestions, so they simply endure it for a few years until they move on while the organization loses customers and money from the waste.
Everyone wants to feel proud of their work and is striving to do their best at the tasks they’re hired to do. But this is not enough on its own. Given enough time within a broken system, individuals will lose their drive.
Below are some ways to build a better system where everyone is empowered to improve quality.
Sharing ideas, suggestions, feelings, and thoughts within a team carries a level of risk for the individual. Psychological safety means team members can take these risks without worrying about being shamed, blamed, or punished by the rest of the team or by the organization.
Teams and organizations with low psychological safety are instead encouraging people to keep their ideas and thoughts to themselves, thus narrowing the pool of shared information and missing out on ideas that could improve the system.
Let me preface this by saying no postmortem is ever truly blameless. It’s human nature to try and blame things on someone or something as a way to discharge our anger1.
That being said, postmortems are a powerful tool for understanding what went wrong, and how to prevent it from going wrong the same way next time. But, without psychological safety, postmortems are an exercise in blaming the incident on someone rather than understanding what happened.
Although most resources on postmortems talk about blameless postmortems without acknowledging the fact that humans are hard-wired to blame, they’re still a good starting point for organizations to build their own process from. PagerDuty’s guide on the topic2 is a good starting point, for instance.
If the organization is striving for fast and cheap, something has to give. And that thing is quality. It sometimes makes sense to trade quality off, but I have very rarely seen it done right.
Not taking enough time to do things properly means that quality will suffer, making the “fast and cheap” solution very slow and expensive in the long run.
As seen in the red bead experiment, quality is determined by the system rather than the people working within the system. Management owns the system, which makes management responsible for quality issues that arise from it.
To improve quality, it is the system that must change: a well-designed system will result in improvements. Imagine how much the ratio of red beads would have changed if the red beads were picked off before scooping. Alas, management didn’t allow any suggestions (let alone changes) in the system, so nothing improved and the business eventually failed.
In a nutshell, Kaizen is continuous improvement. Whenever anyone (especially the individuals doing the job) can think of an improvement for process or tools, they should be free to pursue it and iterate on the solution.
Adding these little improvements up will result in less waste, yielding even more time and resources to come up with more improvements. And before long, quality will go up, people within the organization will feel better about their work, and customers will notice the quality uptick.
Think about it this way: an organization can spend most of its budget on waste from quality issues, or on quality improvements each year. The first kind of organization will be challenged to stay still, let alone grow. The second kind will reap the compounded benefits from less waste and can either become more profitable, grow, or both.
Employees and customers know which kind of organization they’re dealing with and will pick accordingly. The only thing more expensive than quality is the lack thereof.