The world of software development is one of constant evolution. Development methodologies rise and fall, while new technologies bloom and fade just as quickly. At the same time, our market demands shift at a dizzying speed. Yet, amidst this constant churn, certain fundamental principles retain their potency. Over two decades ago, Mary and Tom Poppendieck published Lean Software Development: An Agile Toolkit, a seminal work that translated the powerful principles of Lean manufacturing, pioneered by Toyota, into the domain of software creation.

In a series of articles, we will explore its principles and whether they are still relevant today. As we all navigate the complexities of software development in 2025 – an era defined by rising AI integration, new cloud-native architectures, an increase in platform engineering, heightened cybersecurity threats, and ever-accelerating delivery expectations – it is worth revisiting the book’s foundational concepts. As we will discover, these are still as relevant as they were 22 years ago.

The very first principle they tackled, forming the bedrock of their framework, was deceptively simple yet profoundly impactful: Eliminate Waste.

The Lean Foundation: Value and Muda

Is the idea of eliminating waste, as defined by the Poppendiecks, still relevant today? Or has our IT landscape shifted so dramatically that these original insights have become mere historical footnotes? The answer, overwhelmingly, is that the principle of eliminating waste is not just relevant; it is arguably more critical than ever. Understanding and actively combating the various forms of waste remains essential for building effective software systems. Lean thinking, which underpins the Poppendiecks’ work, revolves around maximizing customer value while minimizing waste. Let us look at where the roots of lean thinking lie.

These roots trace back to post-war Japan and the challenges faced by the Japanese car manufacturer Toyota. Tasked with producing cars affordably for a small market, Toyota couldn’t rely on the economies of scale inherent in mass production. Taiichi Ohno, the architect of the Toyota Production System, pioneered a new approach centered on relentlessly identifying and eliminating “muda,” or waste in Japanese. While value is defined as anything the customer is willing to pay for or derive benefit from, waste is anything that consumes resources (time, money, effort) but adds no corresponding value from the customer’s perspective. This included not just obvious things like defects, but also inventory waiting to be used, overproduction, unnecessary factory logistics, waiting time, and overly complex processes. The idea became to deliver exactly what the customer ordered, precisely when it was needed while minimizing everything else.

Ohno and Toyota successfully transferred this thinking from the factory floor to product development. They recognized that ongoing development projects are akin to inventory – work that hasn’t yet delivered value to the customer. Designs and prototypes, while necessary steps, only realize value when the final product reaches the customer. Therefore, minimizing Toyota’s development cycle time became crucial. 

This perspective challenged the traditional software development mindset, urging one to see intermediate artifacts and processes not as essential steps, but potentially as forms of waste if they don’t directly contribute to delivering value efficiently. The Poppendiecks adapted Taiichi Ohno’s original seven wastes identified in the Toyota Production System for the context of software development. Identifying and systematically eliminating these wastes will streamline your development process, reduce costs, improve quality, shorten lead times, and ultimately deliver more value to your clients, at a faster rate.

Dissecting the Wastes: The Poppendieck’s Framework

The first and most critical step in applying lean principles is learning to see waste in the context of software development. This requires us to question every activity and artifact: Does it truly add value from our customers’ perspective?  If there is a way to achieve the same value without it, then this might be a waste. The first chapter of Lean Software Development meticulously outlines seven key categories of waste in software development. While later discussions often include an eighth (Underutilized Talent), we will examine the original seven wastes, as these form the core of the chapter, and consider their current manifestations and relevant implications.

1. Partially done work (Inventory)

This refers to any work started but not completed and delivered (“work in progress”). Requirements documents sitting unread, code waiting for integration, features waiting for testing – all of these represent investments tied up without delivering value. Like physical inventory, it ties up capital (developer time, resources) without generating value. It risks obsolescence, requires “storage” (mental effort, keeping track, code branch management), and hides potential problems until late in the cycle.

Relevance in 2025: This remains a pervasive issue. Long-lived feature branches are a classic example. While Gitflow and similar models have their place, code branches that sit unmerged for weeks or months represent significant partially done work, increasing merge complexity and delaying feedback. Unverified assumptions in requirements documents, extensive backlogs groomed far ahead of capacity, or even untested AI model iterations represent modern forms of this waste. Practices like continuous integration and continuous delivery, small batch sizes (promoted by Agile and Kanban), and feature flags allowing for the deployment of incomplete features (while keeping them hidden from users) are direct countermeasures, highlighting the ongoing battle against this waste. The faster the market moves, the higher the risk and cost associated with partially done work becoming obsolete or irrelevant.

2. Extra features (Overproduction)

