Sunday, June 15, 2025

Built a Custom GPT to Help Teams Ship Smaller, Safer, Faster

Most teams build too much, too early, with too much anxiety. They optimize for perfect architecture before users, comprehensive features before learning, elaborate processes before understanding real constraints.

The result? Endless discussions, delayed releases, building the wrong thing.

So I built: 👉 eferro Lean – your no-BS delivery copilot

A Custom GPT that works with any product development artifact—PRDs, tickets, code reviews, roadmaps, architecture docs—and asks the uncomfortable, helpful questions:
  • "What's the smallest shippable version?"
  • "Do we actually need this complexity right now?"
  • "What if we postponed this decision?"
  • "How can we make this change in smaller, safer steps?"
Perfect for anyone building products: developers, PMs, designers, architects, team leads.


Use it to:
  • Slice big ideas into vertical experiments and safe technical steps
  • Plan parallel changes, expand-and-contract migrations, or branch-by-abstraction
  • Challenge bloated PRDs or over-engineered solutions
  • Turn risky releases into incremental, reversible deployments
It challenges assumptions, slices features into experiments, and guides you toward the last responsible moment for decisions. Questions that create momentum instead of paralysis.

Software is a learning exercise. Every feature is an experiment. The faster we test hypotheses safely, the faster we learn what creates value.

No tracking, no upsell, no agenda. My only intention is to share what I've learned and keep learning from the community.

If it helps one team ship better—with less stress, more learning—that's enough.

Thursday, June 12, 2025

Good talks/podcasts (Jun)

These are the best podcasts/talks I've seen/listened to recently:
  • Data - The Land DevOps Forgot 🔗 talk notes (Michael T. Nygard) [Architecture, Data Engineering, Devops, Platform] [Duration: 00:47] (⭐⭐⭐⭐⭐) This talk offers a critical look at why the analytical data world is "the land DevOps forgot," and presents Data Mesh as a paradigm shift to enable decentralized, autonomous data operations, emphasizing that successful adoption requires significant organizational and cultural change.
  • Jeff Bezos explains one-way door decisions and two-way door decisions 🔗 talk notes (Jeff Bezos) [Management, Mental models] [Duration: 00:03] (⭐⭐⭐⭐⭐) Jeff Bezos explains his mental model of two-way door (reversible) and one-way door (irreversible) decisions, highlighting how to apply different decision-making processes for each in organizations.
  • TDD, AI agents and coding with Kent Beck 🔗 talk notes (Kent Beck, Gergely Orosz) [AI, XP, tdd] [Duration: 01:15] Industry legend Kent Beck, creator of XP and TDD, shares insights on the evolution of Agile, Extreme Programming, and Test-Driven Development, alongside his current experience of "most fun ever" coding with AI agents.
Reminder: All of these talks are interesting, even just listening to them.

You can now explore all recommended talks and podcasts interactively on our new site: The new site allows you to:
  • 🏷️ Browse talks by topic
  • 👤 Filter by speaker
  • 🎤 Search by conference
  • 📅 Navigate by year
Feedback Welcome!
Your feedback and suggestions are highly appreciated to help improve the site and content. Feel free to contribute or share your thoughts!
Related:

Sunday, June 08, 2025

Lean Software Development: Overcoming resistance and creating conditions for quality

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.

Improve or die meme


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
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.

This type of leadership, which seeks to change the system to make quality inevitable, is not an isolated intuition. Studies such as those from the DORA report show that transformational leadership, together with Lean practices, has a clear impact on team performance, well-being, and business results.

Transformational Leadership Impact Model by DORA
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.

Saturday, May 24, 2025

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.

Sunday, May 18, 2025

Good talks/podcasts (May)

