Lean and Agile Principles

Lean and Agile principles are claims about how work behaves; where value is created, where it waits, and what the people doing the work can see that no outside method can. Practices arrive first in most organisations, and the principles surface later, usually the week a practice stops fitting the situation in front of a team.

---

What Are Lean and Agile Principles? The Lean-Agile Mindset Defined

Lean and Agile principles are the combined belief set behind two bodies of thought: the Agile Manifesto and Lean Thinking, held together by what the Scaled Agile Framework calls the Lean-Agile Mindset: the combination of beliefs, assumptions, attitudes and actions of leaders and practitioners who embrace both.

That definition puts belief before behaviour, and the ordering matters for anyone deciding where to start. Jim Highsmith, writing in Agile Project Management, states the position plainly: “Agility is principally about mindset, not practices.” Richard Knaster and Dean Leffingwell make the same move in their treatment of the Lean-Agile Mindset, where the mindset is the precondition for every practice that follows rather than a summary of them. The two source bodies are the Manifesto for Agile Software Development, signed by Kent Beck and sixteen co-authors in 2001, and Lean Thinking as reframed for product development. Everything else on this page, the twelve Manifesto principles, the five Lean Thinking steps, the flow economics underneath both, descends from those two.

Growth Mindset: Why Thinking Must Change Before Practice

A growth mindset is the belief that an organisation’s own thinking can change, and SAFe treats it as the entry condition for adopting the Lean-Agile Mindset at all. The distinction it draws is between people who grasp the core ideas and people who follow rules written by someone who did.

The practical consequence shows up in how a team handles a rule that does not fit. A team holding the rules has one option when the situation departs from the template: apply the rule anyway and absorb the cost. A team holding the ideas has a second option, which is to reason from the idea the rule was protecting and choose differently. That second option is the whole return on understanding the principles, and it is unavailable to anyone who learned the practice as a procedure.

This is why organisations that install a framework competently still report the same flow problems eighteen months later. The installation was faithful and the beliefs underneath it never moved. Planview’s practitioner guidance on Agile and Lean describes the two as complementary bodies of thought precisely because neither is reducible to a ceremony list: each is a way of reading a situation.

The precondition is uncomfortable to state to a leadership group, because it asks them to accept that their current thinking is part of what needs to change. Teams sense the difference quickly: they can tell whether a principle is something the organisation believes or something it has agreed to be measured on.

Two Lineages: The Agile Manifesto and Lean Thinking

The set has two parents, and they were not related by design. The Agile Manifesto came from seventeen software practitioners looking for common ground across competing lightweight methods; Lean Thinking came from Western researchers trying to explain Toyota’s manufacturing performance to an audience that assumed mass production was the only serious option.

Their vocabularies overlap because their subject overlaps. Both are theories of how value moves through a system of people, and both conclude that the movement matters more than the effort at any single station. Where the Manifesto reaches for working software as the measure of progress, Lean Thinking reaches for value defined by the customer. Where the Manifesto asks for self-organising teams, Lean Thinking asks for respect for the people closest to the work.

The overlap is not perfect, and the seams are worth knowing. Lean Thinking carries a systemic apparatus the Manifesto never developed: value streams, pull, waste categories, and the queueing economics a later generation of authors supplied. The Manifesto carries a stance on human collaboration, individuals and interactions, face-to-face conversation, trust, expressed more directly than Lean’s manufacturing-era texts manage.

Reading them as one set costs nothing and explains a great deal, particularly why a team can be fluent in one vocabulary and blind to the constraint the other names. Practitioners who hold both can move between the team question and the system question without changing frameworks.

How This Hub Is Organised

This page defines the whole set and hands each individual principle to a page that treats it in depth. The attribute pages under /principles/ each own one principle, one model or one mechanism, which keeps the depth out of the hub and the map inside it.

The sequence below runs from origin to application. The lineage section dates the two traditions and their meeting point. Two reference sections state the Manifesto’s four values and twelve principles, and Lean Thinking’s five steps, in their published form. Comparison sections then separate the two House of Lean models, sort the vocabulary of pillars, values, principles and practices, and read Lean and Agile against each other principle by principle. The flow and economic sections supply the mechanics, queues, batch size, WIP limits, Little’s Law, Cost of Delay, variability, that both traditions assume. Respect for people follows, then the organisation-level application, then the open argument about how the set spreads beyond a single team.

A reader who wants one principle can jump to its attribute page from the routing table in the Manifesto section. A reader who wants the set as a system is better served reading in order, because the later sections assume the definitions the earlier ones fix. Either route ends in the same place: a reader who can name which principle their own situation is testing.

---

How Lean Thinking and the Agile Manifesto Met: From the Toyota Production System to Snowbird 2001

Lean thinking and the Agile Manifesto grew up in the same decade from the same root: MIT researchers studying the Toyota Production System coined the word “Lean” in the late 1980s, and by February 2001 lean thinking was, in Ian Mitchell’s phrase, in a sort of ascendancy when the Manifesto was written.

The conventional story has Lean and Agile as separate philosophies that converged later, and the dates do not support it. Planview’s overview of Lean and Agile treats them as a single practitioner tradition for this reason. Here is the lineage in date order, kept short because the page’s substance is the principles themselves.

Lean Production Before Software: Toyota and The Machine That Changed the World

The term “Lean” is an outsider’s word for an insider’s system. MIT researchers studying the Toyota Production System needed a name for what they were observing, and the label they produced travelled further than the detail behind it.

James P. Womack and Daniel T. Jones gave that label its audience with The Machine That Changed the World in 1990, a study that set lean production against mass production and showed the performance gap in numbers a Western manufacturing executive could not dismiss. The book’s argument was comparative: two systems, the same industry, radically different results in quality, inventory and time. Mass production optimised each station for local efficiency and accumulated inventory between them. Lean production optimised the movement of work and treated the inventory as evidence of a problem.

Software had no equivalent literature in 1990 and borrowed this one. The borrowing was uneven, because a factory’s inventory is visible on the floor and a development organisation’s inventory is a queue in a tracking tool. Womack and Jones supplied the categories anyway, and the vocabulary that reached software, value, value stream, flow, pull, waste, arrived pre-formed from the manufacturing study rather than being invented for knowledge work.

That inheritance explains a persistent friction in Lean and Agile principles as practitioners meet them: the mechanics are stated in manufacturing terms while the work they describe is invisible. Most translation problems in this field trace back to that single fact.

Snowbird 2001: Seventeen People and One Manifesto

Seventeen people met at Snowbird, Utah, between 11 and 13 February 2001, and produced the Manifesto for Agile Software Development in three days. They were practitioners of competing lightweight methods looking for whatever they agreed on.

What they agreed on was short: four value statements and twelve principles. Ian Mitchell of Scrum.org, writing on the Agile Manifesto from a lean perspective, places the meeting in its intellectual context; lean thinking was already in a sort of ascendancy in 2001, which means the room was not innocent of it. Several attendees had read Womack and Jones. The Manifesto does not cite lean, and it did not need to; the ideas were in circulation among exactly the people who wrote it.

Mitchell draws the conclusion directly: attempts to tease lean and agile apart “can often seem contrived and artificial.” A distinction maintained by consultancies and framework vendors turns out to be much harder to sustain when read against the text and the dates.

The rhetorical question of why the Manifesto still holds has since been studied on its own terms. A Rhetorical Analysis of the Agile Manifesto on its 20th Anniversary, published in the Journal of the Southern Association for Information Systems in 2023, convened a focus group of eight industry experts and academics to examine the document’s lasting appeal. Their subject was the wording: a short, hedged, comparative text that has outlasted most of the methods it was meant to reconcile.

Seventeen Authors, Seventeen Readings of Agility

Mitchell adds a caution that changes how the Manifesto should be read: agility meant, or came to mean, something different to each of the seventeen attendees. The document is a negotiated artefact rather than one author’s theory.

This matters when a team argues about what the Manifesto “really means.” There is no single authorial intent to recover, because the text was written to be acceptable to people who disagreed about method. The four values are comparative statements, one thing valued over another, rather than prohibitions, and that hedged construction was the price of consensus in the room.

