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
•Based on Lean Thinking: Kanban uses the Lean mindset—focused on reducing waste and
improving efficiency—to help teams improve how they work.
•Focuses on Process Improvement: Unlike Scrum (which manages projects) or XP (which
improves coding), Kanban helps teams improve their workflow over time by making small,
continuous changes.
•Identifies and Eliminates Waste: Teams using Kanban learn to spot waste in their process
(like overburden, uneven flow, and useless work—muri, mura, muda) and remove the root
causes.
•Most Common Way to Apply Lean in Agile: While Lean can be used without Kanban,
Kanban is the most popular way agile teams apply lean thinking in software development.
[Link], AP/IT, KEC 48
•Start with what exists: Kanban begins by accepting your current process, roles,
and structure. Then, it encourages small, steady improvements over time.
•Use key practices to improve flow: Kanban teams visualize their work, limit
work in progress (WIP), and manage the flow of tasks to reduce delays and
bottlenecks.
•Make everything clear and collaborative: Teams make rules and processes
visible, use feedback loops, and experiment with changes to keep improving.
•You don’t need to do everything at once: Teams can start with a “shallow”
Kanban implementation and add more practices gradually as they grow in skill
and confidence. [Link], AP/IT, KEC 49
 Act II: Playing Catch-Up
• Dan, Catherine, and Timothy Story

• Constant Micromanagement:
Dan keeps interfering with the team’s work during every project, calling it "Intensive Care
Unit mode," which frustrates the team.

• Perpetual “Crunch Time”:

Dan always pushes urgency, claiming every deadline is critical, creating constant pressure
instead of solving root problems.

• Communication Breakdown:
Dan ignores input from Catherine and Timothy, cuts them off, and assumes control, which
[Link], AP/IT, KEC 50
demotivates the team.
• Recurring Waste and Delays: The team faces repeated issues, like long
UI discussions and last-minute bug fixes, but these problems aren’t
addressed systematically.

• Resistance to Improvement: Catherine tries to raise the idea of process

waste and continuous problems, but Dan dismisses it as “negative.”

• Missed Opportunity for Lean Thinking: Instead of learning from

patterns and improving the process, Dan just demands more urgency—
blocking real improvement.

[Link], AP/IT, KEC 51

The Principles of Kanban

Kanban’s foundational principles:

• Start with what you do now

• Agree to pursue incremental, evolutionary change

• Initially, respect current roles, responsibilities, and job titles

[Link], AP/IT, KEC 52

•Start with your current process: Kanban doesn’t replace your
workflow — it improves it gradually, beginning with how your
team already works.
•It’s for improving process, not managing projects: Unlike
Scrum (which manages projects), Kanban helps teams
continuously improve how they deliver software.

[Link], AP/IT, KEC 53

