Lean and Kanban

UNIT-IV

[Link] ,
Assistant Professor
Department of Information Technology
Kongu Engineering College
Content
• Lean Thinking • The Principles of Kanban
• Commitment, Options Thinking and Set
• Improving Your
Based Development

• Create Heroes and Magical Thinking • Process with Kanban

• Eliminate Waste • Measure and Manage Flow
• Value Stream Map
• Little’s Law
• Deliver As Fast As Possible
• Emergent Behavior with Kanban
• WIP Area Chart

• Pull Systems
[Link], AP/IT, KEC 2
Lean, Eliminating Waste, and Seeing the Whole
• Scrum and XP are agile methods with specific practices teams follow.

• These practices only work well when teams also embrace their values and
principles.

• Without the right mind set, teams may just follow steps without real
improvement.

• Lean is different -it’s a mind set, not a list of practices.

• Lean Thinking, adapted from manufacturing by the Poppendiecks, helps teams

reduce waste and see the whole system.
[Link], AP/IT, KEC 3
Lean Thinking
• Lean is a mindset, just like Scrum and XP, and it starts with core values.

• Scrum and XP have values that support their mindsets (like courage, respect, feedback).

• Lean values guide teams to build better software by focusing on:

• Eliminate waste

Find the work that you’re doing that doesn’t directly help to create valuable software and remove it from the
project.

• Amplify learning

Use feedback from your project to improve how you build software.

• Decide as late as possible

Make every important decision for your project when you have the most information about it—at the last
responsible moment. [Link], AP/IT, KEC 4
Lean Thinking
• Deliver as fast as possible

Understand the cost of delay, and minimize it using pull systems and queues.

• Empower the team

Establish a focused and effective work environment, and build a whole team of energized people.

• Build integrity in

Build software that intuitively makes sense to the users, and which forms a coherent whole.

• See the whole

Understand the work that happens on your project—and take the right kind of measurements to make sure
you’re actually seeing everything clearly, warts and all.

• These values come with thinking tools, which help teams apply the mindset in real-world situations.
[Link], AP/IT, KEC 5
• Thinking tools in Lean are similar in role to XP principles — they guide behavior, not just actions.
You Already Understand Many of These Values
• Lean is deeply connected to Agile — many Lean values and thinking tools
overlap with ideas from Scrum and XP.

• The Agile Manifesto shifted focus from rigid processes to people,

collaboration, and working software, aligning with Lean principles.

• Lean values like "decide as late as possible" are already used in Scrum and XP
— this principle helps teams make better decisions with more information.

[Link], AP/IT, KEC 6

• "Amplify learning" is another Lean value you’ve already seen through
feedback and iterations — both core parts of Scrum and XP.

• This value also includes synchronization and set-based development —

similar to XP's continuous integration and shared code ownership.

• "Empower the team" echoes ideas from XP (energized work, whole team) and
Scrum (focus), emphasizing motivation, self-direction, and team leadership.

• Lean’s thinking tools support these values in practice, and many are identical
or similar to tools already used in other Agile methods.
[Link], AP/IT, KEC 7
[Link], AP/IT, KEC 8
Commitment, Options Thinking, and Set-Based
Development
• Commitments come from people, not plans — plans just document the
promises people make. Real commitment happens first, then gets written
down.

• Lean and XP deepen the idea of commitment using tools like options
thinking (keeping flexible choices) and set-based development (exploring
multiple solutions in parallel).

[Link], AP/IT, KEC 9

 Scrum teams commit to delivering value, but give
themselves options for how to do it
• Commitments come from people, not plans — Scrum teams commit to

delivering value, not to rigid schedules or detailed task plans.

• Scrum separates commitments from options — teams commit to sprint goals,

but backlog items and tasks remain flexible until the last responsible moment.

• Detailed long-term task planning creates a false sense of control, but often leads

to failure because those commitments are made without enough information.

[Link], AP/IT, KEC 10
• Options thinking (a Lean concept) encourages adaptability — tasks are seen as

options that can be adjusted based on what the team learns during the sprint.

• Overcommitting is common — sometimes due to pressure, heroics, or a

blame-heavy culture that rewards making promises over delivering

realistically.

• Scrum’s flexible task management (e.g., daily changes to the task board)

supports adaptability and keeps the team focused on delivering value, not just

ticking boxes.
[Link], AP/IT, KEC 11
• Scrum teams use options thinking by treating tasks as flexible, not fixed
commitments — they can adjust tasks mid-sprint based on new information.

• Traditional (waterfall) teams struggle with change, often clinging to outdated