Treating the Manifesto as a shared artefact has two practical effects. It lowers the stakes of interpretation disputes, since the authors themselves diverged within months of signing. And it locates authority in the reasoning rather than the wording: a team that can explain why responding to change beats following a plan in their own situation is doing what the signatories did, while a team quoting the line as a rule is doing something the signatories explicitly declined to ask for.

The seventeen went on to build different things; Scrum, Extreme Programming, Crystal, DSDM, later Lean Software Development and the scaling frameworks. Those divergent careers are the best available evidence that the Manifesto fixed a floor rather than a doctrine.

---

The Four Agile Values and the 12 Principles Behind the Agile Manifesto

The Manifesto for Agile Software Development states four values and twelve supporting principles, published at agilemanifesto.org, and Richard Knaster and Dean Leffingwell note that the twelve principles take the four values a step further by describing the behaviour the values imply.

This section gives both lists in their published form, groups the twelve into six themes a reader can hold in memory, and maps each principle to the attribute page that treats it in depth. The grouping is a reading aid; the numbering is the Manifesto’s own.

The Four Values of the Manifesto for Agile Software Development

The four values are comparative statements, each naming two real goods and expressing a preference between them. The published text closes with the qualifier that the items on the right have value, and the authors value the items on the left more.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The construction repays attention. Each line concedes that the right-hand item is worth something, which rules out the reading that documentation, contracts, plans and tools are waste. What the values claim is a tie-breaking rule: when the two conflict and a person must choose, choose the left.

Read that way, the values are decision aids for ambiguous moments rather than statements of organisational identity. A team that cannot produce a recent example of choosing the left-hand item at a cost has not applied them, whatever its ceremony calendar says. Customer collaboration over contract negotiation costs something the first time a scope conversation would have been easier to settle by pointing at a signed document.

The four also explain why the twelve principles exist. A comparative preference does not tell anyone what to do on Monday, and the principles convert each preference into behaviour; delivery frequency, working software as the measure of progress, direct conversation, trust in motivated individuals.

The 12 Principles Grouped Into Six Themes

The twelve Principles behind the Agile Manifesto are published as a flat list, and grouping them into six themes makes the list usable without changing its content. Agile Alliance presents the same twelve in its own 12 Principles Behind the Agile Manifesto reference.

The six themes are customer and change; delivery cadence; people; pace and technical excellence; simplicity and self-organising teams; and reflection. Each theme collects principles that answer the same underlying question, which makes it easier to notice when a team honours one theme and ignores another.

Two principles deserve their exact wording. Principle 3 reads: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Principle 10 reads: “Simplicity, the art of maximizing the amount of work not done, is essential.”

Twenty years of retrospective literature has tested whether the set held. 20 Years of the Agile Manifesto: on Agile Project Management, in Management and Production Engineering Review (2023), examines how the values and principles fared across two decades of practice and finds the text more durable than the methods built on it.

Customer, Change and Delivery Cadence

Principles 1, 2 and 3 handle the customer relationship and the rhythm of delivery. Principle 1 makes customer satisfaction through early and continuous delivery of valuable software the highest priority; principle 2 welcomes changing requirements even late in development; principle 3 sets the delivery interval at weeks rather than months, preferring the shorter end. Principle 4 adds that business people and developers must work together daily throughout the project.

These four are the theme most organisations adopt first, because they map onto visible artefacts: a release calendar, a backlog, a change process. The theme is also where adoption most often stops at the surface. Welcoming late change is a statement about funding and commitment structures, not about a ticket workflow, and a two-week delivery interval that ships to a staging environment has satisfied the ceremony and missed the principle.

People, Pace and Technical Excellence

Principles 5, 6, 8 and 9 concern the people doing the work and the conditions they work under. Principle 5 asks for projects built around motivated individuals given the environment, support and trust they need. Principle 6 names face-to-face conversation as the most efficient form of communication. Principle 8 asks for sustainable development at a constant pace indefinitely. Principle 9 asks for continuous attention to technical excellence and good design.

Sustainable development at a constant pace and face-to-face conversation are the two principles teams most quietly drop. The first collides with quarterly commitments made before anyone measured capacity; the second collides with distributed working arrangements that are now permanent for many organisations. Neither collision is resolved by restating the principle; what the principle does is make the trade-off visible and attributable rather than accidental.

Simplicity, Self-Organizing Teams and Reflection

Principles 7, 10, 11 and 12 close the set. Principle 7 makes working software the primary measure of progress. Principle 10 puts simplicity, maximising the work not done, at the centre. Principle 11 holds that the best architectures, requirements and designs emerge from self-organising teams. Principle 12 asks the team to reflect at regular intervals on how to become more effective and then to tune its behaviour accordingly.

This theme is where the Manifesto is most obviously a system rather than a list. Simplicity requires the judgement that a self-organising team develops; a self-organising team without regular reflection stops developing it; and reflection without working software as the measure has nothing reliable to reflect on. Teams that keep the retrospective and drop the other three convert principle 12 into a scheduled meeting.

Where Each Principle Is Treated in Depth

Each Manifesto principle has an attribute page in this cluster that owns its depth, so this list is navigation rather than summary. The routing below sends the four most-searched principle pairs to their pages.

Manifesto principles	Attribute page that owns the depth
3 and 7, delivery frequency, working software as the measure	Iterative and Incremental Development
4 and 6, daily business and developer contact, face-to-face conversation	Collaboration and Communication
5 and 11, motivated individuals, self-organising teams	Empowerment and Autonomy
1, early and continuous delivery of valuable software	Customer Value and Customer Needs

The routing carries an argument about structure. Principles 3 and 7 share a page because delivery frequency without working software as the measure of progress produces cadence with no signal, and the two failure modes are only diagnosable together. Principles 5 and 11 share a page for the same reason in the other direction: self-organisation is the behaviour that trust in motivated individuals makes possible, and an organisation that grants one while withholding the other gets neither.

Principles 2, 8, 9, 10 and 12 are treated across the flow, respect-for-people and improvement sections of this hub and in their own attribute pages; change tolerance under the economic principles, sustainable pace and technical excellence under respect for people, simplicity under Lean’s waste categories, and reflection under kaizen and PDCA. A reader tracking one principle should follow it to its page rather than expecting this hub to resolve it.

Does the Principles’ Numbering Indicate Priority?

The twelve are numbered in the order the published text lists them, not in order of importance or dependency, and the Manifesto itself makes no priority claim beyond that ordering. The six-theme grouping used above regroups the same twelve principles for readability, which is itself evidence that the original sequence is a publication order rather than a ranking; customer-facing principle 1 and reflection principle 12 sit at opposite ends of the list, but the interdependence shown in the simplicity-and-reflection theme above means neither can be dropped as lower priority without weakening the other.

A team that reads principle 1 as the “top” priority and principle 12 as an optional closing item has imported a ranking the text does not state. Treating the twelve as a flat, unordered set, and using the six themes to see how they cluster, is closer to how the Manifesto’s authors presented them.

---

The Five Lean Thinking Principles: Value, Value Stream, Flow, Pull and Perfection

James P. Womack and Daniel T. Jones set out five Lean Thinking principles in their 1996 book of that name: specify value from the customer’s standpoint, identify the value stream, make value flow, let the customer pull, and pursue perfection. PMI’s Disciplined Agile presents the same five, which makes the list unusually stable across sources.

The five are a sequence rather than a menu, and each step assumes the one before it. Value that has not been specified cannot be separated from waste; a value stream that has not been mapped cannot be made to flow; flow that has not been established cannot be pulled. Queue mechanics belong to the flow section later on this page; here the concern is the sequence itself.

Specify Value From the Customer’s Standpoint

Value is what the customer is willing to pay for, defined from the customer’s standpoint and not from the producer’s. Womack and Jones put this first because every later step measures against it, and a value definition supplied by the organisation’s own preferences corrupts everything downstream.

The difficulty is that customers frequently cannot state what they want. Doanh Do’s treatment of the five principles of lean makes the point about latent needs: a customer knows the problem and rarely knows the solution, which means value has to be discovered through interviews, surveys, observation and web analytics rather than collected through a requirements exercise. A stated requirement is evidence about value, not a statement of it.

