“Agile vs Lean vs Kanban”

What is the difference between agile, lean and kanban?

agile vs lean vs kanban is a key topic in modern project management and teamwork. Agile is a philosophy for delivering under uncertainty, lean is a method for eliminating waste and improving flow, and kanban is a system for visualising work and limiting work in progress so flow can be managed.

The confusion starts because all three are called methodologies in vendor material. They are not peers. Agile tells you what to value. Lean tells you what to remove. Kanban tells you how to regulate the amount of work moving through a process. You can be agile without kanban, kanban without agile, lean without either, and many teams are.

The table is the whole argument in one view. Everything else in this article is the detail behind those rows, plus the arithmetic that makes the distinctions practical.

Is agile a methodology or a mindset?

Agile is a mindset: the 2001 Agile Manifesto states four values and twelve principles, and deliberately stops short of prescribing roles, artefacts or ceremonies.

The four values prioritise individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The phrasing matters. It does not say documentation is worthless or plans are forbidden; it says the left side should be valued more when the two conflict.

That is why “agile” can describe a two-person startup with no sprints and also a regulated bank with quarterly release gates. The principles are about feedback frequency, technical excellence, self-organising teams and simplicity, not about standing meetings at 9:30.

Most of what people call agile in practice is a framework that implements the mindset: Scrum with its roles, events and artefacts, or Extreme Programming with its engineering practices. Confusing the framework with the mindset is the root of cargo-cult agile, where a team performs the ceremonies and still batches work for a quarterly release.

What does lean actually optimize?

Lean optimises the ratio of value to waste across the whole value stream, which is why it rejects local efficiency gains that make the system slower overall.

The Toyota lineage gives lean its vocabulary. Muda is waste, and Ohno’s seven categories are overproduction, waiting, transport, over-processing, inventory, motion and defects. Two related burdens matter just as much: mura, unevenness in workload, and muri, overburdening people or equipment. A team that alternates between idle weeks and 60-hour weeks has a mura problem, and adding more people to the crunch is a muri solution that makes the next cycle worse.

Womack and Jones condensed lean into five principles: specify value from the customer’s perspective, map the value stream, create flow, let the customer pull, and pursue perfection. The Poppendiecks translated this for software into seven principles, including eliminate waste, build quality in, defer commitment, deliver fast, respect people and optimise the whole.

“Optimise the whole” is the principle most often ignored. A test team that automates 90% of regression but waits four days for an environment has improved a step, not the stream. Lean asks where the four days go, not how to make the automated suite faster.

Is kanban agile or lean?

Kanban is neither by definition, but it descends from lean manufacturing and is fully compatible with agile delivery, which is why it is usually described as a lean-agile method.

The software kanban method, as popularised by David J. Anderson, is built on a small set of practices: visualise the workflow, limit work in progress, manage flow, make process policies explicit, implement feedback loops, and improve collaboratively. Its principles include starting with what you do now, agreeing to pursue change incrementally, respecting current roles and responsibilities, and encouraging acts of leadership.

Note what is absent: no prescribed roles, no sprints, no estimation requirement, no definition of “done” imposed from outside. Kanban is deliberately evolutionary. You draw the columns your work actually passes through, including the waiting states that Scrum boards usually hide, then you limit how many items can sit in each state.

That makes kanban a good fit for work that arrives unpredictably: support queues, operations, design requests, security triage. It is a weaker fit for work that benefits from a hard commitment boundary and a batch of planning, such as a product increment that needs coordinated release notes, marketing and training.

How does Little’s Law explain why WIP limits work?

Little’s Law states that average work in progress equals throughput multiplied by average cycle time, so for a fixed throughput, cutting WIP in half halves the time an item spends in the system.

The practical form is cycle time = WIP ÷ throughput. A team with 24 items in progress and a throughput of 6 items per week has an average cycle time of 4 weeks. If the team limits WIP to 12 and throughput holds at 6, cycle time falls to 2 weeks. No one worked faster. The team simply stopped starting work it could not finish.

This is the counter-intuitive part that makes kanban hard to adopt. Limiting WIP looks like reducing capacity. In reality it reduces queueing, context switching and the hidden inventory of half-finished work. A developer carrying four tasks does not deliver four times as much; they deliver later, with more defects, because each task waits while the others are touched.

The same law explains why a board without WIP limits is not kanban. Cards move, the team feels visual, and cycle time stays flat because nothing constrains the arrival of new work.

Can you combine agile, lean and kanban?

Yes, and most mature organisations do: kanban inside a Scrum cadence is Scrumban, lean thinking applied to agile portfolio flow is lean-agile, and kanban used to manage an existing process incrementally is the kanban method’s default mode.

The sequencing matters more than the label. Start by visualising the real workflow, including waiting columns. Add WIP limits where queues form. Then decide whether you need an iteration boundary for planning and commitment. Lean thinking runs through all of it as the question you keep asking: does this step create value for the customer, and if not, why does it exist?

Which one should your team choose?

Choose agile when the main problem is uncertainty about what to build, lean when the main problem is waste inside a known process, and kanban when the main problem is unpredictable arrival and too much work in progress.