plans or designs, which leads to resistance and conflict when new, better options
arise.

• The real problem is committing too early — treating early assumptions as

commitments leads to technical compromises and frustration.

• XP supports options thinking through incremental design — building small,

decoupled components using refactoring and TDD helps teams stay flexible.
[Link], AP/IT, KEC 12
• Set-based development is an explicit way to keep options open — teams
explore multiple solutions at once to gather information before choosing
the best path.

• This extra effort often saves time long-term, avoiding technical debt and
poor decisions made too early with too little information.

• A/B testing is a real-world example of set-based development — building

multiple versions, measuring results, and choosing based on data.

[Link], AP/IT, KEC 13

 Act I: Just One More Thing...
• Catherine’s team is under pressure from their boss, Dan, who expects more work without giving more time
or support, creating a toxic environment.

• The team used to be innovative and motivated at a small company, but after acquisition by a large
corporation, morale and productivity dropped.

• Dan frequently adds last-minute “great news” features mid-sprint, ignoring the team's workload and
pushing for unrealistic timelines.

• Timothy and Catherine express burnout, but Dan dismisses their concerns and pressures them to work
harder, even blaming them for delays.

• The team sacrifices quality (e.g. skipping tests), leading to user dissatisfaction and technical debt — a cycle
that keeps repeating.
[Link], AP/IT, KEC 14
Creating Heroes and Magical Thinking
• "Rugged individualism" in management relies on setting aggressive goals and rewarding solo
heroics, believing this motivates individuals and eliminates bureaucracy.

• Hero developers who work overtime and solve problems alone are celebrated, even if they don’t
contribute to teamwork or long-term quality.

• This mindset is counterproductive — real-world Agile teams (in Scrum and XP) succeed through
collaboration, relaxed conditions, and collective responsibility.

• Managers often fall into this trap because it looks efficient: solo high-performers seem productive
and easy to manage, reinforcing short-term pressure tactics.

• This creates a chaotic, unenergized environment, where quality suffers and long-term software
design is compromised — what the passage calls "magical thinking."
[Link], AP/IT, KEC 15
• Magical thinking in managers assumes teams can always take on more work without
impact, relying on overtime and “power weeks” to get tasks done.

• Hero developers reinforce this by working extra hours for recognition, becoming the
main measure of value—while ignoring software quality or long-term maintainability.

• This approach builds up technical debt, leads to buggy, unfinished software, and
eventually slows the team as they fix problems instead of delivering features.

• Agile methods like Scrum and XP emphasize focused work, collaboration, and realistic
timeboxing, which directly oppose magical thinking and hero culture.

• Lean thinking combats magical thinking by making team work transparent, revealing
hidden problems, and encouraging real value delivery over just burning effort.
[Link], AP/IT, KEC 16
Eliminate Waste
• Waste in Lean means any activity that doesn’t add real value to building better software, often
hidden in everyday team habits.

• Teams usually follow ingrained processes without questioning if they actually help—like writing
unused specs or doing superficial code reviews.

• Common waste examples include outdated project plans, unnecessary meetings, and repetitive
manual tasks that don’t improve software quality.

• Lean encourages “refactoring” how teams work—constantly improving processes by spotting and
removing waste to create a more flexible, effective team.

• Some wasteful tasks may still be necessary for external reasons (management, regulators), but
they don’t directly help the project and should be minimized.
[Link], AP/IT, KEC 17
• Waste is often hard to spot because it usually serves someone else’s priorities
(like managers or contractors), and some waste is so familiar it becomes
invisible.

• For example, time-consuming budgeting or physical separation of team

members causing [Link] Poppendiecks adapted Toyota’s Lean principles
into the Seven Wastes of Software Development to help teams identify and
eliminate waste.

[Link], AP/IT, KEC 18

The Seven Wastes of Software Development
•Partially Done Work: Only fully completed (“done done”) work delivers value;
incomplete work is waste.
•Extra Processes: Unnecessary steps like excessive status reporting that don’t add value.
•Extra Features: Building features users don’t need, even if they help team skills, is waste.
•Task Switching: Multitasking causes delays due to cognitive overhead—focus reduces this
waste.
•Waiting: Delays caused by waiting on approvals, resources, or problem fixes.
•Motion: Physical movement to communicate wastes time and slows projects.
•Defects: Bugs that require late fixes cost more time than writing good tests upfront.

[Link], AP/IT, KEC 19

• Waste can seem useful but doesn’t add value to the product—some
activities help others but don’t help the project’s goals.