This has a consequence teams find inconvenient. If value must be discovered, then the discovery work is part of the value stream and its cost is real, which rules out treating customer research as overhead to be minimised. The organisations that skip it do not avoid the cost; they relocate it into building the wrong thing well.

Specifying value also sets the unit of analysis. Value is specified for a particular product or service that a particular customer wants at a particular price and time: not for a department, a capability or a quarter. That specificity is what makes the next step possible, because a value stream can only be traced for something concrete enough to follow.

Identify the Value Stream and Separate Waste

The value stream is every action required to bring a product from concept to the customer, and mapping it sorts those actions into three groups rather than two. The three-way split is the part readers most often miss.

Activity that creates value as the customer defines it is value-adding work. Everything else is waste, and waste divides further. Some waste is non-value-added but necessary; activity that creates nothing the customer would pay for and cannot be removed under current technology, regulation or asset structure. The rest is non-value-added and unnecessary, removable now, and this is the category a first mapping exercise should be hunting.

Conflating the two categories produces the two standard failures. A team that treats all waste as removable attacks regulatory and compliance activity and loses credibility with everyone who understands why it exists. A team that treats all waste as necessary maps the value stream, files the map, and changes nothing.

The mapping also relocates the improvement conversation. Most activity in a knowledge-work value stream is waiting rather than working, and waiting is invisible in any system that measures individual output. A value stream map that shows a feature spending four days in work and thirty-one days in queues has answered the question of where to intervene, and the answer usually has nothing to do with how hard anyone is working. Waste elimination in agile software development gets its own attribute page for this reason.

Make Value Flow and Let the Customer Pull

Flow means value moving through the value stream without stopping, and the third principle asks the organisation to remove whatever interrupts it; batching, handoffs, approvals, rework loops and departmental boundaries that force work to wait for someone’s attention.

Womack and Jones found that flow requires dismantling the functional organisation that mass production built. Work organised by department optimises each department and hands the queue to the next one. Work organised around the value stream gives one team the whole path, which removes the handoff and the wait it creates. This is the same argument organisation-design authors reach through different reasoning later on this page.

A pull system is the mechanism that keeps flow honest: nothing is produced upstream until a downstream customer asks for it. Pull inverts the default, which is to push work forward whenever capacity exists and let it accumulate wherever it cannot proceed. Push feels efficient at each station and produces the queues that dominate lead time. Pull looks idle at some stations and produces shorter lead times, which is why it is difficult to sell to anyone measuring utilisation.

The pair is inseparable in practice. Flow without pull re-accumulates inventory as soon as demand varies, and pull without flow starves a system whose handoffs are too slow to respond. The Authentic Pillars of Lean treats both in depth.

Pursue Perfection as a Repeating Cycle

Pursuing perfection means repeating the first four steps until waste is gone, and Womack and Jones frame it as a cycle with no terminal state rather than a fifth activity to complete. Each pass through the sequence exposes waste the previous pass concealed.

The mechanism is straightforward. Specifying value more precisely reclassifies activity that used to look value-adding. Making value flow faster shortens the cycle, which surfaces queues that were hidden inside a longer one. Establishing pull exposes the variability that push was absorbing with inventory. None of these discoveries is available at the start, which is why a single improvement pass reliably underdelivers against its business case.

Two things follow for practitioners. The first is that improvement capacity has to be permanent, because a cycle with no terminal state cannot be resourced as a project. The second is that early passes should be judged on what they reveal rather than on how much waste they remove, since the removable waste in pass one is usually the least interesting waste in the system.

Perfection as a direction also disciplines the target-setting conversation. An organisation that commits to eliminating waste by a date has misread the principle; one that commits to running the cycle on a cadence has read it correctly. Kaizen and PDCA, treated later on this page, are the practices that make the cycle routine.

---

Two Houses of Lean: The Toyota House and the SAFe House of Lean Compared

Two different diagrams answer to the name “house of lean”: Taiichi Ohno’s Toyota house, whose pillars are Just-in-Time and Jidoka, and the SAFe House of Lean from Richard Knaster and Dean Leffingwell, whose four pillars rest on a foundation of leadership. This section keeps them apart and shows what moved between them.

The translation from the factory to knowledge work changed the structure in two visible ways. Leadership moved from a Toyota management concern into the foundation of the SAFe house, and the stop-the-line devices that were a Toyota pillar landed under the flow pillar. Both changes are legible once the two diagrams sit side by side.

The Toyota House of Lean: Just-in-Time and Jidoka

The Toyota house has two pillars, described by Taiichi Ohno in Toyota Production System: Beyond Large-Scale Production (1988): Just-in-Time and Jidoka. The roof is customer value and the floor is standardised work and kaizen.

Just-in-Time is the production discipline: make only what the next step has asked for, in the quantity asked for, at the time asked for. It is the pull system from Lean Thinking’s fourth principle, implemented with physical signals on a factory floor. The pillar exists to keep inventory out of the system, and it works because inventory that never accumulates cannot hide a problem.

Jidoka is the quality discipline, usually translated as automation with a human touch. A machine or an operator that detects an abnormality stops the line, and the Andon signal calls attention to the stoppage immediately. The design decision inside Jidoka is that stopping production is cheaper than continuing to produce defects, which reverses the intuition every production manager arrives with.

The two pillars are interdependent by construction. Just-in-Time removes the inventory buffer, which means a defect reaches the next step immediately, which makes Jidoka’s stoppage rule necessary. Running Just-in-Time without Jidoka propagates defects at speed. Running Jidoka without Just-in-Time lets a buffer absorb the signal, and the line never has to stop.

Standardised work and kaizen sit underneath both. A standard is what makes an abnormality detectable, and kaizen is what raises the standard once the abnormality has been understood. Ohno’s house is therefore a closed loop rather than a static structure: the floor produces the conditions the pillars need.

The SAFe House of Lean

The SAFe House of Lean, set out by Richard Knaster and Dean Leffingwell in SAFe 4.5 Distilled (2018) and in their treatment of Lean-Agile Mindset, has a roof of value, four pillars, and a foundation of leadership. Knaster and Leffingwell say the house was inspired by the Toyota house and credit Don Reinertsen and Mary and Tom Poppendieck with reframing lean for product development.

The reframing is the point. A product development organisation has no physical line to stop and no material inventory to remove, so the pillars had to be restated in terms that apply to invisible work. Echometer’s summary of the SAFe House of Lean model reflects how widely the restated version now circulates among practitioners who have never read Ohno.

The Roof: Value in the Shortest Sustainable Lead Time

The roof states the goal the rest of the house serves: the maximum value in the shortest sustainable lead time, with the highest quality, for the customer and the enterprise. Each qualifier in that sentence is doing work, and removing any one of them produces a recognisable organisational pathology.

“Shortest” without “sustainable” describes an organisation that hits a date by borrowing from its own future capacity. “Shortest sustainable” without “highest quality” describes one that ships on cadence and spends the following quarter on defects. The roof is a compound test, and a delivery claim that satisfies only part of it has not met it.

The Four Pillars: Respect for People and Culture, Flow, Innovation, Relentless Improvement

The four pillars are respect for people and culture, flow, innovation, and relentless improvement. Respect for people and culture holds the claim that the people doing the work are the ones who can see it; flow holds the queueing and batch-size mechanics; innovation holds the deliberate creation of time and space for new ideas; relentless improvement holds the permanent improvement cycle.

Two of the four have no counterpart in Ohno’s pillars, and their presence marks what product development needed that manufacturing did not. Innovation appears because a development organisation’s output is novel by definition, and a system optimised only for throughput of known work produces none. Relentless improvement is promoted from the Toyota house’s baseline to a pillar of its own, which raises kaizen from a supporting condition to a core element.

The Foundation: Leadership

Leadership is the foundation of the SAFe house, which makes every pillar above it dependent on the behaviour of managers rather than on the diligence of teams. Knaster and Leffingwell are explicit that leaders must be trained in these ways of thinking and be the first practitioners of them.