These are the best podcasts/talks I've seen/listened to recently:
  • Escaping A MAJOR Platform Engineering PITFALL (Steve Smith) [Engineering Culture, Platform, Platform engineering, Technology Strategy] [Duration: 00:11] This talk explores the pitfalls of technology anarchy and autocracy in platform engineering and advocates for escaping them by building opinionated platform capabilities with contextual technical alignment to accelerate delivery teams
  • How To Get The Most Out Of Vibe Coding | Startup School (Tom Blomfield) [AI, Developer Productivity, Devex, Generative AI] [Duration: 00:16] Practical best practices for effective vibe coding and using AI tools/LLMs in software development workflows, from planning and testing to debugging and leveraging multiple models.
  • o11ycast - Ep. #80, Augmented Coding with Kent Beck (Ken Rimple, Kent Beck, Jessica Kerr) [AI, Engineering Culture, Inspirational, testing] [Duration: 00:39] (⭐⭐⭐⭐⭐) Explore augmented coding with Kent Beck, discussing how AI agents transform software development, the essential role of observability and testing for control and understanding, and the future impact on engineering careers.
  • Devoxx Greece 2025 - Data Modeling for Software Engineers by Scott Sosna (Scott Sosna) [Agile, Architecture, Data Engineering, Flow, Software Design] [Duration: 00:40] Learn why thoughtful, consistent data modeling and decoupling external data views from internal implementations are critical responsibilities for software engineers in modern agile environments, given that data persists forever and outlives the code that uses it.
  • Devoxx Greece 2025 - How Flow Works and other curiosities by James Lewis (James Lewis) [Continuous Delivery, Flow, Lean, Lean Product Management, Lean Software Development] [Duration: 00:40] "How Flow Works and other curiosities" by James Lewis explains how work flows as information through organizational value streams, detailing blockages like queues and offering principles like batch size reduction to improve delivery and throughput.
  • Software Engineering F&*K Up Behind The Passport E-gate Failure" (Dave Farley) [Architecture, Resilience, Software Design] [Duration: 00:17] In this episode, Dave Farley talks about the issue, how poor software engineering led to this, how distributed systems come into it all, how to avoid something like this happening again and at the end of the video asks for answers on some concerning issues around the whole story.
Reminder: All of these talks are interesting, even just listening to them.

You can now explore all recommended talks and podcasts interactively on our new site: The new site allows you to:
  • 🏷️ Browse talks by topic
  • 👤 Filter by speaker
  • 🎤 Search by conference
  • 📅 Navigate by year
Feedback Welcome!
Your feedback and suggestions are highly appreciated to help improve the site and content. Feel free to contribute or share your thoughts!
Related:

Friday, May 16, 2025

Lean Software Development: Quality as the Foundation of Sustainable Development

Third part of the series on quality in Lean Software Development. After exploring how to detect errors early and learn from them, in this entry we explore how technical and internal quality is key to sustaining external quality, why less is more, and how to create a culture where working with quality is not the exception but the norm. In this entry, we explore how this foundational quality is not a luxury but the essential hygiene of a well-crafted software product.

Quality as a Development Accelerator

One of the most widespread beliefs, especially in organizations that haven’t yet adopted Lean approaches, is that working with quality slows down development. It’s assumed that writing tests, automating validations, or refactoring consumes time that could be spent "delivering faster." However, from the perspective of Lean Software Development, this view is not only wrong—it perpetuates waste.

In reality, well-understood quality is an accelerator. When the system is healthy—with reliable automated tests, simple design, and robust processes—every step we take has less friction. The team’s confidence in its ability to change the system grows, feedback is faster, and the cost of change drops dramatically. In other words, we go faster not despite quality, but thanks to it.

This is fully aligned with the Lean principles we've been explaining in this series (poka-yoke, jidoka, kaizen).

Moreover, when the team trusts its system—because it knows that errors are detected in time, that the design allows for easy evolution, and that experiments can be conducted without breaking anything—it dares to innovate, try new ideas, and quickly adapt to what it learns from the user. In short, it enables the continuous delivery of value.

In my experience, teams that invest in quality from the beginning and incorporate it as part of their way of working progress much more steadily, quickly, and with less emotional cost. They don’t have to constantly stop to "fix the system" because they never let it deteriorate. And that’s possible because they understand that quality isn’t inspected at the end—it’s built into every step.

Internal Quality as the Foundation of External Quality

In Lean Software Development, external quality—the one users or clients directly perceive—is a priority. However, to sustain that quality over time, solid internal quality is essential: a well-designed, understandable system that can be maintained and evolved without fear.

