Skills / Engineering-practices

Lean Software Development

People under pressure don't think faster.

Lean Software Development applies Toyota's proven production system to software teams, giving engineers and managers a concrete toolkit for identifying and eliminating the 7 types of software waste, mapping value streams, and optimizing flow from idea to production. Created by Mary and Tom Poppendieck, it is the intellectual foundation of Kanban, DevOps flow metrics, and scaling frameworks like SAFe and LeSS. Unlike generic agile advice, it pairs high-level principles with specific diagnostic tools — waste audits, Value Stream Maps, WIP limits — that produce measurable, actionable output.

By Mary Poppendieck  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisLean Software Development

Input

“Sure. Product writes a spec, then it sits in a backlog for a sprint or two, then a dev picks it up and builds it, it goes to QA, there's usually some…”

Diagnosis

Let's start by finding where your value is actually flowing — and where it's stalling.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Stop building what nobody needs — eliminate waste and let value flow to your customer

Lean Software Development organizes around 7 principles adapted from the Toyota Production System: Eliminate Waste, Amplify Learning, Decide as Late as Possible, Deliver as Fast as Possible, Empower the Team, Build Integrity In, and See the Whole. The waste elimination principle gives teams a concrete 7-category taxonomy — partially done work, extra features, relearning, handoffs, task switching, delays, and defects — turning vague 'inefficiency' into an auditable checklist. Value Stream Mapping is the primary diagnostic tool: teams trace the full flow of a feature from concept to production, measure wait times at each stage, and design a leaner future-state process. The Last Responsible Moment principle introduces Set-Based Development, where multiple design options are held open until the latest point at which deferral adds value rather than risk — contrasting sharply with the industry norm of deciding architecture upfront. Pull systems with WIP limits replace push-based sprint loading, and Build Integrity In distinguishes perceived integrity (does it delight customers?) from conceptual integrity (does the system hold together coherently?), with Test-Driven Development as the primary mechanism for both.

The problem

Software teams accumulate invisible waste — partially built features, constant context switching, handoffs between siloed specialists, and decisions made too early that require expensive rework later. Because waste in software is cognitive and organizational rather than physical, it hides inside normal-looking processes: long sprint backlogs, 'done but not deployed' tickets, and architectural decisions locked in before customer feedback exists. Without a named taxonomy and a diagnostic tool like Value Stream Mapping, teams keep optimizing the wrong things and the same retrospective problems resurface every sprint.

The solution

By naming your waste precisely, mapping where value actually flows and where it stalls, and applying Last Responsible Moment thinking to your riskiest decisions, you will stop solving symptoms and start removing the structural causes of slow, unreliable delivery.

You bring

A description of your team's current delivery process — how work flows from idea to production
Specific friction points, delays, or quality issues you're experiencing
Team size, work types, and any available cycle time or lead time data
Context on whether you're optimizing a single team or a multi-team value stream

You get

A categorized 7-Waste Audit Report mapping your symptoms to specific lean waste types with severity ratings and prioritized remediations
A guided current-state Value Stream Map identifying your biggest flow bottlenecks and the ratio of value-adding time to total lead time
A Last Responsible Moment Decision Log for your pending architectural and process choices
WIP limit recommendations calibrated to your team's cycle time, work type, and capacity

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen AVague

Unaided

“Your team has a 7-week average lead time. Developers say they're blocked; product says developers aren't picking up tickets fast enough; QA is always in fire-drill mode at sprint end. You run a retrospective every two weeks where the same three problems come up. Everyone is working hard but the system keeps producing the same results because no one has mapped where the time is actually going.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Lean Software Development

“You've mapped your value stream and identified that 5 of your 7 weeks are queue time, not work time. You've set WIP limits of 2 items per developer, cut your sprint backlog from 40 items to 12, and eliminated the biweekly release window in favor of continuous deployment for routine changes. Lead time has dropped to under 2 weeks. The retrospective problems haven't been solved — they've been made structurally impossible.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Lean Software DevelopmentClaude

Lean Software Development

Let's start by finding where your value is actually flowing — and where it's stalling. In lean terms, we're looking for waste: activities that consume time and resources without adding value for your customer. Can you walk me through how a feature typically moves through your team, from the moment someone decides to build it to the moment a user can actually use it? I'm particularly interested in the handoffs and wait times between stages.

