How Lean Thinking Shapes Agile Project Management

1. Articles
2. How Lean Thinking Shapes Agile Project Management

How Lean Thinking Shapes Agile Project Management

By Christopher Scordo, PMP, ITIL · Last updated: August 11, 2026

On this page

• Agile is a descendant of Lean, not a sibling
• The five principles, and the question each one really asks
• Ohno's seven wastes and what changed in translation
• The 2026 shift: PMI retired the metric that hid the waste
• Why full utilization is the trap
• What the 2026 delivery data actually shows
• Three Lean statistics you should stop repeating
• Where to start on Monday
• Frequently asked questions

Almost every article about Lean and Agile opens the same way. A Toyota assembly line in the 1950s. Five principles in a numbered list. Seven wastes in a bulleted list. A closing paragraph about how it applies to software.

I read the six pages currently ranking for this topic before writing this one. All six follow that outline, none cites a study, and none mentions a certification exam. The median publication date is 2023.

That is a missed opportunity, because 2026 is the year this relationship became load-bearing. PMI's own agile guidance changed, and the metric most Agile teams have reported for fifteen years was formally demoted in favor of a measurement set that is Lean end to end. If you manage delivery, that change matters more than the Toyota story.

Agile is a descendant of Lean, not a sibling

The ranking pages cannot agree on this. Atlassian argues Lean is not a subset of Agile. Easy Agile and KaiNexus merge the two into "Lean Agile." Asana treats them as siblings. A reader coming to the topic cold gets three incompatible answers.

PMI took a position in July 2026. The Agile Practice Guide—Second Edition has a section titled "Lean Thinking Concepts," and it opens like this: "One way to think about the relationship between Lean, agile, and the Kanban Method is to consider agile and the Kanban Method as descendants of Lean thinking. In other words, lean thinking is a superset, sharing attributes with agile and Kanban." The framing is offered as one way to see it, but the superset claim itself is stated flatly. One section earlier, the guide names the concepts they share: "focus on value," "small batch sizes," and "elimination of waste."

This is not a semantic point. If Lean is the superset, your Agile ceremonies are one instantiation of Lean thinking rather than the thing itself. A team can run every Scrum event on schedule, hit its Definition of Done, close every sprint cleanly, and still violate all five Lean principles. That combination is common, and it is the diagnosis most struggling Agile teams actually need.

Nearly fifty years of one argument about waiting

What each step actually handed project managers

• 1978  Waiting became a category you count, not a condition you tolerate.
• 1988  A name that traveled outside the factory.
• 1996  Value, value stream, flow, pull, perfection — a sequence, not a menu.
• 2003  Partially done work and task switching finally got names.
• 2009  “Capacity utilization increases queues exponentially.”
• 2026  The Lean measurement argument wins inside PMI's own guidance.

The five principles, and the question each one really asks

James Womack and Daniel Jones set out the five principles in Lean Thinking in 1996 and, the same year, in Harvard Business Review. Every competing page lists them. Almost none tells you what to do with the list. Here they are with the diagnostic question each one is really asking of your project.

1. Specify value from the end customer's perspective.

Womack and Jones are blunt that value "can only be defined by the ultimate customer." The question: can you name the specific person who would notice if this work item quietly disappeared from the backlog? If not, you are managing activity, not value.

2. Identify the value stream.

The value stream is the full set of actions required to carry a product through problem-solving, information management, and physical transformation. The question: have you drawn yours, including the waiting? Most teams have mapped their process steps. Very few have mapped the gaps between them, which is where the time goes.

3. Make value flow.

Flow means the value-creating steps run continuously, with no waiting, downtime, or scrap within or between them. The question: what percentage of a work item's elapsed time is anyone actually touching it?

4. Let the customer pull.

Womack and Jones define pull simply: "no one upstream should produce a good or service until the customer downstream asks for it." The question: what triggers work starting on your team, a genuine downstream request or the fact that somebody had capacity? If it is the second, you have a push system wearing a Kanban board.

5. Pursue perfection.

There is no endpoint to reducing effort, time, cost, and mistakes. The question: what got measurably better last quarter? Not what the retrospective discussed, but what number moved.

PMI's own section on Lean portfolio management reproduces these five almost verbatim, one level up, and adds the operational point most portfolio groups miss: high-performing Lean portfolio groups "limit the portfolio WIP by capping the number of epics actively being worked on."

Ohno's seven wastes and what changed in translation