Many times, the defects visible to users originate from invisible problems within the system: tightly coupled code, unreliable tests, contextless technical decisions, or fragile processes. These issues not only cause errors, they slow down the team, hinder adaptation to change, and raise the cost of delivering value. They are a silent but very real form of waste.

Lean encourages us to see these structural problems as improvement opportunities (kaizen) and to address them systematically. It's not about “beautifying the code” or following arbitrary rules, but about building a solid technical foundation that reduces everyday friction and enables rapid, confident progress.

We also apply jidoka in this context: when a flaky test, opaque dependency, or hard-to-deploy system blocks progress, we flag it as a system problem, not an individual weakness. We stop, analyze, and improve the technical infrastructure to prevent recurrence. Every small change counts. For example, if a deployment fails repeatedly, we don’t just try again—we investigate the root cause and automate a solution, like a script that checks database availability before deployment.

Moreover, poka-yoke principles also apply to internal quality. Using strong typing, simple design patterns, proper encapsulation, and tools that make the right thing easy to do without constant effort are ways to prevent technical errors and ease system evolution. The easier it is to do the right thing, the less likely it is to introduce debt or accidental errors. For example, using a code linter to catch syntax errors before they reach production, or configuring version control to prevent unreviewed code from being committed.

In summary, internal quality isn’t an end in itself—it’s a means to sustainably ensure external quality. When the system is easy to understand, test, and change, the team can focus on delivering value, learning faster, and better adapting to customer needs. That structural simplicity is what allows us to build with quality—and move fast without breaking things.

Graph showing internal quality as the foundation upon which external quality is built.

Quality is Not Complexity or Sophistication

A common confusion in software engineering is associating quality with technical sophistication. “Beautiful” code, elegant solutions, or complex designs anticipating future needs are often praised. However, from a Lean Software Development perspective, this view is fundamentally flawed. In reality, quality is not a luxury—it is a basic necessity, the fundamental hygiene of a well-built software product.

Lean doesn’t reward unnecessary complexity or overdesign. Quite the opposite: it promotes deliberate simplicity as a way to reduce waste, ease system evolution, and ensure reliability. Quality in this context is not measured by how many design patterns we apply or how "intellectually interesting" the design is, but by how well it solves the current problem with the least effort and risk. It’s like cleanliness in a home: not an ornament, but the minimum necessary for healthy living.

Every line of code we don’t need right now is a potential source of error. It not only adds maintenance cost, but also complicates understanding, slows evolution, and can mislead decisions.

"The best code is no code at all" — Ward Cunningham

From Lean’s perspective, anticipating features that don’t yet exist or designing systems beyond current needs is a form of waste. It’s also a kaizen failure, as it prevents learning and iteration step by step. And it breaks poka-yoke by introducing optional, unvalidated paths not covered by tests. Instead of preventing errors, we’re planting them.

Quality in Lean is built with clear, tested, understandable code, limited to what is strictly necessary. We care about design not to make it more complex, but simpler, safer, and easier to evolve. We rely on tests, continuous feedback, evolutionary design, and constant refactoring to keep the system healthy without falling into the trap of planning the future from the present.

So no: technical beauty or overdesign is not quality. Often, it’s its enemy. Building with quality in Lean is, above all, having the humility to do just enough, do it well, and prepare to improve based on what we learn tomorrow.

Conclusions: Quality as Basic Hygiene

In summary, quality in Lean Software Development is not an optional feature or a sophisticated extra. It is the base, the foundation, the essential hygiene of a sustainable and valuable software product. It’s not about seeking complexity or elegance for their own sake, but about building a system that is clear, simple, tested, and easy to maintain.

Quality is like the air we breathe: we don’t always notice it, but its absence quickly suffocates us. Software without quality is software doomed to fail—full of bugs, hard to change, and expensive to maintain. That’s why investing in quality from the start, and seeing it as an essential practice rather than a luxury, is the best way to ensure long-term success.

Quality is not a bonus—it’s the bare minimum. And simplicity is its best ally.

In the fourth part, we’ll see how collaboration and visibility are also essential to maintain this hygiene and build sustainable quality software.