AI Makes Technical Execution Cheap. Judgment Stays Scarce.
Hiring more developers or replacing them with AI agents leaves the same question unanswered: who will make the decisi...
Mary Poppendieck: Stop Feeding the Queue
9 min read
She Made Waiting Impossible to Ignore
12.10.2026, By Stephan Schwab
A software team can be busy all day and still deliver almost nothing. Requirements wait for clarification, code waits for review, releases wait for approval, and customers wait for value. Mary Poppendieck gave leaders a better way to see that system. Lean software development does not ask developers to type faster. It asks the organization to stop feeding queues, build quality into the work, and optimize the whole path from a real need to a useful result. That remains an uncomfortably practical management lesson.
Lean Did Not Arrive as a Software Costume
Poppendieck brought experience from software, manufacturing operations, and product development into one view of delivery.
Mary Poppendieck did not discover Lean in a certification catalogue and paste factory vocabulary onto a backlog. She began as a process-control programmer, later managed information technology in manufacturing, and worked in product development. In her account of that career, she describes early programming at Bell Labs, automated vehicle controls at General Motors, and control systems for the machines that made tape at 3M.
That history matters because her argument was never that software should become an assembly line. Software development contains discovery. Teams learn what customers need, what the system can support, and which assumptions were wrong while they build. The useful lesson from Lean was to organize that learning so it moved, rather than burying it under inventory, handoffs, and premature commitments.
Mary and Tom Poppendieck gave that translation a durable form in Lean Software Development: An Agile Toolkit in 2003, followed by books on implementation, leadership, and the Lean mindset. Their work connected customer value, flow, quality, learning, respect for people, and whole-system thinking. It also gave software leaders a vocabulary for a problem they could already feel: everybody appeared occupied, yet the business waited months for answers.
Most of the Work Is Waiting
A full queue proves that work is waiting. Find what holds it there before adding more work.
In her 2005 analysis of the quality-speed compromise, Poppendieck describes mapping the path from a customer request to deployed software. In the value-stream maps produced in her classes, the request typically spent less than one fifth of its total time being worked on. For the rest, it waited in a queue.
That pattern is painfully easy to reproduce. A workflow change waits for a product decision. The decision becomes a ticket and waits for a team. The code waits for review. The review exposes an integration question and the work waits for a vendor. Testing begins at the end, finds a defect, and sends the change back through the same obstacle course. Every department can report respectable utilization while the customer receives nothing.
Management often responds by feeding the system harder. Add more scope. Start another initiative. Ask each specialist to stay fully occupied. Buy an AI tool so developers can produce code faster. The queues grow, coordination expands, and lead time gets worse. Then somebody schedules a workshop about velocity.
The Lean response is less theatrical. Limit what enters the system. Finish a small valuable change. See where it waits. Remove that constraint. Repeat.
This does not mean a board full of colored cards is Lean. A board can display congestion with admirable visual consistency. The work moves only when the organization changes the conditions creating the congestion.
Local Productivity Can Damage Delivery
Optimizing one role makes the whole system worse when it creates work faster than the next constraint can absorb it.
Most organizations measure the pieces because pieces are easy to assign. Analysts should produce more requirements. Developers should close more tickets. Testers should find more defects. Operations should protect stability by reducing releases. Procurement should reduce vendor rates. Each function can hit its target while delivery collapses between them.
Poppendieck’s alternative is to optimize the whole. The unit of concern is the path from need to useful outcome, including business decisions, development, testing, deployment, operations, support, and customer learning. Her essay on software development productivity argues that useful productivity concerns how effectively ideas become valuable software, rather than how many lines of code people produce.
Imagine a logistics company automating exception handling. Operations knows which cases ruin a morning. A vendor owns the transport platform. An internal developer maintains the integration. Finance controls the rules for compensation. If each party works from its own queue, the company gets impressive activity and slow learning. Nobody owns the complete result.
Put those people around one thin outcome instead: detect one high-cost exception, route it correctly, verify the result, and observe it in use. The software boundary becomes visible. So do the decisions. The team can now learn whether the automation helps before it encodes every imagined exception into a small private bureaucracy.
That is what software flow looks like when the management principle reaches the code and the operating model. The whole path improves, or the customer still waits.
Quality Belongs Inside the Flow
Testing at the end turns defects into inventory and quality into a scheduling problem.
Lean is regularly mutilated into a cost-cutting slogan. Remove people, reduce buffers, demand more output, and call the resulting fragility efficient. Poppendieck’s work points in the opposite direction. Quality must be built into the work because defects discovered late create queues, rework, and delayed learning.
Her 2005 essay puts testing close to coding, with frequent integration and automated checks. The principle is broader than a particular test practice. Find uncertainty where it enters. Turn a business rule into an example while the people who understand it are available. Check an integration while the change is still small. Make a deployment routine enough that release day does not require a committee and a favorable wind.
This is where Mary Poppendieck’s story meets Kent Beck’s small feedback loops. Beck gives the development rhythm: test, change, refactor, learn. Poppendieck widens the frame. If the tested change still spends twelve days waiting for approval, the organization has protected one part of the flow while neglecting the whole.
Speed and quality are not natural enemies. Delay and late discovery make them look that way. Moving evidence closer to the decision lets a team move faster because it wastes less time building, transferring, rediscovering, and repairing the wrong thing.
Decide at the Last Responsible Moment
Keeping options open is disciplined when the team is actively learning what will make the decision sound.
Traditional project control likes early certainty. Specify the complete workflow. Select the platform. Lock the integration design. Estimate the entire program. Make change expensive enough that people stop mentioning what they have learned.
Lean software development treats premature certainty as waste. A decision made before the necessary information exists is merely a guess wearing a deadline. Poppendieck argued for delaying detailed requirements until closer to implementation, when the team knows more and can avoid maintaining a queue of changes to old guesses.
This idea is easy to abuse. “Decide later” cannot become permission to leave a team blocked while executives avoid an uncomfortable choice. The last responsible moment is the point before delay closes a valuable option, not the afternoon after the option died. Teams need clear boundaries, fast access to decision-makers, and small experiments that create better evidence.
For a new AI-assisted claims workflow, that might mean committing early to privacy boundaries, auditability, and human override while delaying the choice of orchestration framework. Test the riskiest claim type with real operators. Learn where the model fails. Preserve the ability to replace it. The architecture should buy information before it buys permanence.
AI Can Feed the Queue at Machine Speed
Cheaper code production increases the value of deciding what the delivery system can responsibly absorb.
AI coding tools make Poppendieck’s lesson more relevant. They can reduce the time needed to produce a plausible implementation. Faster coding does not settle a product decision, reconcile departments, grant production access, repair a vendor relationship, or establish which failures the business can accept. Tools can help with that work. The authority and accountability still need an owner.
If a team already has twenty changes waiting for review, generating forty more is not acceleration. If deployment happens monthly because the system is fragile, faster code adds inventory. If nobody owns an AI-built internal tool after its creator changes jobs, the organization has produced software without producing a service.
This is the modern form of local optimization. The coding step becomes faster, so leadership declares the delivery system faster. Reality keeps the full invoice: more review, more tests, more dependencies, more operational behavior, and more guesses that somebody must reject.
The useful question is not how much code the agent produced. Ask whether one valuable change reached use sooner, with enough evidence to trust it and enough ownership to support it. When AI makes a company responsible for software, Lean thinking prevents cheap output from becoming expensive congestion.
The Leadership Decision
Leaders control how much work enters the system, how quickly decisions arrive, and whether teams can improve the whole path.
A CTO cannot fix flow by telling developers to focus harder. Some constraints sit in the codebase. Others live in budgets, approval structures, team boundaries, vendor contracts, release policy, and executive indecision. Leadership owns the conditions around the work.
Start with one request that matters. Trace it from the moment the business asks for it until somebody uses the result. Count the waiting. Find the handoffs. Ask why testing happens where it does. Notice which decision has no owner and which specialist has become a compulsory stop for every change.
Then remove one real constraint. Reduce work in progress. Put the people who build, operate, and use the system around the same outcome. Give a team authority over a service it can understand and support. Move quality checks forward. Break a dependency instead of adding a coordination ceremony around it.
Poppendieck warned in 2019 against transformations pursued for their own sake. Organizations do not need to “do Lean” as a new identity. They need products and services customers value, a working environment that uses people’s judgment, and a delivery system capable of learning before the market finishes the lesson for them.
Her enduring contribution was to make the delay visible. A team can look busy while value starves in a queue. Once leaders see that, feeding the queue becomes a choice.
References
- An Interview, Mary Poppendieck
- Software Development Productivity, Mary Poppendieck
- Breaking the Quality-Speed Compromise, Mary Poppendieck
- Mary Poppendieck author biography, O’Reilly
- Lean Software Development: An Agile Toolkit, Addison-Wesley
- Implementing Lean Software Development, Addison-Wesley
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
Process Theater Takes Hold
BergMotor's QA team in Passau reads QuantumMind's integration documentation and asks the question nobody wanted to hear: where is the safety analys...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- AI Computer Use Is Not a Business Contract (09.10.2026)
- When Everything Is Finally Under Control (05.10.2026)
- AI Makes Technical Execution Cheap. Judgment Stays Scarce. (26.09.2026)
- The Agent Escaped. Who Left the Door Open? (24.09.2026)
- What an AI Agent Actually Is (21.09.2026)