Feature creep and building features that your customers don’t need or use is perhaps the most insidious form of waste. It consumes your development effort, adds complexity to your codebase (making future changes harder), increases the testing burden on your team, and clutters the user interface. This often stems from speculation (“they might need this”) rather than validated customer demand.

Relevance in 2025: Gold-plating and feature bloat are timeless problems. In 2025, the ease of adding features, fueled by powerful frameworks and component libraries, can exacerbate this. The pressure to compete can lead teams to build extensive feature sets based on competitor analysis rather than direct user feedback or data. The “You Ain’t Gonna Need It” (YAGNI) principle is a direct counter. Methodologies like Lean Startup, emphasizing minimum viable products and validated learning cycles, are built around avoiding this waste. Tools such as A/B testing, feature toggles coupled with usage analytics, and direct user research are crucial in 2025 to ensure development effort focuses strictly on features that deliver demonstrable value. Building complex, speculative AI-driven features without clear user validation is a significant modern risk here.

3. Relearning (Motion)

This waste occurs when the knowledge that your development teams have acquired is lost or needs to be rediscovered. This can happen due to poor documentation, inadequate knowledge sharing, team churn, or simply forgetting how complex systems work. Whenever someone has to re-figure something out, it is a wasteful effort.

Relevance in 2025: In an era of increasingly complex distributed systems, microservices, sophisticated cloud infrastructure, and intricate AI models, the potential for creating waste by relearning is enormous. High developer turnover rates can compound this problem. Countermeasures are critical: robust (but concise and maintainable) documentation, automated architecture diagrams, pair programming, mob programming, internal wikis, communities of practice, thorough onboarding processes, and investing in knowledge management tools. The rise of platform engineering aims to abstract away complexity, reducing the cognitive load and the need for every developer to relearn the intricacies of the underlying infrastructure. Effective logging, monitoring, and observability are also key – they provide and maintain insights into your systems’ behavior, reducing the need for your teams to “relearn” how things work during incidents.

4. Handoffs (Transportation)

Every time work is passed from one person or group to another (e.g., analyst to developer, developer to tester, tester to operations), there is a potential for delay, miscommunication, and loss of information. Each handoff introduces friction and waiting time into the value stream.

Relevance in 2025: Are you adopting DevOps? The DevOps movement focuses on dismantling the barriers between development and operations, directly addressing the primary traditional handoff in software delivery. Cross-functional teams, consisting of developers, testers, designers, and operations specialists, are formed to lessen handoffs in the development cycle. Likewise, while full-stack development seeks to minimize skill-based handoffs, the practical division between frontend and backend often introduces an internal handoff point among teams. Aligning UI requirements with API capabilities may cause delays and require meticulous interface management. Automated continuous integration and delivery pipelines drastically minimize manual handoffs during the building, testing, and deployment phases. Nevertheless, other handoffs can still exist, often hidden. Handoffs between your product management and engineering, among varied feature teams collaborating on interrelated components, or even between data scientists and machine learning engineers during model deployment, can lead to significant bottlenecks. In 2025, value stream mapping will continue to be an effective tool for pinpointing and analyzing each handoff in the delivery process, so make sure to utilize it.

5. Task switching (Motion/Processing)

We humans are notoriously inefficient at context-switching. Assigning developers to multiple projects simultaneously or frequently interrupting them with urgent but unrelated tasks incurs significant cognitive overhead. Each switch requires time to reorient, reload context, and regain focus, leading to lost productivity and increased errors.

Relevance in 2025: In our hyper-connected world with Slack and Teams notifications, constant meetings, and the pressure for instant responses, task-switching waste is arguably worse than when the Poppendiecks released their book in 2003. The prevalence of remote work can blur boundaries and increase interruptions without the right toolset, and if not managed carefully. Agile practices, like limiting the work-in-progress items in Kanban, are direct attempts to combat this. Creating dedicated focus times, structuring your teams around specific products or value streams, and fostering a culture that respects deep work are crucial. The cognitive load associated with managing complex cloud environments or debugging distributed systems makes minimizing task switching even more critical for effectiveness; you should keep this in mind when structuring your teams’ work.

6. Delays (Waiting)

Any time spent waiting in the development process can be considered a waste. This includes your developers waiting for approvals, resources (e.g., test environments), information, their builds or tests to complete, or dependencies from your other teams. Delays extend lead times and frustrate your team members.