The Toyota root of this position is Jeffrey K. Liker’s account in The Toyota Way (2004), whose principle is to grow leaders who thoroughly understand the work, live the philosophy, and teach it to others. Liker’s leaders are developed inside the system rather than hired into the top of it. The management obligation that follows from Deming’s claim about systems is treated in the respect-for-people section of this page.

What Changed Between the Factory and Knowledge Work

Three things moved when the house was translated. Leadership moved from a management concern inside the Toyota system to the explicit foundation of the SAFe house; relentless improvement moved from the floor to a pillar; and the stop-the-line devices, Jidoka and Andon, moved from a pillar of their own into the flow pillar.

Element	Toyota House of Lean (Ohno, 1988)	SAFe House of Lean (Knaster and Leffingwell, 2018)
Roof	Customer value, quality, short lead time	Value: maximum value in the shortest sustainable lead time, highest quality
Pillars	Just-in-Time; Jidoka	Respect for people and culture; flow; innovation; relentless improvement
Stop-the-line	Jidoka and Andon as a pillar	Folded into the flow pillar
Improvement	Kaizen in the foundation with standardised work	Relentless improvement promoted to a pillar
Foundation	Standardised work and kaizen	Leadership
Innovation	Not a structural element	A pillar of its own

The relocation of Jidoka tells the most about the translation. On a factory floor, stopping the line is a discrete, visible act with an unambiguous trigger. In development work, the equivalent act, halting a release because a quality signal fired, has no physical expression and no automatic detection, so it survives in the SAFe house as a flow concern rather than a pillar with its own devices.

The promotion of leadership to the foundation follows from the same asymmetry. A factory’s pull system is enforced by physical constraints that persist whether or not a manager believes in them. A development organisation’s queues, batch sizes and WIP limits exist only as agreements, and any manager can suspend them for one urgent request. The Authentic Pillars of Lean treats the pillar structure in depth.

How Can a Team Use the House of Lean as a Diagnostic Tool?

The house reads top to bottom as a chain of dependencies, which makes it useful for locating where an organisation’s practice diverges from its stated commitment to Lean-Agile. A team that hits its delivery dates but ships defects is failing the roof’s compound test, and the fault sits in the flow pillar where the stop-the-line signal now lives. A team that delivers reliably but produces nothing new is strong on flow and weak on the innovation pillar, the element with no counterpart in Ohno’s original house. A team whose pillars look correct on a slide but collapse under one deadline has a foundation problem, because leadership is what keeps flow, innovation and improvement intact when a manager is tempted to suspend them for an urgent request.

Read this way, the house is less a poster and more a fault-finding order: check the roof’s compound claim first, then the pillar that claim implicates, then whether leadership is protecting that pillar under pressure.

---

Pillars, Values, Principles and Practices: How the Layers of Lean-Agile Fit Together

Four words do the work of one in most writing about this subject: mindset, values and pillars, principles, and practices name four distinct layers, and a reader who separates them can tell which layer a given claim belongs to. The Manifesto already layers itself; Knaster and Leffingwell note that its twelve principles take the four values a step further.

Searchers type “pillars of agile,” “agile pillars and values” and “pillars vs principles” because the vocabulary is loose enough that the same page can use all three for the same thing. Fixing the layers first makes the rest of this page readable, and it explains how a team can run a framework faithfully and still miss the principles it was built to serve.

Mindset, Values, Principles, Practices: The Four Layers

The four layers run from the most general to the most specific: mindset at the top, then values and pillars, then principles, then practices. Each layer constrains the one below it and none determines it.

Mindset is the belief set: the Lean-Agile Mindset defined at the top of this page. Values and pillars are the core commitments that a mindset produces: the Manifesto’s four value statements, the four pillars of the SAFe house. Principles are the rules that guide decisions. The twelve Manifesto principles and the five Lean Thinking steps sit here. Practices are the specific, replaceable ways of applying the rules; Scrum, Kanban, pair programming, a daily standup, a Kanban board.

The Manifesto demonstrates the layering internally. Its four values are comparative preferences, and its twelve principles convert each preference into behaviour, which is what Knaster and Leffingwell mean by the principles taking the values a step further. Two adjacent layers, published in one document, doing different jobs.

The asymmetry between layers is what makes the model useful. A practice can be swapped without touching the principle it serves, and organisations do this routinely. A principle cannot be swapped without touching the value above it, which is why principle changes feel political and practice changes feel operational. Cillion Consulting’s survey of the eight pillars of agile and lean principles draws on twenty-nine sources and finds the same layering problem across them.

Pillars Versus Principles: Structure Versus Rules

A pillar is a structural support in a house model; a principle is a rule that guides a decision. The two words answer different questions, and the confusion between them is mostly an artefact of the house diagrams being the most-shared images in this field.

A pillar names a category of concern that the model refuses to do without. “Flow” as a SAFe pillar does not tell anyone what to do: it asserts that any implementation missing flow has failed structurally. Pillars are therefore completeness checks. Asking whether an organisation has all four pillars is a coverage question with a yes or no answer.

A principle is actionable in a way a pillar is not. “Deliver working software frequently, with a preference to the shorter timescale” resolves a specific decision about release intervals. Principles are therefore decision rules, and asking whether an organisation follows one is a behavioural question answered by examining what it chose when the principle was inconvenient.

The practical test is substitution. If a statement can be checked by inventory, present or absent, it is functioning as a pillar. If it can only be checked by watching a decision, it is functioning as a principle. The I4 Group’s practitioner summary of the lean-agile principles mixes both kinds in one list, which is common and harmless as long as a reader knows which statements are inventory and which are decision rules.

Agile as a Tool or Agile as a Culture

Adopting agile as a tool and adopting it as a culture are distinguishable in research, and the distinction predicts different outcomes. Agile-as-a-tool and agile-as-a-culture: a comprehensive review of agile approaches adopting contingency and configuration theories, in Reviews of Management Sciences (2024), separates the two through contingency theory and configuration theory.

Agile-as-a-tool is adoption at the practice layer: the ceremonies, artefacts and tooling, installed as a delivery method. Agile-as-a-culture is adoption at the mindset and values layers, where the beliefs about people, value and change move as well. The review’s theoretical apparatus explains why the first is easier to observe and the second harder to fake. Contingency theory asks which configuration fits a given organisational context; configuration theory asks which bundles of elements hold together as coherent wholes.

The finding that matters to practitioners is that the two adoptions are not stages of one path. A tool adoption does not mature into a culture adoption by continuing. The practices can run indefinitely as a delivery method while the decision rights, funding cycles and management behaviour stay exactly as they were, and the review’s configurational reading is what makes that stable state predictable rather than surprising.

Easy Agile’s practitioner guidance puts the same caution more bluntly in its treatment of Lean Agile and the five lean principles: agile is not a silver bullet and not a turnkey thing. The warning is about layer confusion; buying at the practice layer and expecting returns that only the upper layers produce.

Why No Single Framework Owns the Principles

The principles sit above every framework, which means a team can run a framework correctly and still break the principles it was built to serve. Scrum, Kanban, Extreme Programming and the scaling frameworks are practices at the bottom layer, each one a way of applying rules that exist independently of it.

The demonstration is easy to construct. A team can complete every Scrum event on schedule, maintain a groomed backlog, and hold a retrospective every sprint, while shipping to a staging environment nobody uses; satisfying the practice and failing principle 7, which makes working software the measure of progress. Another can run a Kanban board with WIP limits that are raised whenever they bind, satisfying the practice and failing the flow principle the limits existed to serve.

Neither failure is detectable by auditing the practice, because the practice was performed. This is why framework compliance and principle adherence need separate assessments, and why maturity models built on ceremony inventories produce confident scores that predict nothing about delivery.

The reverse case is equally instructive. Teams exist that run no named framework and satisfy the principles; short delivery intervals, direct customer contact, bounded work in progress, regular reflection that changes behaviour. They are harder to find and they settle the ownership question: a delivery method is one way of applying a rule set, and the rule set was never issued by the method.

---

Lean Versus Agile: Where the Principle Sets Differ and Where Each Reinforces the Other