Three diagnostic questions usually settle it. First, can you describe the next three months of work with reasonable confidence? If yes, lean and kanban are strong candidates; if no, an agile cadence with short feedback loops helps you learn. Second, where does work wait? If the answer is “in our queue, not in our heads”, kanban will expose it fastest. Third, what is the cost of a bad batch? If releasing 40 changes at once is catastrophic, reduce batch size and improve flow before adding ceremonies.

A useful rule for mixed cases: use agile for discovery, kanban for delivery. Product discovery benefits from time-boxed learning loops. Delivery benefits from flow, WIP limits and cycle-time measurement. Many teams run both without calling it a hybrid.

What does each approach measure?

Each approach measures something different, and using one approach’s metric to judge another produces misleading conclusions.

Flow efficiency deserves a note because it is the metric most teams never calculate. It is active time divided by lead time. If a task spends 3 days being worked on and 12 days waiting, flow efficiency is 3 ÷ 12 = 25%. The remaining 75% is queue time, and that is where lean’s waste categories live.

What are the most common mistakes?

The most common mistakes are treating a framework as a strategy, adopting kanban without limits, and using lean as a cover for headcount reduction.

The first mistake is buying a certification and expecting behaviour to change. Agile values are cheap to recite and expensive to practise, particularly “responding to change” when a contract specifies scope.

The second is a kanban board with no WIP limits and no explicit policies. Columns appear, cards move, and nothing about the system changes. If your board cannot tell a newcomer what “ready” and “done” mean at each column, it is a status display, not a flow system.

The third is the most damaging. Lean is about removing waste, and headcount is not waste; waiting, rework and overproduction are. A lean programme that starts with layoffs teaches everyone to hide improvement opportunities, which destroys the data the method depends on.

A fourth mistake is measuring utilisation instead of flow. A team at 95% utilisation has no slack to absorb variation, so queues grow and lead time rises. Lean manufacturing learned this decades ago; knowledge work keeps relearning it.

What does this look like for one team over one quarter?

Take a five-person product team with a backlog of 120 items, an average of 30 items in progress across all stages, and a delivery rate of 10 items per week.

Under an agile-only cadence, the team plans 20 items per two-week sprint and completes 17 on average. Predictability is 85%, which is decent, but cycle time is 30 ÷ 10 = 3 weeks and stakeholders complain that small requests take a month.

The team maps the workflow and finds that 14 of the 30 in-progress items are sitting in review or waiting for a staging environment. It adds WIP limits of 6 in development, 4 in review and 3 in test, and creates a explicit policy that review starts within one working day.

After six weeks, WIP averages 18 and throughput holds at 10 per week, so cycle time becomes 18 ÷ 10 = 1.8 weeks. The sprint cadence stays, the planning event stays, and the only new discipline is the limit. That is Scrumban in practice: agile for commitment, kanban for flow, lean for the decision to attack the review queue rather than ask people to work faster.

When does combining them go wrong?

Combinations fail when teams adopt the rituals of one approach and the metrics of another without changing either the workflow or the policies.

The classic symptom is a Scrum team with a kanban board where the WIP limit is routinely exceeded “because the sprint committed us”. At that point the limit is decoration. Either the sprint scope was wrong or the limit was set below capacity, and the team needs to fix the cause rather than ignore the signal.

A second failure is lean-agile theatre: value-stream maps produced once for a transformation deck, flow metrics reported monthly, and no change to the approval steps that create the waiting. Mapping without authority to remove a step is documentation, not lean.

The third is tooling that forces one model. A board that only supports sprints cannot show a continuous support queue; a board that only supports flow cannot express a sprint commitment. If your work has both, you need a tool that can hold both without duplicating the backlog.

Where does tooling fit?

Tooling should make the chosen system visible, and the minimum requirement is a board that shows real workflow states, a way to limit work, and metrics that do not require a spreadsheet rebuild every week.

Doitify supports kanban boards, sprints and backlogs, multi-level tasks with dependencies, workload views and progress reporting, which lets a team run an agile cadence while keeping flow visible. Cycle time and WIP can be tracked from task status history, and the board configuration can include review and waiting columns rather than only “to do, doing, done”. Doitify is our product, so treat this as a disclosure: no tool enforces a WIP limit for you, and a team that has not agreed its policies will reproduce the same queues inside a nicer interface.

The practical test for any tool is whether a newcomer can read the board and answer three questions: what is in progress, what is waiting, and what is the oldest item. If the board cannot answer those, the method behind it is not yet real.

Conclusion

Agile, lean and kanban answer three different questions. Agile asks how to deliver value when requirements are uncertain. Lean asks where value is created and where it is wasted. Kanban asks how much work is in progress and how fast it flows.

Treat them as layers rather than alternatives. Start with the workflow you actually have, make it visible, limit the work, and measure cycle time. Then decide whether you need an iteration boundary for commitment, and keep asking the lean question about which steps earn their place. The team that does this does not need to choose a label; it needs a board, a limit and a habit of removing one obstacle at a time.

If this post on agile vs lean vs kanban was helpful, you might also enjoy Free Change Request Template and How to Automate Project Reminders (Step-by-Step).