Taiichi Ohno's seven wastes are usually presented in a modern reordering as TIMWOOD, which is a mnemonic rather than a citation. In Ohno's own book, in his own order, they are: overproduction, time on hand (waiting), transportation, processing itself, stock on hand, movement, and making defective products.

Mary and Tom Poppendieck translated the list for knowledge work in 2003: partially done work, extra processes, extra features, task switching, waiting, motion, and defects. A trap here, and it is the authors' doing rather than the internet's. The list most Agile sites label "the seven principles of Lean software development" (eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect people, optimize the whole) is from the Poppendiecks' second book, published in 2006. The 2003 book has a different seven. Name the edition when you quote it.

For project managers, the two wastes that matter most are the two with no visible manufacturing analogue: partially done work and task switching. Neither shows up on a status report. Both are obvious within a week on a board with genuine work-in-process limits.

The 2026 shift: PMI retired the metric that hid the waste

The most consequential Lean development of 2026 was not a new framework. It was a deletion.

The Agile Practice Guide—Second Edition states that it "no longer recommends tracking story point velocity outside the team that produced it or using it to assess performance, forecast at scale, or set delivery targets." The guide is direct about why: velocity gets weaponized for comparison, story points carry false precision across teams, and when velocity becomes a target, teams inflate estimates or split work unnaturally to hit it.

What replaces it is a Lean measurement set: throughput, cycle time, lead time, work in process, escaped defects and rework, and queue length. Every one of those six measures an attribute of the system rather than the output of the people inside it. Velocity answered "how much did the team produce." Flow metrics answer "how long did the work wait, and where." Lean has argued for decades that the second question is the one with the money in it. In 2026, PMI's guidance agrees.

Why full utilization is the trap

This is the most counterintuitive idea in Lean for project managers, because resource utilization is usually the number a PMO is asked to defend.

Donald Reinertsen's The Principles of Product Development Flow puts it as a numbered principle: "Capacity utilization increases queues exponentially." Not linearly. He also argues that "queues are the root cause of the majority of economic waste in product development," while noting that only about 2 percent of product developers measure them at all. His prescription is specific and uncomfortable: "Don't control capacity utilization, control queue size."

A team at 95 percent utilization is not marginally slower than a team at 75 percent. It is in a different regime, where every new arrival waits behind a queue that no longer drains. The busyness is real. The throughput is not.

The honest caveat is that field evidence is more nuanced than theory. The best empirical study on this question tracked more than 8,000 work items across five teams over four years and found, as expected, that lower WIP is associated with shorter lead times. It also found WIP correlated with productivity, which is inconsistent with the usual claim that low WIP raises productivity, and it notes that no published research from real cases establishes what an optimal WIP limit should be. So anyone selling you a specific WIP number is guessing. Set a limit, watch cycle time for six weeks, adjust. That is the Lean method anyway.

The bigger mistake is capping work in only one place. Most teams put WIP limits on the board and stop there, which is the level with the least leverage of the three available.

Three places to cap work in process. Most teams use one.

Why the board alone does not work: a WIP limit on the team board, with an uncapped portfolio pushing epics in from above and people split across three projects below, does not reduce work in process. It relocates the queue.

The Agile Practice Guide makes all three points, but in three sections spread nearly forty pages apart, so they read as unrelated advice rather than as one control system. Portfolio: high-performing groups "limit the portfolio WIP by capping the number of epics actively being worked on." Team: limiting WIP "exposes bottlenecks, reduces context-switching, accelerates flow, and improves throughput." Individual: people split across projects "multitask and task-switch," which "reduces the throughput of the team's work." Cap one level and the queue moves to another. Cap all three and it drains.

What the 2026 delivery data actually shows

Start with a correction, because most content on this subject is now out of date: DORA publishes five delivery metrics, not four. Change lead time, deployment frequency, and failed deployment recovery time make up throughput. Change fail rate and deployment rework rate make up instability. Rework rate was added in 2024. If a page still says there are four DORA metrics, it has not been updated in two years.

DORA's 2025 report, based on responses from nearly 5,000 technology professionals, concludes that "AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones." It observes a positive relationship between AI adoption and both delivery throughput and product performance, and at the same time a continuing negative relationship between AI adoption and delivery stability.