The one real difference between the two sets is the unit of optimisation: lean optimises the whole system, while the Agile Manifesto optimises a team delivering working software. Everything else reads as two descriptions of the same behaviour, and Ian Mitchell of Scrum.org demonstrates it principle by principle.

Competitor pages frame this as a choice, and the LSSA paper Choosing between Agile and Lean addresses that framing directly: organisations believe they must choose, and they do not have to. What follows reads the Manifesto through lean, presents the deliberate merge that Mary and Tom Poppendieck published in 2003, and tracks the combined set into IT service management.

Where Lean and Agile Differ: The Unit of Optimisation

Lean’s unit of optimisation is the whole system, and the Manifesto’s is a team delivering working software. That single difference accounts for most of the apparent disagreement between the two traditions.

Lean’s vocabulary is systemic throughout. A value stream runs from concept to customer and crosses every department on the way; “optimize the whole” appears as an explicit lean principle, and Lean Software Development names it as one of seven. The subject of a lean sentence is usually the system, and the improvement target is something no single team controls: a handoff, an approval queue, a funding cycle.

The Manifesto’s subject is a team. Its twelve principles address what a team does: how often it delivers, how it communicates, how it organises itself, how it reflects. The document never describes an enterprise, a portfolio or a value stream, because the seventeen authors were solving a team-level problem that heavyweight methods had created.

Neither unit is wrong. Each one is blind where the other sees. A lean reading can optimise a value stream while the teams inside it work in ways nobody would defend. An agile reading can produce capable teams inside an organisation whose lead time is dominated by queues those teams never touch. This second failure is the more common one now, and it is why the organisation-level section of this page exists.

The reconciliation is structural rather than diplomatic. Apply the Manifesto at the team layer and lean at the system layer, and the two sets stop competing for the same decisions.

Reading the Manifesto Through Lean: Principles 1 and 12

Mitchell’s lean reading of the Manifesto turns two of its principles into lean statements without altering a word, and the demonstration is the strongest available argument that the two sets share a root. His reading appears in the Agile Manifesto from a lean perspective.

Principle 1 asks for early and continuous delivery of valuable software as the highest priority. Mitchell reads it as a waste statement: the longer customers wait for value, the more waste there is in lost time and lost opportunity. The principle is usually read as a statement about customer satisfaction, and the lean reading exposes what it is actually measuring: the cost of delay, before that term entered the vocabulary of the field.

Principle 12 asks the team to reflect at regular intervals and tune its behaviour accordingly. Mitchell reads it as lean discipline: a workflow becomes lean, and stays lean, only if it is continually inspected and adapted. The lean reading supplies the reason the interval has to be regular. Waste accumulates as conditions change, so a workflow that was lean at one point and has not been inspected since is not lean now.

Two observations follow. The Manifesto contains lean claims it does not label, which makes the lean-or-agile question a vocabulary dispute in these cases. And the lean reading is more actionable than the conventional one, because “reduce the waste of waiting” identifies a target while “satisfy the customer” names an aspiration.

The Seven Lean Software Development Principles

Mary Poppendieck and Tom Poppendieck published the deliberate merge in Lean Software Development (2003): seven principles that restate lean for software work. The set is 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 seven are not a translation of the Manifesto and not a copy of Womack and Jones. They are a third statement, written by authors who held both and who were credited alongside Don Reinertsen by Knaster and Leffingwell for reframing lean for product development. Three of the seven touch mechanisms other sections of this page own, and those are named rather than explained here.

Eliminate Waste, Amplify Learning, Decide as Late as Possible

Eliminate waste applies Lean Thinking’s waste categories to software: partially done work, extra features, relearning, handoffs, task switching, delays and defects. The translation from manufacturing is where most of the value sits, because partially done work is the software equivalent of inventory and it is invisible in every system that counts completed tasks.

Amplify learning treats development as a knowledge-generating activity whose output is understanding as much as code, which makes short feedback cycles the mechanism rather than a preference. Decide as late as possible keeps options open until the moment a decision must be made, since information accumulates over time and an early commitment spends it. The parallel design mechanism for that last principle belongs to the economic and systems section below.

Deliver as Fast as Possible and Empower the Team

Deliver as fast as possible is the throughput principle, and its lean justification is the one Mitchell reads out of Manifesto principle 1: speed reduces the waste of waiting and shortens the interval in which a decision can be wrong. Batch size is the lever the principle depends on, and the flow section below treats how cutting it affects cycle time and variability.

Empower the team places decisions with the people doing the work, which is respect for people stated as a delivery mechanism rather than an ethic. The Poppendiecks’ argument is informational: the team holds knowledge about the work that does not survive transmission upward, so a decision made above the team is made with less information. The management obligation underneath that claim is treated in the respect-for-people section.

Build Integrity In and See the Whole

Build integrity in asks for quality designed into the product rather than inspected into it afterwards, which is Jidoka restated for software. Perceived integrity is whether the product does what the customer needs as a coherent whole; conceptual integrity is whether its components work together. Automated testing, continuous integration and refactoring are the practices, and the principle is what they serve.

See the whole is the systemic principle and the one that carries lean’s unit of optimisation into software. It warns against local optimisation: a team, a component or a metric improved at the expense of the system. The SAFe roof’s compound test for value in the shortest sustainable lead time is a version of the same warning, and Two Houses of Lean above treats it.

Lean, Agile and DevOps Inside ITIL4

The combined set has now reached IT service management, which is the clearest evidence that these principles are no longer read as a software development concern. Impact of Integrating Lean, Agile, and DevOps with ITIL4 Framework for Modern IT Service Management, presented at ICETI in 2024, examines the integration directly.

ITIL4 is an unlikely destination. Its predecessors codified service management as process discipline with change advisory boards, formal approval gates and documented procedures: the structure lean and agile principles diagnose as a queue-generating system. That ITIL4 now accommodates lean, agile and DevOps at all indicates movement in the framework rather than in the principles.

The integration matters to practitioners for a specific reason. Most development organisations hand their output to an operations function whose governance derives from ITIL, and a value stream that flows to the point of release and then enters a change advisory queue has not shortened its lead time from concept to customer. The integration research addresses the boundary where lean-agile principles most often stop at the organisational edge.

What the combination cannot resolve is the governance question underneath. Approval gates exist to manage risk, and removing them without replacing the risk control is the failure mode that restores every gate with interest. The principles ask for the control to be redesigned, automated testing, progressive delivery, small batches, rather than deleted.

---

Flow Principles: Queues, Batch Size, WIP Limits and Little’s Law as One System

Queues, batch size, WIP limits and Little’s Law are one system rather than four pieces of advice, and Little’s Law is the equation that links them: work in progress equals throughput multiplied by cycle time. Donald G. Reinertsen supplied the argument in The Principles of Product Development Flow (2009).

Practitioners usually meet these four separately, which is why the flow advice they receive appears to be a list of unrelated interventions. The improvement target underneath all four is delay, and the research crosswalk for this cluster’s lean flow model is explicit that delays and queues are the primary targets rather than individual effort. Each topic below is kept short, because each has an attribute page that owns its depth.

Queues: The Hidden Cost Reinertsen Named

Reinertsen’s central claim is that queues are the largest hidden cost in product development, and they are hidden because queued work is invisible inventory. A factory’s inventory occupies floor space; a development organisation’s inventory sits in a backlog, a review column or someone’s inbox.

The cost of a queue is the delay it imposes on everything behind it, and that cost compounds in ways a utilisation metric cannot show. Work waiting in a queue accrues no value, ages, and becomes more likely to need rework as the world around it changes. A feature specified in January and built in July was built against January’s understanding.

What makes queues durable is that they look like productivity. A long backlog of requests reads as demand for the team’s work; a full review column reads as throughput. Neither reading is available to an observer who measures how long an item waits rather than how many items exist.

Reinertsen’s second observation is that queue length varies far more than capacity does, which locates the intervention. An organisation cannot change its capacity quickly, and it can change the size of its queues almost immediately by changing the rules about admitting work. Managing Queues in Product Development treats the measurement and control of queues in depth.

