Fifth article on quality in Lean Software Development. In previous posts, we talked about how to build with quality through mistakes, technical design, collaboration, and visibility. Now we address a key topic: why many organizations still don't work this way, and what we can do to change that.
In the world of software development, there is a persistent myth: that quality and speed are opposing forces, and that one must be sacrificed to obtain the other. However, the reality, as demonstrated by the DORA reports and the experience of high-performing teams, is that quality is the most direct and sustainable path to the highest possible speed.
There is a fundamental paradox: the more we obsess over immediate speed at the expense of quality, the slower we become. Teams that accumulate technical debt, unresolved bugs, or hard-to-maintain code make each new feature exponentially more expensive. What seemed like a "pragmatic" decision becomes a burden that slows down the entire system.
True pragmatism aligns with Lean principles: postponing decisions until sufficient information is available, applying YAGNI (You Aren't Gonna Need It), keeping design simple, and constantly iterating to have the simplest version of the system that meets current needs. That is being truly pragmatic.
It’s important to understand that in the age we live in—of continuous change and software adaptation—when we talk about the “medium term” we actually mean a few weeks. We are not talking about months or years to see the benefits of quality. The effects of working with quality are noticed very quickly, and that supposed short-term trade-off only makes sense for throwaway software.
In Lean thinking, the way to have more impact is to minimize waste, with lack of quality being one of the main wastes in software. So the winning combination in software development is to maximize impact, minimize the amount of software generated, and do it with quality in the process. The approach is not to do things worse or faster, but to be smart and disciplined to achieve more impact with less, and with quality. This is the true way to go fast, achieve maximum impact, and be a sustainable high-performing team.
Common reasons for not working this way (frequent resistances)
Pressure for short-term speed
"We don't have time to write tests," "it has to be delivered now." This is the classic one. However, as we've already seen, well-integrated tests in the development flow allow faster progress at lower cost in the medium term.
In environments where immediate output is valued, investing in quality at the start may seem slower, but it prevents a greater slowdown even in the short term. We're not talking about benefits that take months to arrive—in a matter of weeks you can notice the difference when technical debt doesn't accumulate and waste is kept under control. Lean practices are often misinterpreted as an initial brake, but their true value becomes clear when the system starts to fail and the real cost of not having invested in quality becomes evident.
Misalignment between business and technology
If the business only measures visible deliveries (features) and does not understand the value of refactoring, tests, or simple design, perverse incentives arise that push to avoid everything that isn't “visible.”
Here it's necessary to align incentives, showing with data that investing in quality generates higher returns. Moreover, the waste of building unnecessary or misunderstood features skyrockets when this alignment is missing. Let’s not kid ourselves: the fundamental waste in product software development is implementing what’s not needed, and maintaining it for the lifetime of the product. We already know that the basal cost doesn't apply only to features that are used.
Lack of training or experience
For many people, this way of working is new. They haven’t seen environments with trunk-based development, TDD, or real automation. If they haven’t experienced the benefits, it’s normal for them to distrust or underestimate them. Some of these practices require a significant mindset shift and specific technical skills that take time to develop. Investment in training and mentoring is key to overcoming this initial barrier and building the confidence needed in these methods.
Fear of change
Fear of the unknown is a natural human response. Many teams feel comfortable with their current processes, even if they are inefficient. Changing established routines generates uncertainty and resistance. This fear can manifest as skepticism ("this won’t work here") or even passive sabotage. The transition requires effective leadership, clear communication of expected benefits, and the creation of a safe environment where experimenting with new methods is valued and supported.
Lack of structural quality
Some teams want to work with quality, but they already have a system full of debt, without tests, without confidence. Changing it requires an investment that the organization is often unwilling to make. Here improvement must be incremental, with visible wins: reducing deployment time by 10%, fixing the 3 most critical bugs, etc. Establishing “clean zones” in the code and gradually expanding them can be an effective strategy to regain ground without needing a full rewrite.
Organizational inertia and rigid structures
If teams lack autonomy, if decisions are made top-down without technical feedback, or if release, QA, or security processes are outside the team, it’s hard to apply jidoka or react quickly to problems.
The system inhibits quality, and the waste of time and resources increases exponentially while problems persist.
Culture of blame and punishment
If the organization doesn’t tolerate mistakes, if it looks for culprits instead of causes, or if incidents generate fear instead of learning, errors are hidden instead of made visible. And without visibility, there is no improvement, nor can waste be reduced.
Fear paralyzes innovation, delays problem identification, and hides waste at all levels.
Even if it sounds exaggerated, many organizations face this dilemma when they realize that their way of working is no longer sustainable. Improving requires effort, but not improving has inevitable consequences.
Create the conditions to build with quality
Working with quality, as we've seen throughout this series, does not depend only on tools or individual talent. It is a direct consequence of the environment (system) we build. Quality does not arise spontaneously: it needs space, alignment, and a culture that values it.
From Lean Software Development, we start from one premise: people want to do good work. But if incentives, habits, and culture don’t support that, even teams with the best intentions will fall into practices that sacrifice quality in favor of urgency, volume, or the appearance of productivity. And this inevitably leads to generating a lot of waste.
“A bad system will beat a good person every time.”
—W. Edwards Deming
As product development leaders, we have a clear responsibility: create the right conditions so that quality is not only possible, but inevitable. This involves intervening in three key dimensions: incentives, work systems, and culture.
Quality doesn’t improve by acting only on the visible. As Donella Meadows well summarized, there are many levels from which to intervene in a system. The deeper the intervention point (mindset, culture, structure), the greater its impact. This framework reminds us that if we want sustainable quality, it's not enough to tweak metrics: we have to transform how we think and how we work.
 |
| Places to Intervene in a System by Donella Meadows |
Redefine success
Instead of celebrating only the number of features delivered or apparent speed, let's focus on real impact, system sustainability, and the team’s ability to adapt confidently.
Quality is not about delivering more, but about delivering better: with less risk, maintaining a sustainable pace, continuously learning, and better anticipating changes.
Make space for learning and continuous improvement
One of the most common mistakes is to think that Kaizen time is dispensable. But setting aside time to refactor, automate, review processes, or simplify is not a luxury: it’s part of the team’s job and an investment in the system’s health.
To make it possible, we need to introduce intentional slack: planned space to observe, learn, and improve. Without that margin, all the time is spent delivering, and there’s no energy or focus left for Kaizen.
Continuous improvement requires time, attention, and a sustainable rhythm. It's what allows consistent waste reduction.
Take care of team culture
Psychological safety is key. If there is fear of making mistakes or pointing out problems, there will be no jidoka, kaizen, or visibility. Only in an environment where it’s safe to question, explore, and learn without punishment can we detect errors in time and improve together, reducing the waste they generate.
We must also avoid encouraging heroic work: when good outcomes depend solely on someone’s extraordinary effort, it's a sign that the system is failing.
Instead of heroes, we need teams that work sustainably, with processes that ensure continuous and predictable quality. Heroic work is often a chronic waste generator.
Moreover, real autonomy must be granted: choosing technologies, designing testing processes, having a voice in planning, etc. A team with no control over its technical environment, workflow, or how it validates what it builds will hardly be able to guarantee quality.
Autonomy, combined with shared responsibility, is one of the strongest pillars of quality in Lean.
Finally, incentives must be aligned with quality. Recognize and make visible the work that keeps everything flowing: not just new features, but also when technical debt is reduced, the testing process is improved, a production incident is prevented, or a critical system component is simplified.
All of that is also delivered value. And it’s often the most enduring.
How to make quality inevitable: leadership in practice
Making quality possible is not about demanding more effort from teams. It's about changing the system so that working with quality becomes the most natural, simplest, and fastest path. Over the years, I’ve tried to systematize this approach with very concrete decisions. Here are some of them:
- Reserve space for learning. Actively decide what portion of time is invested in learning. Sometimes it’s training, other times it’s simply asking: “What have you learned? What can you share?”
- Turn mistakes into collective learning. Introduce blameless postmortems. Lead the first ones, define the process, normalize that errors are not blame, but opportunities for improvement.
- Lead by example. Apply TDD, evolutionary design, pairing. Be the first to document and act on incidents. Don’t demand what you don’t practice.
- Introduce Technical Coaching. Learn alongside those who already master practices like TDD or Pair Programming. If possible, bring in experts with real experience.
- Change the hiring process. Evaluate how people work, not just what they know. Introduce TDD, pairing, collaborative design as part of the process.
- Reward and make structural improvements visible. Explicitly value what improves quality: debt reduction, better test strategies, simplifications, etc.
 |
| Transformational Leadership Impact Model by DORA / Accelerate |
Lead to make quality inevitable
Building with quality is not just a matter of technical practices: it is, above all, a matter of leadership. Our role as leaders is not to demand quality as if it were an optional extra, but to understand that it is the foundation for sustainable speed, for reducing waste, and for maximizing real impact.
Quality is not a goal or an option: it is the operating system upon which everything else relies. If that system fails, any attempt to move fast leads directly to collapse.
Our job as leaders is to create the conditions where quality does not depend on individual will, but becomes the easiest, fastest, and most natural path. Where building with quality is not a heroic act, but the inevitable one.
No comments:
Post a Comment