Lean Software Development: Quality through Collaboration and Visibility

Fourth part of the series on quality in Lean Software Development. In the previous post, we discussed how internal and technical quality is key to sustaining external quality and accelerating development.

Quality through collaboration and shared design

An essential part of quality, often underestimated, doesn’t lie in the code or the tools, but in how we work together. In Lean Software Development, errors are not just seen as technical failures, but also as failures in understanding. Many of the defects that reach production aren’t due to poorly written code, but because the code doesn’t solve the right problem, or doesn’t do so in the right way.

That’s why one of the key mechanisms to build with quality is close and continuous collaboration among all the people involved—those who design, develop, test, or speak with users. The earlier we share an understanding of the problem and align expectations, the fewer errors will be introduced into the system. Once again, quality from the start.

Practices like pair programming, ensemble work, using concrete examples in conversations with the business, or co-designing solutions are mechanisms that allow us to detect errors—technical and conceptual—as soon as they appear. In doing so, they enable early intervention aligned with the spirit of jidoka. And we do this naturally, because there are many eyes on the problem, many opportunities to surface misunderstandings.

This collaborative approach also reinforces kaizen, as it facilitates continuous improvement. Ideas are challenged, explained, and refined. The system evolves more coherently because it doesn’t rely on isolated individual decisions, but on shared and distributed knowledge.

Furthermore, collaboration reduces waste: we build what is actually needed, avoid incorrect assumptions, and minimize rework. Solutions tend to be simpler because they’ve been discussed and refined from different perspectives.

Ultimately, if we understand building with quality as avoiding defects, reducing waste, and maintaining a healthy system we can evolve with confidence, then collaboration is not optional. It is one of the most powerful ways to prevent errors before they become code.

The value of making quality (or its absence) visible

One of Lean’s fundamental principles is to make problems visible. If we can’t see a problem, we can’t improve it. And if quality isn’t visible to the team, to decision-makers, or to those supporting the product, then it’s unlikely to become a priority.

That’s why, in Lean Software Development, it’s essential to make the real state of quality visible at all times. Not only through technical metrics, but also with mechanisms that make it obvious when something is failing, when we’re accumulating waste, or when we’re risking system stability.

This connects directly to jidoka: any signal of a problem, no matter how small, should stop the flow or at least get our attention. Whether it's a failing test, a monitoring alert, a drop in coverage, or an increase in average bug resolution time—everything should turn on a warning light. The goal is that nothing goes unnoticed so we can act in time.

It’s also a constant reinforcement of kaizen: what isn't seen can’t be improved. Making quality—internal and external—visible allows us to make informed decisions about where to focus our improvement efforts. If we notice production defects always come from a certain part of the system, we probably need to strengthen our testing there. If the pace of change slows down, maybe complexity is growing out of control.

There are many ways to make quality visible: from continuous integration dashboards to production alerts, from physical boards with open bugs to regular incident review meetings. The important thing isn’t the tool, but the habit of looking honestly at the state of the system and the process.

Making quality (or its absence) visible also has a cultural impact: it reinforces shared responsibility. If everyone sees there’s a quality issue, it’s easier for everyone to participate in solving it. The invisibility of decay is eliminated, resignation is avoided, and an environment is fostered where problems are tackled as soon as they appear.

Because ultimately, building with quality also means building with transparency.

Quality as an organizational habit

Building with quality isn’t a phase of the process, a task assigned to a specific person, or something you “add at the end.” It’s a way of working, a habit cultivated daily and embedded in everything we do: how we design, how we write code, how we collaborate, how we solve problems, and how we learn.

In Lean Software Development, quality is non-negotiable because it is the foundation of everything else. Without quality, flow breaks down, learning slows, the cost of change rises, and trust disappears. That’s why quality isn’t pursued for technical idealism, but because it’s the most effective way to deliver value continuously and sustainably.

The principles of jidoka, poka-yoke, and kaizen are present in every practice we've mentioned: in automated tests that stop the flow upon failure, in processes that prevent human errors, in the constant improvement of our tools and processes, and in how we treat incidents as learning opportunities.

But none of this works unless it becomes part of the team’s culture. Quality doesn’t emerge by chance or good intentions—it arises when there are concrete practices that support it, when there are shared agreements on how to work, and when the environment reinforces these behaviors over and over. In other words, when there are habits.

And like any habit, it must be trained. It starts with small actions: writing a test before fixing a bug, stopping development to investigate an error, reviewing the design with someone else before implementing. Over time, these actions become the natural way of working. The team gains confidence, the system remains healthy, and problems are addressed quickly and calmly.

In the next and final post, we’ll explore why many organizations still don’t work with quality—even knowing its benefits. We’ll look at the most common resistances and how we can create an environment where quality doesn’t depend on heroic efforts, but becomes a natural consequence of the system.