Sure. Product writes a spec, then it sits in a backlog for a sprint or two, then a dev picks it up and builds it, it goes to QA, there's usually some back-and-forth, then it waits for a release window. Probably takes 6-8 weeks for most features. Devs are always saying they're blocked waiting for designs or answers from product.

That 6-8 week lead time almost certainly has a lot of wait time baked in — Delays is one of the 7 lean waste types. But I'm also hearing at least two others right away. 'Sits in a backlog for a sprint or two' is Partially Done Work: the spec exists but value isn't flowing yet. And 'blocked waiting for designs or answers' is Handoff waste — work thrown over walls between specialists rather than pulled through a connected flow. Before we go further, let's map your full value stream. Can you estimate how long a feature spends in each stage: (1) spec written but not started, (2) in development, (3) in QA back-and-forth, (4) waiting for the release window?

Rough guess: 2-3 weeks waiting before dev starts, 1-2 weeks in dev, 1 week in QA, then 1-2 weeks for the next release window.

That tells us something critical. Of your ~7 week lead time, roughly 4-5 weeks is queue time and only 1-2 weeks is active development. In value stream terms, your Process Cycle Efficiency — value-adding time divided by total elapsed time — is around 15-25%. Toyota treats below 25% as a signal that the system needs redesign, not the people. The highest-leverage fix here isn't making developers code faster — it's attacking that pre-dev queue and the release batch size. What controls the 2-3 week wait before a developer picks up a spec? Is it that everyone is fully loaded with other work?

Yes — everyone's always in the middle of 3-4 things at once. We have a big sprint backlog and people get pulled onto different priorities constantly.

That's Task Switching waste — another of the 7. And it's self-reinforcing: because everyone is juggling 3-4 items, each item moves slowly, which makes the backlog feel even more urgent, which leads to pulling in more work. This is exactly what WIP limits are designed to break. If each developer limits themselves to 1-2 active items at a time, individual features move through faster, the pre-dev queue drains, and the need to context-switch disappears. I'd recommend we formalize this as a current-state Value Stream Map and design a future state with explicit WIP limits at each stage. Want me to draft the current-state map based on what you've described — with wait time estimates and waste flags at each step?

Yes, that would be really helpful. I've been trying to explain to my manager why we're slow and this framing is much clearer than anything I've tried before.

Good — and that's actually the 'See the Whole' principle at work. Your manager has probably been optimizing pieces: 'QA needs to be faster,' 'developers need to commit earlier.' But the waste is in the system, not the individuals. A value stream map gives you both the full picture and the vocabulary to explain it. Here is your current-state map based on what you've shared: [Spec Written] —(2-3 wk wait)→ [Development: 1-2 wks] —(0.5 wk wait)→ [QA: 1 wk, includes rework loops] —(1-2 wk wait)→ [Release Window] → Production. Process Cycle Efficiency: ~21%. The three highest-waste stages are the pre-dev queue, the release window, and the QA rework loop. Your future-state design should target all three. Ready to work through the WIP limit recommendations and a deployment frequency change?

Reply to Lean Software Development…

What the skill is doing

01Software Waste Audit

02Value Stream Mapping Facilitation

03Last Responsible Moment Analysis

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

LSLean Software Developmenttyping…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

Sure. Product writes a spec, then it sits in a backlog for a sprint or two, then a dev picks it up and builds it, it goes to QA, there's usually some…9:14✓✓

Let's start by finding where your value is actually flowing — and where it's stalling.9:14

In lean terms, we're looking for waste: activities that consume time and resources without adding value for your customer.9:15

Can you walk me through how a feature typically moves through your team, from the moment someone decides to build it to the moment…9:15

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Software Waste Audit

Walk through your team's process and identify which of the 7 lean waste categories are present, how severe each is, and what concrete changes would eliminate or reduce them. Partially done work, extra features, and handoffs are the most common culprits — but the audit surfaces all seven, each with a remediation pattern drawn from Poppendieck's toolkit.

◦ MethodBased on Poppendieck's direct adaptation of Toyota's 7 muda (waste types) to software — mapping concepts like 'extra processing' to 'unnecessary features' and 'waiting' to delayed code reviews or approval gates, as detailed in Lean Software Development: An Agile Toolkit chapters 1-2.

CapabilityC-02

Value Stream Mapping Facilitation