• Frameworks or processes intended to save effort can become obstacles,

creating extra work and slowing progress.

• Lean thinking teaches teams to spot and acknowledge waste clearly,

focusing on what truly adds value to the product.

[Link], AP/IT, KEC 20

Use a Value Stream Map to Help See Waste Clearly
• Pick a minimal marketable feature (MMF)—the smallest deliverable chunk of
value the customer wanted.

• Map all the actual steps the feature went through from start to delivery in a
straight line (no branches).

• Estimate and mark the time spent working and waiting between each step to
spot delays and inefficiencies.

[Link], AP/IT, KEC 21

[Link], AP/IT, KEC 22
• The feature took 71 days from start to deployment, but half that time (35.5
days) was waiting, not working.

• Waiting could come from slow reviews, scheduling delays, or committee

approvals.

• The team might not notice the wait because they’re busy on other tasks, but the
customer only sees the total delay.

• Showing the boss this map helps highlight the impact of waste and motivates
changes to speed up delivery—making customers and bosses happier.

[Link], AP/IT, KEC 23

 Gain a Deeper Understanding of the Product
• Integrity means the product balances function, usability, reliability, and cost to

delight users.

• Perceived integrity is how well users feel their needs are met by the software.

• Conceptual integrity means the software’s features work smoothly and cohesively

together.

• Poor perceived integrity frustrates users, like a website that blocks expected actions.

[Link], AP/IT, KEC 24

• Video games show the importance of conceptual integrity by catering to casual

and hardcore gamers differently.

• Casual games gradually increase difficulty, while hardcore games embrace

challenge and “grinding.”

• Difficulty settings in games help maintain integrity for both player types.

• Teams improve software value by understanding and designing for both

perceived and conceptual integrity.

[Link], AP/IT, KEC 25

See the Whole

• Organizational structures and processes often introduce inefficiencies or “waste”

that impact how software teams work.

• Some wasteful activities may be necessary for the company but don’t add direct
project value.

• Lean value “see the whole” means understanding the entire system objectively,
not just individual parts or perspectives.

• Different team members may have conflicting views on project success;

objective measurements help align perspectives.
[Link], AP/IT, KEC 26
• Users value quick delivery of features, which is why agile methods use
short iterations and feedback loops.

• Positive status reports may mask real problems like long feature lead
times, causing customer dissatisfaction.

• Measuring lead time—the average time from feature request to delivery—

provides an objective way to identify and fix responsiveness issues.

[Link], AP/IT, KEC 27

 Find the Root Cause of Problems That You
Discover
• Seeing the objective truth through measurements is only the first step; the next is

finding the root cause of problems.

• Lean and XP teams use the “Five Whys” technique—asking “why” repeatedly

(about five times) to uncover the root cause.

• Example: Long lead times are due to late-stage changes requested by senior

managers after demos.

• These late changes happen because managers don’t engage early, only reviewing

finished work, causing delays and rescheduling.

[Link], AP/IT, KEC 28
• This root cause shows the delay isn’t the team’s fault but a process issue

impacting delivery speed and customer satisfaction.

• Possible solutions include more iterative demos with managers, delegating

approval to a Product Owner, or managing user expectations better.

• Identifying root causes helps align the team and leadership with objective facts,

enabling informed decisions and long-term fixes.

[Link], AP/IT, KEC 29

 Deliver As Fast As Possible
• “Deliver as fast as possible” doesn’t mean rushing, cutting corners, or
overworking—it actually slows teams down.

• Agile promotes sustainable development, where a steady, maintainable pace

leads to better and faster delivery over time.

• Scrum’s Focus and XP’s Energized Work support this by encouraging teams to
work well, not just fast.

• Lean expands this idea using three tools: pull systems, queuing theory, and
cost of delay.
[Link], AP/IT, KEC 30
• Queuing theory helps teams avoid overload by managing task flow—work is
done in order, often first-in, first-out.

• Public, visible queues guide decisions and help teams prioritize effectively,
improving speed and quality together.

[Link], AP/IT, KEC 31

Use an Area Chart to Visualize Work in Progress
• Lean uses measurement to determine if a team is delivering as fast as possible.

• A useful tool for this is the Work-In-Progress (WIP) area chart.

• The WIP chart shows how minimal marketable features (MMFs) flow through each
stage of the value stream.

• It’s based on the value stream map you’ve already created.

• MMFs are used because they represent the smallest chunk of deliverable customer
value.