Find a Starting Point and Evolve Experimentally
from There
•Recurring problems feel normal until examined: Teams often repeat mistakes
without realizing it because the issues don’t seem like mistakes in the moment.
•Real improvement starts with finding patterns: To improve, teams must look
for common causes behind recurring problems, not just blame people or bad
luck.
•Kanban starts with your current system:Every team already has habits and
routines (even if they're unspoken); Kanban makes these visible and
changeable. [Link], AP/IT, KEC 54
•Change happens through measurement and feedback: Teams use
experiments, data, and feedback loops to test small changes and learn what
really works.
•Respecting roles supports learning: Kanban doesn't require changing team
roles — it amplifies learning by building on what’s already working, not
replacing it all.

[Link], AP/IT, KEC 55

 Wait a minute. So Kanban doesn’t tell me
how to run my project?
•Start with your current process:
Kanban doesn’t replace your method (Scrum, XP, waterfall, or even
chaos); it helps you understand and improve what you already do.
•Most teams don’t question their system:
Just because a team is following a method doesn’t mean it’s efficient
—waste can hide in familiar habits.
[Link], AP/IT, KEC 56
•Waste can go unnoticed: Even if everyone is busy and
productive, the overall system might still be slow or
inefficient (e.g., long lead times).
•Kanban helps reveal and fix hidden problems: By
visualizing work and measuring flow, Kanban surfaces
issues that teams wouldn’t otherwise see—and helps
improve them over time.

[Link], AP/IT, KEC 57

Stories Go into the System; Code Comes Out
•See the system behind the work: Teams don’t just make isolated decisions—
they follow patterns and workflows. Recognizing this is called systems
thinking.
•Scrum (or any method) is a system For example, Scrum turns backlog items
into code. Seeing it as a system helps identify waste or unnecessary steps in
that flow.
•Kanban begins with understanding your system: No matter your method
(Scrum, XP, or none), Kanban helps by encouraging teams to see and improve
the way they work as a whole.
[Link], AP/IT, KEC 58
 Every software team follows a system,
whether they know it or not
•Every team has a system—even if it’s informal: People naturally follow habits
and unwritten rules when they work together, even if they don’t realize it.
•Value stream maps help make the system visible: By tracing how a feature
moves from idea to code, teams can map out the real process they follow—this
reveals their actual system.
•Once you see your system, you can improve it: Understanding the paths your
work takes lets you spot waste and make thoughtful changes, even if the
system has multiple paths. [Link], AP/IT, KEC 59
Kanban is not a software methodology or a project management system

•Kanban is for process improvement, not just software development.

It helps understand and improve how work flows, not just a way to build
software.
•Kanban boards track work items, not tasks.
Work items are larger units of work that move through the system; tasks are the
smaller actions people do to move these items along.
•Tasks are the “cogs” moving work items; people are not cogs.
Systems thinking focuses on tasks pushing work items forward, respecting that
[Link], AP/IT, KEC 60
people have unique motivations.
•Kanban boards show the entire workflow, beyond just the team’s sprint.
They include stages before and after team work, unlike task boards which
focus only on team tasks during a sprint.
•Kanban helps reveal process problems unseen on task boards.
Issues like delays or wrong work items can be identified because Kanban
shows the bigger picture.
•Kanban improves flow predictability and influences project management.
Using Kanban practices and metrics can evolve how a project is planned and
managed.
[Link], AP/IT, KEC 61
 Improving Your Process with Kanban
•Kanban is an agile, Lean-based process improvement
method created by David Anderson, inspired by Japanese
manufacturing.
•Traditional process improvement often involves top-down
mandates, heavy documentation, and committees, leading to
frustration and poor adoption by teams.

[Link], AP/IT, KEC 62

•Many traditional efforts fail because processes feel unnatural, and
teams just comply superficially without real engagement.
•Kanban differs by empowering the team itself to identify workflow
problems, suggest improvements, measure results, and hold
themselves accountable.
•This team-driven approach is why agile teams find Kanban effective
compared to traditional, manager-driven process improvement.

[Link], AP/IT, KEC 63

 Visualize the Workflow
•The first step in Kanban is to visualize the team’s actual current workflow—warts
and all—without adding things just because they should happen.
•People tend to include ideal steps (like code reviews) even if they don’t happen
consistently, which hides real problems.
•This false visualization prevents teams from identifying and fixing underlying
issues.
•Kanban emphasizes honest, accurate visualization as part of Lean thinking,
following principles like “see the whole” and “decide as late as possible.”
•Accurately visualizing workflow helps teams truly understand their process and
prepare to improve it effectively. [Link], AP/IT, KEC 64
 Use a kanban board to visualize the workflow

•Kanban boards visualize workflow with columns and sticky notes,

similar to Scrum task boards but focused on work items (stories)
rather than tasks.
•The columns on a kanban board vary by team and represent actual
workflow steps; teams first create a board that reflects their unique
process to start visualizing work.
[Link], AP/IT, KEC 65
[Link], AP/IT, KEC 66
• Kanban teams regularly “walk the board” to update and discuss work items, using
a board tailored to their own actual workflow rather than copying someone else’s,
supporting continuous, evolutionary improvement.

1. Team gets a feature request from a user

2. Project manager schedules features for the next release

3. Team builds the feature

4. Team tests the feature

5. Project manager verifies that the tests pass

6. The feature is done and included [Link],

the next release
AP/IT, KEC 67
A kanban board visualization reveals the real workflow—
including problems and variations—more clearly than a
written list or idealized “happy path.”

[Link], AP/IT, KEC 68

1. Team gets a feature request from a user

2. Project manager schedules features for the next three-month release

3. Team builds the feature

4. Team tests the feature

5. Project manager verifies that the tests pass

6. Project manager schedules a demo with senior management

7. If senior management wants the team to make changes to the feature, the project manager does
an impact analysis on the changes, and the feature moves back to step1—if not, it moves on to step
8

8. The feature is done and included in the next release

[Link], AP/IT, KEC 69
Adding a “Manager Review” column to the kanban board
reflects the real step where senior managers review and may
delay features after the team finishes work.

[Link], AP/IT, KEC 70

As a team member, I want work items bumped by managers to be
placed in a new “Bumped by Managers” column with a dot indicator,
So that these critical items stay visible and continue progressing
without restarting the whole workflow.

[Link], AP/IT, KEC 71

As a team member, I want the Kanban board to clearly show
the impact of senior managers’ feature reviews on lead time, So
that everyone can objectively see the cause of delays and
address the problem.

[Link], AP/IT, KEC 72

 Limit Work in Progress
• Overcommitting leads to waste and burnout

When teams take on more work than they can handle, it results in missed deadlines, poor quality, or
unsustainable work pace. Even if each task seems reasonable alone, multitasking and context-switching can
halve productivity.

• Visualizing work reveals bottlenecks

A kanban board makes workflow problems like unevenness and overburdening visible—e.g., stickies piling
up in a column. This clarity helps identify where the system is breaking down.

• WIP limits prevent overburdening

By setting Work In Progress (WIP) limits, teams control how many items can be in any workflow stage.
This reduces multitasking, prevents team overload, and keeps work flowing smoothly.

[Link], AP/IT, KEC 73

• Options thinking enables smarter decisions

Rather than blindly pushing work forward, team members choose from multiple available tasks
across the board. This options-based thinking improves efficiency and prevents unnecessary queues.

• WIP limits create valuable feedback loops

For example, setting a WIP limit on “Manager Review” forces earlier review sessions. This allows
for early feedback, reduces waste, and avoids last-minute work being bumped or discarded.

• WIP limits are adjustable and collaborative

There’s no fixed number for WIP limits. Teams experiment and adjust based on measurements and
collaboration with stakeholders, continuously improving workflow and shortening feedback cycles.

[Link], AP/IT, KEC 74

[Link], AP/IT, KEC 75
Why not make the WIP limit 1 and meet all the time?
Aren’t shorter feedback loops better?
Feedback loops must be balanced

Too-frequent reviews cause thrashing, where teams spend more time handling feedback than doing productive

work. Kanban helps visualize and adjust feedback timing through WIP limits.

Repeated loops clog the workflow

Sending the same features back through the process wastes time and WIP capacity. Marking repeated items

makes bottlenecks visible and helps teams reduce unnecessary rework.

A linear workflow is often faster

By limiting re-reviews and adding steps after feedback (instead of looping back), teams create a longer but

smoother workflow. This improves lead time—and teams feel the difference firsthand.
[Link], AP/IT, KEC 76
[Link], AP/IT, KEC 77
Measure and Manage Flow

[Link], AP/IT, KEC 78