Relevance in 2025: Speed is paramount today. Delays directly impact time-to-market and the ability to respond to feedback. While continuous integration and delivery have dramatically reduced build and deployment delays, other forms persist. Waiting for slow, manual approval processes (e.g., security reviews, change advisory boards), access to specialized environments (such as cloud environments or GPU clusters), slow automated test suites, or on external dependencies or APIs are common bottlenecks. Techniques like automating infrastructure provisioning (infrastructure as code), parallelizing test execution, implementing efficient asynchronous communication patterns, and streamlining governance processes can be vital to remedy this. Value Stream Mapping is still essential for identifying where delays occur in your end-to-end flow.

7. Bugs, errors, and vulnerabilities (Defects)

Defects discovered late in the process (or worse, by your customer) are incredibly wasteful. They require significant effort to diagnose, fix, re-test, and redeploy. They damage customer trust and can have significant consequences on your business. The cost of fixing a defect will increase exponentially the later it is found.

Relevance in 2025: Preventing defects remains fundamental. While the nature of defects might evolve (e.g., subtle bugs in complex algorithms, security vulnerabilities, performance regressions in distributed systems, AI model bias), the principle is unchanged. The “Shift Left” movement in testing – incorporating quality practices earlier in the lifecycle – is a direct response. test-driven development, behavior-driven development, comprehensive automated testing (unit, integration, end-to-end, contract), static analysis, security scanning, chaos engineering, and robust monitoring/observability are all essential practices in 2025 to prevent defects or detect them as early as possible. Your teams should be using them! The ability for your teams to quickly roll back faulty deployments via automated pipelines is also a crucial defect mitigation strategy.

The Eighth Waste: Underutilized Human Potential

Often added to the original seven, this waste (sometimes called “non-utilized talent” or “unleveraged skills”) refers to failing to leverage the skills, knowledge, creativity, and experience of your development team members. This includes command-and-control management styles, lack of empowerment, poor communication, insufficient training, and failure to create an environment of psychological safety where your people can fully contribute.

In 2025, with the “war for talent” still raging and the increasing importance of innovation, this waste is particularly damaging. Organizations that fail to engage their employees, provide growth opportunities, and empower them to solve problems will find attracting and retaining good talent challenging; they will inevitably underperform. Fostering autonomy, mastery, and purpose, as well as creating inclusive, psychologically safe environments, are key to unlocking human potential and avoiding this waste.

Beyond these core sources of waste, the Poppendiecks also point to Management Activities as potential sources of waste. Cumbersome project prioritization, tracking systems that don’t improve flow, and bureaucratic authorization systems often add overhead without adding value, sometimes indicating deeper systemic issues like too much work in progress. This is something that you can remedy directly by introducing agile management tools and adopting frameworks such as Scrum.

Challenges and Nuances in 2025

While the principles that we have just looked at remain solid, applying them in 2025 requires some nuance:

  • New Forms of Waste: Are there new categories emerging? Consider waste related to excessive or poorly integrated tooling (“toolchain complexity”), building overly complex abstractions that hinder understanding, data hoarding without generating insights, or inefficient cloud resource utilization that yields no practical value.
  • The Scale Factor: Identifying and eliminating waste in large, complex, distributed systems and organizations is significantly harder than in smaller, co-located teams. Systemic waste, embedded in organizational structures or processes, requires a concerted effort to address.
  • Necessary “Overhead”: Not all the activities that don’t directly produce customer features are wasteful. Investing in robust testing infrastructure, security measures, compliance activities, platform engineering, and even some level of experimentation or R&D might seem like overhead. Still, these are often necessary investments for long-term sustainability, resilience, and innovation. The key is distinguishing necessary investment from unnecessary waste. A good IT manager will listen to what his team thinks about this!

Conclusion

Revisiting the first chapter of Poppendieck’s book Lean Software Development in 2025 confirms the enduring power of their “Eliminate Waste” principle. The specific manifestations of waste may evolve with technology and methodology, but the core concepts – partially done work, extra features, relearning, handoffs, task switching, delays, defects, and underutilized talent – remain potent drains on your development teams’ productivity, quality, and value delivery.

The challenges of 2025 and beyond – complexity, speed, security, and cloud integration – don’t invalidate these principles; they amplify their importance. Suppose you can help embed a Lean mindset, continuously identifying and eliminating waste in all its forms. In that case, you and your teams will be better equipped to navigate the modern software landscape. You will be able to deliver value faster and build more resilient, more maintainable systems while fostering more engaged and productive teams. Both are necessary to achieve sustainable success.

The Poppendiecks’ insights from over two decades ago are not just relevant; they provide a crucial lens through which you can optimize your software development efforts today and into the future. The pursuit of eliminating waste is not a one-time cleanup; it’s a continuous journey, essential for thriving in today’s demanding world of software engineering.

Look forward to our next article, which will delve into the second chapter of Lean Software Development: An Agile Toolkit; Amplify Learning.