• The chart helps teams visualize flow efficiency and identify bottlenecks.
[Link], AP/IT, KEC 32
• It supports better decisions by revealing where delivery can be improved.
[Link], AP/IT, KEC 33
• Goal of the WIP area chart: Show the complete history of work in progress,
measured in MMFs (not tasks).

• The chart tracks features currently being worked on, across all value stream
stages.

• Tasks used to build features are not shown; only the feature-level (like user
stories) is tracked.

• A user story is a good example of an MMF—it's a small, self-contained unit of

user value.
[Link], AP/IT, KEC 34
• The x-axis shows time (dates); the y-axis shows the number of MMFs in
progress.

• Each value stream stage from the map is represented as an area in the chart.

• You plot points as MMFs are added—e.g., 9 MMFs on day 1, then 3 more
later = 12 total.

• Connect the points to show how MMFs flow through the stages over time.

[Link], AP/IT, KEC 35

[Link], AP/IT, KEC 36
• As MMFs progress to the next stage (e.g., 4 stories move to design), the
total WIP remains 12, but it’s split across multiple stages (e.g., 8 in
stage one, 4 in stage two).

• Over time, as MMFs move through stages, the WIP area chart fills with
layered “stripes”, showing how work is distributed across the value
stream.

[Link], AP/IT, KEC 37

[Link], AP/IT, KEC 38
• What happens when MMFs are completed? If you keep them on the chart,
eventually the number of “done” MMFs grows to a size that dwarfs all of the
other columns. This makes the active MMFs resemble a ribbon on top of a
mountain.

[Link], AP/IT, KEC 39

• Including completed work in a WIP area chart shows growth, not flow, which
can mislead managers without helping teams manage progress. Most WIP
charts exclude completed MMFs to better visualize how value moves through
stages—thinner and thicker stripes show transitions and trends clearly.

[Link], AP/IT, KEC 40

[Link], AP/IT, KEC 41
 Control Bottlenecks by Limiting Work in
Progress
• Theory of Constraints (by Eliyahu Goldratt) says every overloaded system
has at least one constraint or bottleneck limiting overall work throughput.

• When one bottleneck is removed, another becomes critical, so improving flow

means identifying and eliminating constraints one by one.

• A bottleneck causes work to pile up, increasing delays and waste in the
system.

[Link], AP/IT, KEC 42

• Teams stuck as bottlenecks often face multitasking pressure, switching
between too many responsibilities.

• “Multitasking” often hides the reality that the team is simply overloaded.

• Extra tasks (like support or meetings) added gradually can exhaust teams
without them realizing why.

• Applying queuing theory helps teams recognize bottlenecks and fix the real
root cause of overload.

[Link], AP/IT, KEC 43

Pull Systems Help Teams Eliminate Constraints
• Pull Systems Origin: Pull systems began in Japanese auto manufacturing (e.g., Toyota) to avoid delays

caused by missing parts; they deliver parts only when needed, reducing waste and wait time.

• Waste Types in Lean: Lean identifies three types of waste:

• Muda: Futility or unnecessary work.

• Mura: Unevenness or inconsistent workflows.

• Muri: Overburdening or unrealistic expectations.

• Common Software Project Problems: Delays, rigid specs, late testing, unnecessary change control,

and overstaffing at the end are all signs of waste—either muda, mura, or muri.

• Theory of Constraints: Every system has at least one bottleneck limiting flow. When one is removed,

another appears. Identifying and fixing constraints reduces delays and improves output.
[Link], AP/IT, KEC 44
• Multitasking Masks Overload: Teams forced to multitask often don’t realize they’re

overloaded—task switching adds time and stress, reducing efficiency.

• Pull vs. Push in Software: Instead of managers pushing tasks, teams pull small chunks of

work from a queue when ready. This improves flow and reduces overload.

• Lean Software Parallel: Lean thinking from manufacturing (e.g., TPS) can be applied to

software by focusing on reducing waste, managing constraints, and improving flow through

pull systems.

• MMFs and Options Thinking: Breaking work into Minimal Marketable Features (MMFs)

gives teams flexibility—some can be approved and started quickly while others go through

more review. [Link], AP/IT, KEC 45

• Pull System Example: Replacing a massive spec-and-review process with

small, approvable chunks (MMFs) allows the team to begin work sooner and

avoid wasteful prework.

• Lean Integration: Lean thinking combines seeing the whole, removing waste,

and setting up pull systems to create a more efficient and adaptable way to build

software.

[Link], AP/IT, KEC 46

[Link], AP/IT, KEC 47
Kanban, Flow, and Constantly Improving

[Link], AP/IT, KEC 48