4 PROJECT MANAGEMENT: lean/agile

Lean (definition)

A philosophy originating from the Toyota Production System, focused on maximising customer value while minimising waste across an entire process/value stream. It is not a project management method with defined phases or roles — it's a set of principles for organising any production process efficiently, later adapted to software (Kanban, Lean Software Development).

Agile (definition)

A family of iterative, adaptive approaches to software delivery, built as a reaction against Waterfall's rigid, upfront planning. Agile structures work inside a team into short, iterative cycles to produce functional results and respond quickly to changing requirements.

Core difference: Lean vs Agile

Lean prioritises optimising processes and eliminating waste to build efficiency across the WHOLE value stream (end to end). Agile prioritises flexibility, rapid collaboration and adaptive delivery to meet CHANGING requirements. Lean asks "how do we work efficiently?"; Agile asks "how do we adapt fast?" They overlap heavily in practice but are not the same question.

Are Lean and Agile competitors?

No — they're better pictured as two overlapping circles, not rivals or a hierarchy. Scrum sits mostly in Agile-only territory (it didn't originate from Lean). Kanban sits in the overlap: it's Lean's flow/waste thinking applied directly to software, but because it's iterative and responsive to change it also satisfies Agile Manifesto values. Waterfall sits outside both circles entirely.

The Three Ms (Muda, Mura, Muri)

A diagnostic lens or classification scheme within Lean:

• Muda (Waste): activity that consumes resources but adds no customer value (e.g. overproduction, waiting, defects).

• Mura (Unevenness): inconsistency/fluctuation in workflow or demand (e.g. too much work one day, idle the next).

• Muri (Overburden): pushing people/systems beyond safe/reasonable limits — often a result of trying to catch up after Mura.

Muda Type I vs Type II

1. Type I muda: waste that is currently unavoidable given constraints (e.g. mandatory reporting, compliance checks) — reduce over time but can't eliminate immediately.

2. Type II muda: pure waste with no value to anyone — eliminate immediately (e.g. unnecessary handoffs, over-engineering, partially-done work sitting idle).

Lean House Structure

A structural model of how the lean concepts rely on each other

1. The Goal: high quality, low cost, short lead time, safety and morale

2. 2 Pilars: JIT and Jidoka

3. Centre: Kaizen and Respect for People

4. Foundation: Heijunka (Level Production), Standard Work (docment current most efficient way to perform task) and 5S Methodology

Lean House — the Roof

Represents the ultimate goal: customer value, delivered via

Highest Quality (defect-free), Lowest Cost (waste eliminated), Shortest Lead Time, and Safety & Morale (engaged workforce).

Lean House — the Pillars

• Just-In-Time (JIT): make only what's needed, when needed, in the amount needed (includes Takt Time and Continuous Flow).

• Jidoka (built-in quality): make problems visible and stop the process instantly when an abnormality occurs, so defects never pass downstream.

Lean House — the Centre

• Kaizen (Continuous Improvement): a relentless effort to evolve everyday processes.

• Respect for People: engaging employees, avoiding overburdening staff (linking back to Muri), and building trust.

Lean House — the Foundation

• Heijunka (Level Production): levelling out volume/variety of work to avoid spikes and dry spells (addresses Mura).

• Standard Work: documenting the current most efficient way to do a task.

• 5S: workplace organisation (Sort, Set in order, Shine, Standardize, Sustain).

Womack & Jones' 5 Lean Principles

Steps to apply lean

1. Define Value — from the customer's perspective only.

2. Map the Value Stream — The value stream includes the entire lifecycle of a product or service, spanning raw materials, production, and delivery. sort every step into value-adding, non-value-adding-but-necessary, or waste.

3. Create Flow — arrange value-adding steps to run smoothly, avoiding batch-and-queue.

4. Establish Pull — nothing is made until the downstream customer requests it (JIT).

5. Pursue Perfection — a continuous culture, not a one-off project.

7 Lean Principles (software / knowledge-work version)

Specific way to apply lean for software dev.

1. Eliminate Waste (remove anything not adding direct customer value — over-engineering, handoffs, partially-done work);

2. Build Quality In (test/check at every stage, e.g. TDD, not just at the end);

3. Create Knowledge (retrospectives, code reviews, documentation);

4. Defer Commitment (delay irreversible decisions to the last responsible moment);

5. Deliver Fast (shorten the feedback loop);

6. Respect People (trust the team to design/estimate their own work);

7. Optimize the Whole (look at the end-to-end value stream, not just one department).

Don't confuse: Womack & Jones' 5 principles vs the 7 Lean software principles

These are two different lists covering similar ground at different levels:

• Womack & Jones (1996) describe general Lean manufacturing thinking (Value, Value Stream, Flow, Pull, Perfection).

• The 7 Lean principles are the software-specific adaptation (Poppendieck) — e.g. "Create Knowledge" and "Defer Commitment" don't appear in the original 5. Know both exist and roughly what each contains, but don't merge them into one list.

Agile Manifesto — the 4 values

1. Individuals and interactions OVER processes and tools.

2. Working software OVER comprehensive documentation.

3. Customer collaboration OVER contract negotiation.

4. Responding to change OVER following a plan