That is a Lean result in modern dress. Increase the arrival rate into a system without increasing downstream capacity and you do not get more output, you get a longer queue and more instability. Ninety percent of respondents now use AI at work. Fewer than one in ten report a change lead time under one hour, and roughly a quarter deploy less often than monthly. The constraint was never typing speed. DORA's own recommendation follows directly: value stream management "acts as a force multiplier for AI, ensuring that local productivity gains translate into measurable improvements in team and product performance."

Atlassian's State of Teams 2026, based on 12,035 knowledge workers plus a separate panel of 173 Fortune 1000 executives, is vendor research and should be read as such, but one pairing is hard to dismiss: 89 percent of those executives say AI increases speed, while 6 percent can point to clear examples of organization-wide AI return. Meanwhile 87 percent of the knowledge workers report they lack the capacity to coordinate because everyone is in execution mode. Speed at the task level, no measurable gain at the system level, an overburdened middle. Ohno had a word for that shape.

Two more anchors. A GAO review of federal efficiency initiatives documents Lean Six Sigma work that doubled the Marine Corps' monthly repair and maintenance output for M-16 rifles from 625 rifles to 1,250. And a 2024 meta-analysis covering 127 studies, 969 effect sizes, and 30,741 firms supports the positive link between lean, agile, and combined "leagile" strategies while also finding evidence for trade-offs rather than pure cumulative gains. Combining Lean and Agile works. It is not free.

Three Lean statistics you should stop repeating

Lean content has a citation problem. Three numbers circulate constantly in Agile training material, and all three fall apart when you chase them to the source. I have used two of them myself in the past.

"64 percent of features are rarely or never used."

This traces to a keynote Jim Johnson of the Standish Group gave at XP 2002. What he presented was a chart showing 45 percent of features never used and 19 percent rarely used. The famous 64 percent is a sum somebody else performed. The underlying study was never published, and Standish has since given two irreconcilable accounts of its sample: one contact reported four internal applications, while Johnson himself later described 100 mission-critical applications across roughly 25 organizations. Do not put this number in a slide.

"Multitasking costs 40 percent of your productivity."

Usually attributed to a 2001 task-switching paper in the Journal of Experimental Psychology. That paper ran four experiments with 108 participants and measured switching costs in fractions of a second. It contains no 40 percent finding; the figure comes from an informal extrapolation one author offered in press coverage. The Agile Practice Guide—Second Edition carries a version of this claim, stating that "teams experience productivity losses somewhere between 20% and 40% when task-switching," without a citation. The direction of the effect is well supported. The precision is not.

"Most teams run under 15 percent flow efficiency."

No traceable primary study exists for this; it circulates between vendor blogs. The closest thing to hard data comes from construction time studies, and they disagree sharply: one Swedish study puts direct work at 25.5 percent of work time with 22.8 percent lost to waiting and interruptions, while a later observational study puts direct work at 49.1 percent. The useful conclusion is the methodological one, that the more detailed the study, the more waste it uncovers. Measure your own. A rough number from your system beats a precise-sounding number from someone else's.

Where to start on Monday

The failure mode with Lean is starting from the framework. Somebody reads about value stream mapping and schedules a two-day workshop before anyone has established where the work is actually losing time. Start from the symptom instead.

Start from the symptom, not the framework

Queue problem

Trim the queue in front of the busiest step before you add anyone to it.

Watch: Queue length, lead time

Utilization trap

Cut the number of items started, not the number of people working.

Watch: WIP, throughput

Rework loop

Move the feedback earlier. Rework is waste created upstream, paid downstream.

Watch: Escaped defects, rework rate

Value definition

The failure happened before the backlog item existed. Go back to the customer.

Watch: Benefit realized vs. forecast

Whichever branch you land on, the first move is the same and it is unglamorous: pick ten work items your team finished in the last quarter and, for each one, write down the date it was requested, the date someone first touched it, and the date it was delivered. That is an afternoon of work and it will tell you more about your system than a quarter of velocity charts. In most teams the gap between "requested" and "first touched" is the largest number on the page, and nobody had ever looked at it.

That is Lean thinking. Not the vocabulary, not the Japanese terms, not the Toyota story. Just the discipline of measuring how long value waits, and then refusing to look away from the answer.

Frequently asked questions

What is Lean thinking in project management?

Lean thinking is a management philosophy focused on maximizing customer value while minimizing waste. In project management it shows up as five principles: define value from the customer's perspective, map the value stream, make work flow without interruption, let demand pull work through the system, and continuously pursue improvement. Its practical contribution is a shift in what you measure, from how much the team produced to how long the work waited.