Step-by-step facilitation of a current-state value stream map for a software feature — from the moment a customer need is identified to the moment working software reaches them. The map surfaces actual wait times, handoff counts, and rework loops invisible in sprint dashboards. A future-state map then identifies the highest-leverage changes to the system.

◦ MethodValue Stream Mapping is a core tool in Poppendieck's toolkit chapters in Lean Software Development and Implementing Lean Software Development (2007), adapted from Toyota's material-and-information flow diagrams to trace knowledge-work flow, decision points, and code handoffs.

CapabilityC-03

Last Responsible Moment Analysis

Identify which decisions on your current project or architecture can be safely deferred, what information to gather in the meantime, and at what point deferral becomes irresponsible. Prevents two failure modes: locking in options before you have real feedback, and allowing ambiguity to block progress indefinitely.

◦ MethodBased on Poppendieck's Last Responsible Moment principle and its contrast with Set-Based Development — the practice of maintaining parallel design options until convergence criteria are met, drawn directly from Toyota's concurrent engineering approach, as described in Leading Lean Software Development (2009).

CapabilityC-04

WIP Limit Design

Recommend appropriate Work-In-Progress limits for each stage of your delivery pipeline based on team size, work type distribution, and observed cycle time data. WIP limits are not arbitrary throttles — they are calibrated using Little's Law (Cycle Time = WIP ÷ Throughput) to prevent inventory accumulation and expose bottlenecks that would otherwise stay hidden.

◦ MethodRooted in Poppendieck's pull-system principle and Little's Law relationship, connecting directly to Kanban's WIP-limiting practices whose intellectual lineage traces to Lean Software Development's treatment of pull scheduling.

CapabilityC-05

Integrity Assessment (Perceived vs. Conceptual)

Evaluate your product or system against both dimensions of integrity Poppendieck defines: perceived integrity (does it do what customers actually need, in a coherent experience?) and conceptual integrity (does the system have a unified internal logic, or has feature accretion created a fragmented architecture?). The assessment surfaces integrity gaps and prescribes targeted interventions.

◦ MethodBased on Poppendieck's 'Build Integrity In' principle, which distinguishes the two integrity dimensions and prescribes test-driven development, refactoring, and continuous customer-collaboration loops as the primary mechanisms for maintaining both — as detailed in Implementing Lean Software Development.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

7-Waste Audit Report

A structured inventory of all seven lean waste categories found in your team's process, scored by frequency and severity, with specific examples from your workflow and ranked remediation actions tied to Poppendieck's toolkit patterns.

OutputD-02

Current-State Value Stream Map

A flow diagram tracing your feature's journey from concept to production, annotating each step with process time, wait time, and quality data — with a Process Cycle Efficiency ratio that quantifies how much of elapsed time is actually value-adding work.

OutputD-03

Last Responsible Moment Decision Log

A structured table of pending decisions, their reversibility, the information needed to make them well, and a deadline for commitment — preventing both premature architectural lock-in and indefinite deferral that blocks progress.

OutputD-04

WIP Limit Recommendation Sheet

Per-stage WIP limit recommendations with Little's Law rationale based on your cycle time data and team capacity, including guidelines for adjusting limits as flow improves over time.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Mary Poppendieck

Mary Poppendieck spent her career at 3M as a manufacturing plant manager before moving into software development leadership — giving her direct, firsthand experience translating Toyota Production System principles into knowledge-work contexts. Together with co-author Tom Poppendieck, she published four books beginning with Lean Software Development: An Agile Toolkit (2003), which became foundational texts in the agile and DevOps communities. Her frameworks are embedded in SAFe, LeSS, and Kanban training curricula, and she is a recurring keynote speaker at Agile Alliance, QCon, and GOTO conferences.

Status · Inspired by Mary Poppendieck’s work — not yet claimed. Are you Mary Poppendieck?

Primary sourceS-01

Lean Software Development: An Agile Toolkit

by Mary Poppendieck

Former 3M manufacturing plant manager and software executive; co-author of 4 foundational lean-agile books; keynote speaker at Agile Alliance, QCon, and GOTO; frameworks embedded in SAFe, LeSS, and Kanban.

Read the original ↗

Citationpoppendieck.com

In the build queue

Be first to run it.

Lean Software Development is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchMy team's lead time is around 6 weeks for most features and I suspect most of that is wait time, not actual development. Can we do a waste audit and value stream map to find out where the time is really going?