Batch Size and WIP Limits: Two Levers on One Queue

Batch size and WIP limits are two ways of acting on the same queue. Cutting batch size reduces cycle time, variability and risk at once; setting a WIP limit bounds how much the queue can grow in the first place.

Batch size is the amount of work moved through a step at one time: a release, a specification, a review, a deployment. Small batches move faster, fail more visibly, and produce feedback while the decision that created them is still recoverable. The reason large batches persist is that each handoff has a fixed cost, and when that cost is high, batching it amortises the overhead. This is exactly why automation pays: it lowers the transaction cost and makes small batches economical. Batch Size Optimization treats the trade-off.

A WIP limit is a cap on how many items may be in a given state at once, enforced by refusing to start new work when the cap is reached. Its effect is to convert an invisible queue into a visible refusal, which is uncomfortable and diagnostic. The limit produces the argument the organisation needed to have.

The two levers interact. Small batches with no WIP limit simply queue more items faster; a WIP limit with large batches blocks the system on a single item for a long interval. Optimizing Flow with Work in Progress (WIP) Limits treats the limit-setting mechanics.

Little’s Law: The Equation That Links Them

Little’s Law states that work in progress equals throughput multiplied by cycle time, and rearranging it gives cycle time as WIP divided by throughput. That rearrangement is why both flow levers work, and it is the equation linking every topic in this section.

Read as a cycle time equation, the law says lead time can be shortened two ways: raise throughput or lower WIP. Raising throughput means changing capacity, skill or automation, which is slow and expensive. Lowering WIP means admitting less work concurrently, which is immediate and free. Most organisations attempt the first and describe the second as unrealistic.

The law also explains why adding work to a busy system delays everything rather than just the new item. Additional WIP with unchanged throughput raises cycle time for every item in the system. The urgent request that jumps the queue does not take its own duration from the system; it takes that duration from every item behind it.

Its limits are worth stating. The law holds over a period in a stable system, so it describes averages and not individual items, and a system whose arrival rate or capacity is shifting will not match a single calculation. Little’s Law has its own attribute page for the assumptions and the arithmetic.

Theory of Constraints: Pacing the System to Its Bottleneck

Eliyahu M. Goldratt’s Theory of Constraints (1990) supplies the sequencing rule the flow principles need: identify the system’s one constraint, exploit it, and subordinate every other step to it. A system has a single binding constraint at any time, and improvement anywhere else changes nothing.

The subordination step is the one organisations skip. Exploiting the constraint means protecting it from starvation and interruption, which requires other steps to run below their own capacity; accepting visible idleness at non-constraints to keep the constraint fully fed. Any organisation measuring utilisation per team will reject that instruction on sight.

The theory also predicts that constraints move. Elevating one exposes the next, so the identification step repeats rather than concluding, which is the same non-terminal structure as pursuing perfection in Lean Thinking.

The factory origin of these mechanics fits in one line: one-piece flow came from Taiichi Ohno, and SMED, single-minute exchange of die, came from Shigeo Shingo, whose setup-time reductions made small batches economical in the first place. Shingo’s contribution is the direct ancestor of the argument for deployment automation: cut the transaction cost of a handoff and the economic case for batching disappears.

---

Economic and Systems Principles: Cost of Delay, Variability and Seeing the System

The economic and systems principles supply the reasoning a practitioner falls back on when no practice prescribes an answer: quantify the cost of delay, distinguish variation you caused from variation the system produces, and preserve options until information arrives.

Reinertsen and W. Edwards Deming are the two sources here, and they address different halves of the same problem. Reinertsen supplies the arithmetic for a decision under time pressure; Deming supplies the account of why the numbers a system reports are usually misread. Product Economics, Systems Thinking and Complexity Theory in Practice carry the depth for each strand.

The Economic View: Cost of Delay and WSJF

Reinertsen’s economic view asks that every development decision be weighed by its economic impact, and quantifying the cost of delay is what reveals true urgency. Without that number, urgency is decided by whoever argues most persistently.

Cost of delay is the value lost per unit of time a piece of work is not delivered; revenue forgone, a market window narrowing, a risk left unmitigated, a cost that continues to accrue. Estimating it is uncomfortable because it demands a figure nobody can verify. It is still an improvement on the alternative, which is an ordering produced by seniority.

Weighted Shortest Job First converts the estimate into a sequence: cost of delay divided by job duration, highest score first. The division is where the insight sits. A high-value item that takes a year can be worth less than a modest item delivered next week, and the ratio makes that visible in a way a value-only ranking cannot. Product Economics treats WSJF’s calculation and its failure modes.

Two cautions belong with the arithmetic. The numbers are estimates, so a WSJF ranking is a conversation structure rather than a verdict, and treating its output as precise reintroduces the false confidence the method was meant to remove. And an item whose cost of delay cannot be articulated at all is usually an item nobody has a reason for, which is a finding rather than an obstacle.

Deming on Systems and Variation

Deming’s contribution in The New Economics for Industry, Government, Education (1993) is a theory of knowledge for managers, built on two ideas this page depends on: appreciation for a system, and knowledge of variation.

Appreciation for a system means understanding that results come from interactions among components rather than from the components themselves. A system’s parts can each perform well while the system performs badly, because the interactions, the handoffs, the dependencies, the incentives, are where the behaviour is produced. This is the formal statement of the claim behind see the whole and behind the SAFe roof’s warning against local optimisation.

Knowledge of variation separates common-cause variation, which the system produces as a matter of course, from special-cause variation, which comes from something outside it. The distinction governs the response. Reacting to common-cause variation as though it had a specific cause adds variation rather than removing it, Deming called this tampering, and hunting for the assignable cause of an ordinary fluctuation produces explanations that do not survive.

For anyone reading delivery metrics, the practical consequence is immediate. A velocity drop in one sprint is almost always common-cause variation, and the retrospective that finds a reason for it has manufactured one. The signal worth acting on is a change in the pattern over time, not a movement between two adjacent points.

Preserving Options With Set-Based Concurrent Engineering

Set-based concurrent engineering is the mechanism that makes decide as late as possible operational, and Mary Poppendieck and Tom Poppendieck present it in Implementing Lean Software Development (2006). Rather than selecting one design and refining it, several candidate designs are carried forward together and eliminated as evidence accumulates.

The approach appears wasteful under a point-based assumption, since work goes into designs that will be discarded. Its economics are different from that appearance. Point-based design commits early, discovers the commitment was wrong late, and pays the cost of unwinding it. Set-based design spends more up front and buys the ability to eliminate candidates on evidence rather than on rework.

The judgement involved is about which decisions deserve the treatment. Reversible, low-consequence decisions should be made immediately and revisited if wrong; the parallel-set approach earns its cost only on decisions that are expensive to reverse and currently under-informed. Complexity Theory in Practice treats how the character of a decision determines the approach it warrants.

Lean Startup Approaches: Principles Applied to Business Models

The same principles now operate on business models rather than products, and Agile Business Model Innovation in Digital Entrepreneurship: Lean Startup Approaches in the Journal of Business Research (2020) examines that extension in digital entrepreneurship.

The move is a direct application of amplify learning and decide as late as possible at a higher level. A business model is a set of hypotheses about customers, value and revenue. Building the organisation to serve an unvalidated model is a large batch with a long feedback delay, which is the pattern the flow principles identify as the expensive one.

Lean startup approaches treat the model itself as the object of experimentation, and the parallel to set-based design is exact: carry candidate models, run cheap tests, eliminate on evidence. Business model innovation under this reading becomes an empirical process with the same structure as product development.

The boundary is worth naming, because this extension is frequently over-applied. Experimentation suits conditions of genuine uncertainty about what customers want, and a business operating a validated model in a stable market is not in those conditions. Running experiments where the answer is already known is its own waste.

---

Respect for People: Empowerment, Collaboration and Leadership in Lean-Agile Principles

Respect for people is the pillar that makes the rest operable, and Deming’s formulation is the sharpest available: people are already doing their best, the problem is with the system, and only management can change the system. That statement assigns the improvement obligation upward.