Is Lean the same as Agile?

No. PMI's Agile Practice Guide—Second Edition treats agile and the Kanban Method as descendants of Lean thinking, with Lean as the superset. Agile is a set of values and practices for responding to change in delivery. Lean is the broader thinking system about value and waste that Agile inherited from.

Do I have to abandon Scrum to apply Lean thinking?

No, and that framing is the trap. Lean is the superset, so Lean thinking is a lens you apply to whatever you already run. The practical change is usually additive rather than substitutive: keep your events, add work-in-process limits, and start tracking lead time alongside whatever you track now.

What are the seven wastes?

In Taiichi Ohno's original formulation: overproduction, time on hand (waiting), transportation, processing itself, stock on hand, movement, and making defective products. The Poppendiecks' 2003 knowledge-work translation gives: partially done work, extra processes, extra features, task switching, waiting, motion, and defects.

What is a pull system?

A pull system starts work only in response to a genuine downstream request rather than because upstream capacity became available. A board with work-in-process limits is the most common implementation in project work.

How do I measure flow on my team?

Start with the six metrics named in the Agile Practice Guide—Second Edition: throughput, cycle time, lead time, work in process, escaped defects and rework, and queue length. If you only have appetite for one, use lead time, because it includes the waiting that every other view tends to hide.

If you want this material worked through with an instructor and a real project to apply it to, our live PMP classes spend a good deal of time on value-based delivery and flow.

Sources:

PMI and Agile Alliance, Agile Practice Guide—Second Edition (July 2026). Sections 2.2 (p. 10), 2.3 (Lean Thinking Concepts, p. 11), 4.7.1 (p. 57), 5.5.1–5.5.3 (Flow Metrics, p. 76), and 6.5 (Lean Portfolio Management, p. 95).

James P. Womack and Daniel T. Jones, Lean Thinking: Banish Waste and Create Wealth in Your Corporation (Simon & Schuster, 1996), pp. 10, 16, 19, 21, 25, 67; and "Beyond Toyota: How to Root Out Waste and Pursue Perfection," Harvard Business Review, September–October 1996, pp. 140–158 (reprint 96511).

Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Productivity Press, English ed. 1988), pp. 19–20.

John F. Krafcik, "Triumph of the Lean Production System," Sloan Management Review 30, no. 1 (Fall 1988): 41–52.

Mary Poppendieck and Tom Poppendieck, Lean Software Development: An Agile Toolkit (Addison-Wesley, 2003), chapter 1; and Implementing Lean Software Development (Addison-Wesley, 2006).

Donald G. Reinertsen, The Principles of Product Development Flow (Celeritas, 2009), principles Q2 (p. 56), Q3 (p. 59), and Q13 (p. 75); chapter 1, p. 5.

Dag I. K. Sjøberg, "An Empirical Study of WIP in Kanban Teams," ESEM '18 (ACM/IEEE, 2018). More than 8,000 work items across five teams over four years.

Katharina Matz, Kai Foerstl, and Robert Suurmond, "Perfect Couple or Toxic Relationship? A Meta-Analysis of the Effects and Interplays of Lean and Agile Strategies to Improve Performance," Journal of Business Logistics 45, no. 3 (2024). 127 studies, 969 effect sizes, 30,741 firms.

DORA, 2025 DORA Report: State of AI-Assisted Software Development (Google Cloud, September 23, 2025). Nearly 5,000 respondents.

DORA, "DORA's Software Delivery Metrics" (updated January 5, 2026).

Atlassian, State of Teams 2026 (April 27, 2026). 12,035 knowledge workers surveyed January–February 2026.

U.S. Government Accountability Office, Streamlining Government: Key Practices from Select Efficiency Initiatives Should Be Shared Governmentwide, GAO-11-908 (September 2011).

Joshua S. Rubinstein, David E. Meyer, and Jeffrey E. Evans, "Executive Control of Cognitive Processes in Task Switching," Journal of Experimental Psychology: Human Perception and Performance 27, no. 4 (2001): 763–797.

Per-Erik Josephson and Lasse Saukkoriipi, Waste in Construction Projects: Call for a New Approach (Chalmers University of Technology); and Bo Terje Kalsaas, "Work-Time Waste in Construction," Proceedings IGLC-18 (2010).

Mike Cohn, "Are 64% of Features Really Rarely or Never Used?"; and Martin Fowler's contemporaneous report from XP 2002.