Note: these are stated preferences ("we value X more than Y"), not "Y doesn't matter at all".

Waterfall Limits and Opportunities

LIMITS

• Inflexibility (scope changes are hard/costly once planning is done);

• Late-stage testing (errors surface near the end, expensive to fix);

• Low customer involvement (client only sees the final product);

• Unrealistic upfront requirements (assumes you can specify everything at the start, when knowledge is at its lowest).

OPPS

• requirements are stable

• compliance/documentation is important

• changes are expensive

• project is predictable

• safety/regulation requires formal sign-off

MVP (Minimum Viable Product)

The simplest version of a product that still solves a core problem for users and lets the team gather real feedback. Key characteristics: solves a real problem (Core Value), includes only essential functions (Minimal Features), is built with a way to collect user reactions (Feedback Loop), and prioritises validated learning over a "finished" launch.

LEAN

• minimal features reduce waste

• Building something small and testing it before committing further is exactly Lean's instinct to avoid large, unvalidated batches of work.

AGILE

• feedback loop anfd validated learning- responding to change over following a plan

• shipping something small and fast to get real feedback is Agile's deliver fast, shortening the loop between building and learning whether it was right

Why use an MVP?

Reduces risk (test demand before spending a full budget), saves time (avoid building unneeded features), and guides iteration (real feedback dictates what gets built next) — it operationalises Agile's "deliver fast" and Lean's "eliminate waste" at the same time.

Scrum (definition)

A lightweight Agile framework for managing complex work through short, repeating, fixed-length cycles called Sprints (typically 1–4 weeks), at the end of which the team should have a working increment to review.

Scrum roles

• Product Owner: manages the backlog, sets priorities, represents the customer's voice.

• Scrum Master: servant-leader who coaches the team and removes blockers.

• Developers/Team: self-organising group that builds the actual increments.

Scrum events (ceremonies)

• Sprint Planning (set the goal, choose tasks for the sprint);

• Daily Scrum (quick daily check-in, ~15 min);

• Sprint Review (demo completed work to stakeholders for feedback);

• Sprint Retrospective (internal reflection on how to improve the process).

Scrum artifacts

• Product Backlog: master list of all desired work/features.

• Sprint Backlog: the subset chosen for the current sprint.

• Increment: the usable, working piece of product completed by the end of the sprint.

Burndown chart

Tracking tool for scrum. Tracks remaining work versus time left in an iteration. X-axis = timeline (working days); Y-axis = remaining effort (story points/hours/tasks). An Ideal Baseline line runs diagonally from total work to zero at the deadline; an Actual Progress line fluctuates daily, showing whether the team is ahead, on track, or falling behind.

Exam phrase A burndown chart is useful for monitoring progress, but it should not be used alone because it does not show quality, value delivered or technical debt.

Burndown chart PROS AND CONS

Pros

• simple visual progress tracker • helps identify delays • supports sprint monitoring • encourages transparency

Cons

• does not show quality

• can hide technical debt

• depends on accurate estimates

• does not explain why progress changed

• can be gamed

Sprint burndown vs Product/Release burndown

Sprint Burndown: tracks daily task completion within ONE sprint — used by the dev team in daily standups to self-organise. Product/Release Burndown: tracks progress across MULTIPLE sprints on larger features/epics — used by product owners/PMs to gauge overall release dates.

Burndown chart vs Burnup chart

Burndown: starts at maximum work, tracks what's LEFT to do, drops to zero. Burnup: starts at zero, tracks COMPLETED work against total scope, climbs upward — better at distinguishing "we're behind schedule" from "the scope grew," since a rising total-scope line is visible separately from the completed-work line (a burndown can't show this distinction).

Kanban (definition)

A visual workflow management method that tracks and controls tasks via a board (e.g. To Do / In Progress / Done), with strict Work-in-Progress (WIP) limits enforcing a pull system. Originated with Taiichi Ohno at Toyota (1940s) as a JIT manufacturing system; unlike Scrum, it layers onto your EXISTING process rather than prescribing fixed roles/ceremonies, encouraging gradual continuous improvement.

How does Kanban operate?

• Basic board: Backlog → Ready → In Progress → Review/Test → Done

• Pull :Work is pulled when there is capacity. A team member pulls the next highest-priority task when ready.

• WIP limits: WIP = Work in Progress. A WIP limit restricts how many tasks can be in a column at once.

Why WIP limits help

• reduce overload/Muri

• expose bottlenecks

• improve flow

• reduce multitasking

• encourage finishing before starting

Core difference: Scrum vs Kanban

Scrum operates in structured, time-boxed iterations (Sprints, usually 1–4 weeks) with defined roles and ceremonies. Kanban relies on continuous, fluid flow with strict WIP limits and no fixed-length cycles — work ships the moment it's done rather than waiting for a sprint boundary.

Other Agile Variants

• XP: Engineering practices like pair programming/CI . Improve software quality

• TDD: Write tests before code . Reduce defects and improve design

• Scrumban: Mix Scrum cadence with Kanban flow . Useful when teams need both planning and flexibility

Challenges of scaling AGILE

• coordinating many teams

• dependencies

• architecture consistency

• communication overhead

• governance alignment

• maintaining feedback loops

• avoiding fake Agile bureaucracy