Richard Knaster and Dean Leffingwell quote Deming’s line in their treatment of the lean-agile mindset, and it is the core claim for this whole section. If people are already doing their best, then a performance problem is a system problem, and the lever is not motivation but the conditions the work runs under.

Deming: The Problem Is the System, Not the People

Deming’s claim that the problem is with the system and only management can change it is an empirical position about where variation in performance originates, and it rules out an entire class of intervention.

The argument runs through his knowledge of variation. If most of the variation in output is produced by the system, its tooling, its handoffs, its queues, its policies, then the differences between individual performers are largely noise around a mean the system sets. Ranking people on that noise produces a ranking of luck, and rewarding or punishing on it is tampering.

The second half of the claim is the demanding one. Only management can change the system, because the elements that constrain the work, funding, structure, decision rights, tooling, sit outside the authority of the people executing it. An organisation that asks its teams to improve flow while holding those elements fixed has assigned a task nobody in the room can perform.

This is also the answer to the most common objection to lean-agile principles, which is that they were tried and the teams did not take them up. Under Deming’s reading that outcome is expected, since the teams were asked to change behaviour the system continued to penalise.

Motivated Individuals and Driving Out Fear

Manifesto principle 5 asks that projects be built around motivated individuals, given the environment and support they need, and trusted to get the job done. Deming’s “drive out fear,” from Out of the Crisis (1986), names the precondition that makes the trust real.

Principle 5 is usually read as a hiring statement, which loses most of it. The three clauses are a sequence: find motivated people, then supply environment and support, then withhold interference. Each of the last two is a management obligation, and an organisation that performs the first and skips the others has satisfied the easiest part.

Deming’s point 8 supplies the mechanism that fails first. Fear suppresses information; problems go unreported, estimates get padded, bad news travels slowly and arrives pre-interpreted. Every principle on this page that depends on feedback depends on people reporting what they actually see, so a system where reporting a problem is risky cannot run empirically no matter what its cadence looks like.

Fear is rarely intentional and usually structural. Individual performance ratings on system-produced variation, a blame-seeking post-incident process, or a history of messengers being held responsible each produce it without anyone choosing to. Self-organizing teams are the visible form of the alternative, and they only function where surfacing a problem carries no cost.

Lean Enterprise Institute on Respect for People in Transformation

The Lean Enterprise Institute’s practitioners write about respect for people from decades of transformation work, and voices including Josh Howell, Jim Morgan and Mark Reich are consistent on one finding: the pillar is the part organisations adopt last, if at all. Their collected lean writing documents the pattern.

The reason the LEI writers give is that the tools are transferable and the management behaviour is not. A kanban board, a value stream map or a standup can be installed in a week. Going to see the work, asking rather than telling, and treating a problem as a system signal are practices that replace habits leaders were promoted for having.

Their recurring diagnosis is that tool-first transformations stall around eighteen months to two years. The mechanism is legible: the tools surface problems, the management response to those problems is unchanged, people learn that surfacing problems produces blame, and the tools continue to be operated while the information stops flowing through them. What remains is theatre with correct artefacts.

The prescription from that body of work is to treat the leaders’ own behaviour as the first thing the transformation changes. This is what distinguishes agile-as-a-culture from agile-as-a-tool, and it is why the pillar sits underneath rather than alongside.

Human-First Leadership in 2025 Research

Recent work extends the pillar to a question the original sources never faced: how respect for people applies when some of the work is done by machines. Two 2025 contributions address it from different directions.

V. Rajamani’s 2025 study of agile leadership behaviours during transformation examines what leaders actually do in organisations where the change succeeds, and its findings align with the LEI diagnosis: the behaviours that matter are the everyday ones, visible in how problems are received rather than in how the transformation is announced. The Agile Alliance’s sessions on lean-agile leadership cover the same territory from practitioner experience.

The Agile Business Consortium’s 2025 white paper A Human-First Approach for Integrating Humans and Machines takes the harder case. As work is increasingly divided between people and automated systems, the question of what respect for people means becomes concrete rather than ethical: which decisions stay with people, what a person is accountable for when a machine produced the output, and how empowerment survives when part of the process is opaque to the person operating it.

The principle’s logic does transfer, though it needs restating. Empowerment rested on the claim that the people doing the work hold information that does not survive transmission upward. That claim is unchanged by automation, and it now extends to the people operating automated systems, who are the only ones positioned to see where those systems fail.

---

Applying Lean-Agile Principles Across the Organisation: Value Streams, Team Topologies and Flow Metrics

Applying these principles beyond a single team requires four things the team layer cannot supply: a visible value stream, team boundaries designed for flow, metrics that measure flow rather than activity, and a repeatable improvement method.

This is the section most practitioners need and few sources cover, because the common failure is not a team that cannot work iteratively. It is an organisation full of capable teams whose lead time from concept to customer is dominated by approval queues, handoffs, architectural coupling and funding cycles that no team touches. Value Stream Management is the system view that exposes those constraints, and local agility conceals every one of them.

Make the Value Stream Visible

Making the value stream visible is the first organisational move because a constraint nobody can see cannot be prioritised, and the constraints that dominate enterprise lead time are exactly the ones no single team can observe.

The mapping exercise counts waiting as well as working. A request enters, and the map records every step it passes through with two numbers for each: how long the work took, and how long the item waited before it. The ratio between total elapsed time and total working time is flow efficiency, and the figure it produces is routinely in the single digits, which is the moment the argument about team productivity ends.

What the map surfaces is usually a small number of large delays. An architecture review board that meets fortnightly. A funding cycle that batches decisions annually. A shared platform team with a four-week intake queue. A compliance sign-off held by one person. Each is a queue in Reinertsen’s sense, and each is invisible in every metric collected at team level.

Value Stream Management is the practice of holding that view continuously rather than mapping once. Its value is that it changes what the organisation argues about, from which team is slow to which queue is long, and the second argument has an owner who can act.

Design Teams for Fast Flow With Team Topologies

Team Topologies, in its second edition (2025), supplies the organisational design layer these principles imply: four team types, explicit interaction modes, and cognitive load as the constraint that determines what a team can own.

Its underlying claim is that team boundaries and communication paths determine the architecture and the flow, so a structure inherited from a functional org chart will produce handoffs no amount of team-level practice can remove. The design is therefore upstream of the practices.

Stream-Aligned, Platform, Enabling and Complicated-Subsystem Teams

A stream-aligned team owns a single valuable stream of work end to end and is the default type; every other type exists to reduce the load on it. Platform teams provide self-service internal capability so stream-aligned teams do not queue for infrastructure. Enabling teams work alongside stream-aligned teams for a bounded period to build a missing capability, then leave.

Complicated-subsystem teams own a component whose specialist knowledge cannot reasonably be distributed: a pricing engine, a video codec, a risk model. The type is deliberately rare, and treating it as the norm recreates the component-team structure the model was written against. The specialism must be irreducible; if it is merely currently concentrated, the test fails.

Team APIs, Interaction Modes and Cognitive Load

A team API is the published interface to a team’s work: its code, its documentation, its service levels, how to request something and what to expect. Making it explicit converts an undocumented relationship into something that can be relied on without a conversation, which is what removes the coordination queue.

Three interaction modes are permitted; collaboration for joint discovery, X-as-a-service for consumption without coordination, and facilitation for capability transfer. The discipline is that collaboration is expensive and time-boxed; a permanently collaborating pair of teams should be one team or should have a service boundary. Cognitive load is the governing constraint underneath all of it, since a team asked to hold more domains than it can carry will be slow regardless of its practices.

Measure Flow, Not Activity

The Flow Framework’s five flow metrics, flow velocity, flow time, flow efficiency, flow load and flow distribution, measure the movement of value through a value stream, which is what story points and utilisation do not measure.

Flow velocity counts completed flow items per interval; flow time is the elapsed time from accepted to done, waiting included. Flow efficiency is working time over elapsed time, and it is the single most informative number an organisation can collect, because it separates a capacity problem from a queueing problem in one figure. Flow load is work in progress, the quantity Little’s Law makes actionable. Flow distribution is the mix of features, defects, risks and debt, which is how an organisation discovers it has been funding one category exclusively.

The reason the substitution matters is that activity metrics can improve while outcomes worsen. Utilisation rises as queues lengthen; story point throughput rises as batch sizes shrink without any change in delivered value. Both movements read as improvement in an activity frame and as nothing in a flow frame.

Flow distribution also settles the technical debt conversation with data rather than advocacy. An organisation that can see the ratio of feature work to debt work over four quarters is no longer relying on an engineering argument about the need to invest, because the trend is on the chart.

Improve Through Kaizen, A3 and Five Whys

Kaizen, A3 problem solving and Five Whys are the improvement methods the pursuit of perfection needs to become routine, and their shared property is that they are small, structured and performed by the people doing the work.

Kaizen means continuous incremental improvement driven from within the work rather than imposed on it. Its economics match the batch size argument exactly: many small changes, each cheaply reversible, accumulate faster than periodic large initiatives and carry less risk per step. Relentless improvement in the SAFe House of Lean is the same commitment given a different name.

A3 problem solving structures a problem onto a single sheet; background, current condition, goal, root cause analysis, countermeasures, plan, follow-up. The constraint of one page is the method’s contribution, since it forces the problem to be stated precisely enough to fit and makes the reasoning inspectable by someone who was not involved.

Five Whys pursues a causal chain past the first plausible stopping point. Its known failure is producing a single tidy chain for a problem with several interacting causes, and the correction is to permit the tree to branch. The discipline that matters in practice is where the chain is allowed to terminate: a why-chain that ends at a person has stopped early, and Deming’s claim is that the next why leads to the system.

Sustaining any of this depends on structure rather than enthusiasm. The product operating model is what holds improvement in place; persistent teams that outlive projects, funding allocated to those teams rather than to initiatives, and decision rights held where the information is. Without those three, improvement practices survive until the next reorganisation.

Lean-Agile Change in the Public Sector

Public sector organisations face constraints the commercial literature rarely models, and Agile Transformation in Public Sector IT Projects Using Lean-Agile Change Management and Enterprise Architecture Alignment in IJSRMT (2024) examines those constraints directly.

Three of them are structural rather than cultural. Regulatory requirements impose approval sequences that cannot be removed by a decision inside the organisation. Legacy systems carry coupling that constrains how work can be batched at all. And stakeholder accountability is to the public through political structures, which makes the tolerance for visible failure markedly lower than the experiment-driven approaches assume.

The paper’s pairing of lean-agile change management with enterprise architecture alignment responds to the second constraint in particular. Where the architecture makes small batches technically impossible, no amount of process change produces flow, so the architectural work has to proceed alongside rather than after.

The generalisation beyond government is worth drawing, because regulated industries, finance, healthcare, utilities, defence, meet the same three constraints. The principles still apply in full; what changes is that redesigning a control is the only available move, since removing it is not one.

---

Scaling or Growing? SAFe’s Ten Lean-Agile Principles and the 2026 Manifesto for Enterprise Agility

SAFe states ten immutable, underlying Lean-Agile principles synthesised from Agile methods, Lean thinking, systems thinking and product development flow; which makes it the most direct example of how the general principle set gets derived into a framework-specific one.

Scaled Agile opens its treatment with a line from Deming: the impression that “our problems are different” is a common disease, because the principles that improve quality are universal. That framing tells you what kind of claim the ten are making, and it is also the claim a 2025 organisation design paper and a 2026 manifesto have each pushed back on from different angles.

How SAFe Derives Ten Lean-Agile Principles From This Set

The derivation is traceable source by source, which is the useful thing to see, and the SAFe Lean-Agile Principles states the synthesis explicitly. Three of the ten show the pattern clearly.

Principle #1, take an economic view, comes from Reinertsen: the economic view, cost of delay, and the sequencing arithmetic treated in the economic section above. Principle #2, apply systems thinking, comes from Deming: appreciation for a system, and the warning against optimising a part at the expense of the whole. Principle #10, organize around value, comes from Womack and Jones and from the Manifesto’s team orientation: the value stream as the unit of organisation rather than the function.

Two properties of the derivation are worth noting. The sources are the ones this page has been treating throughout, so the ten are a restatement for a specific context rather than a new claim. And “immutable” applies to the principles and not to the practices built on them, which is the distinction the layers section established: SAFe’s practices have changed substantially across versions while the underlying principles have not.

The full ten, with the reasoning for each, belong to the SAFe Lean-Agile Principles pages. What matters here is that the general set is upstream of them, and a practitioner who holds the general set can evaluate any framework’s derivation rather than adopting it.

Scaling Versus Growing Agile: The 2025 Organization Design Argument

Constantin Bremer, Anna Rylander Eklund and Maria Elmquist argue in Scaling or growing agile? Proposing a manifesto for agile organization development, published in the Journal of Organization Design in 2025, that organisations should grow agile within themselves rather than scale team practices outward.

The distinction is substantive. Scaling treats team-level agile as a validated unit to be replicated across an enterprise, which presumes the team practices are the thing that produces the outcome. Growing treats the organisation as the object of development, so the question becomes what this organisation’s structure, funding and decision rights need to become; and the answer will not look like a team practice enlarged.

Their critique lands on a real pattern. Scaling programmes frequently install ceremonies, roles and cadences across hundreds of teams while the funding cycle, the approval structure and the reporting lines remain as they were, and the result is the tool-first stall the Lean Enterprise Institute writers describe at a larger scale.

Read against the ten, the paper is not a rejection of frameworks so much as an argument about the direction of causality. Agile organization development treats the organisation’s own development as the work; a framework rollout treats the framework as the work. The first is harder to sell and harder to schedule.

The 2026 Manifesto for Enterprise Agility

Jim Highsmith and Jon Kern, both original Manifesto signatories, have co-created the 2026 Manifesto for Enterprise Agility with the Agile Alliance; which is the clearest signal available that the 2001 authors consider the original document to have been scoped to a problem the field has outgrown.

The move is consistent with everything above. The 2001 Manifesto’s unit was a team delivering working software, and the problem that has dominated the twenty-five years since is enterprise lead time; queues, funding cycles, architecture and governance. A document written for the first problem was never going to answer the second, and the signatories saying so carries more weight than any external critique.

For a practitioner the practical reading is that the twelve principles remain correct within their scope and incomplete outside it. Nothing in the 2001 set is retracted by a 2026 enterprise document; what is added is the layer the original never addressed, which is the layer the organisational section of this page treats.

---

How to Start Applying Lean and Agile Principles

Start by measuring one number: the flow efficiency of a single value stream, working time over total elapsed time, for the last ten items that went all the way through. It takes an afternoon with a spreadsheet and no permission from anyone.

That number is the right first move because it determines which of everything above applies to you. If flow efficiency comes back at 40% or higher, the constraint really is capacity or capability, and the team-level practices are the relevant lever. If it comes back at 5%, which is the more common result, then 95% of your lead time is queueing, and no improvement in how the team works will move it. The measurement tells you which conversation to have, and it is the only cheap way to find out.

Two boundary cases deserve naming before you act on the result. A value stream with fewer than about ten completed items has no usable flow data; variation will swamp the signal, and Deming’s warning about reacting to common-cause variation applies with full force. And a team whose queueing sits entirely inside a single dependency, one platform team, one sign-off, one shared environment, does not have a value stream problem to map. It has one queue to negotiate, and a map will tell you what you already know.

The failure mode to avoid is the one this page has now described from three directions: installing the practices and leaving the system intact. Boards, cadences and ceremonies surface problems; if the response to a surfaced problem is unchanged, people stop surfacing them and the artefacts continue to be maintained. The Lean Enterprise Institute writers date this stall at eighteen months to two years, and its distinguishing feature is that everything looks correct.

The decision you now face is narrower than a framework choice. It is whether the constraint you can see is inside a team’s control or outside it, because that answer determines who has to act and what they have to change. If it is inside, the Manifesto’s twelve principles are your set. If it is outside, the work is the system, the funding cycle, the approval queue, the architecture, the decision rights, and only management can change that. Everything else on this page is reasoning you will need once you know which one you are in.