Learning Objectives

Differentiate between time-boxing and flow-based

methods
Describe the Kanban Model
Identify the importance of work in progress (WIP)
limit
Name core Kanban principles
Recognize the Kanban matrix and able to a draw
cumulative flow diagram
Identify key differentiators of Kanban and discuss the
situations/environment where application of Kanban

Time-box vs. Flow Based

Iteration 1

Iteration 2

Time-box

Implementation
Design & Analysis

Implementation
Design & Analysis

Q/A

Requirement

Deploy

Evaluation
Prioritization

Process
Flow

Backlog

Q/A

Requirement
Evaluation
Prioritization

Deploy

Backlog
Evaluation
Prioritization

Requirement

Design & Analysis Implementation

Q/A

Deploy

Time-box vs. Flow Based

Time-boxing is a tool. Fundamentally, its designed
to establish a sense of urgency and to coerce the
team to focus their efforts on getting something
done.
Scrum is rooted in the concept of time-boxing
which is a time-management technique that helps
organize the performance of work and manage
scope. Each event takes place in a time frame with
a specific start and end, called a time-box. Inside
this time-box, the team is expected to work at a

Time-box vs. Flow Based

Time-boxing is important for several
reasons

Establishes a WIP limit

Forces prioritization
Demonstrates Progress
Avoids Unnecessary perfectionism
Motivates closure
Improves predictability

Kanban Model
Pull

Kanban Board
Increment

Queu
e

To
Customer

Kanban Model
Kanban is a Japanese word that means "visual card" or "signboard.
At Toyota, Kanban is the term used for the visual & physical signaling
system that ties together the whole Lean production system.
Kanban as used in Lean production is over a half-century old. It is
being newly adapted to some disciplines such as: software.
The Kanban model, illustrated before, is based on the notion that the
team works on the appropriate number of features through
completion. When the team is ready to begin on the next feature, they
pull a feature from a small queue of potential work. This allows for
proper management of both selecting what to work on and how to do
the work.

Kanban Model
It focuses the team on building features that
are as small as possible and that add value to
the customer.
The development pipeline has small queues
and batches and so is more efficient.
The team still gets quick feedback to keep
them on track.

The Differences Between Kanban and Common Agile

Approaches
The queues in front of software development
teams stay small.
The software development teams focus on
completing features as quickly as possible but are
not constrained by a time-boxed system.
Kanban is explicit about including the entire
value stream, from concept to consumption. Ideas
from the customer start the value stream, and the
product managers are directly tied to the teams
because of the work-in-process limits that Kanban

Kanban Board with Work In Progress (WIP)

Backlog

WIP Limit = 4

WIP Limit = 3

Selected

In Progress

Done

Kanban Board with Work In Progress (WIP)

In Kanban the first step is to visualize your current process,

just as it is, in order to see where the bottlenecks are.
Then you introduce WIP limits and start a path of evolution
that may or may not modify or replace your current process
over time.
Kanban does not specify a technique for managing how
work is done: It can be done individually or by a team
swarm.
Instead, Kanban seeks to control the amount of WIP
that is allowed.
Kanban accomplishes this by specifying slots for each

Kanban Board with Work In Progress (WIP)

WIP is associated with number of problems, including:

WIP represents money invested with no return on that
investment yet.
WIP hides bottlenecks in processes, and it masks
efficiency issues.
WIP also represents a risk in the form of potential
rework, since there may still be changes to items until
those items have been accepted. If there is a large
inventory of WIP, there may in turn be a lot of scrap or
expensive rework if a change is required.

5 Core Principles of Kanban (by Anderson)

1.
Visualiz
e the
workflo
w

2. Limit
Work In
Progres
s
3. Make
Process
Policies
explicit

4.
Manage
Flow

5. Improve
Collaboratively

Visualize the Workflow

In order to understand how to work, it is important to

visualize the flow of work.
The right changes are harder to perform if we dont
understand the workflow. One common way to visualize the
workflow is by using a card wall with cards and columns,
called a Kanban board.
The columns on the card wall represent the different states
or steps in the workflow, and the cards represent the
feature, story, task, or result of the workflow, usually
referred to as work items.
What is great is that we use the steps of our existing
workflow and we dont need to enforce a new way of

Work-in-Process Limit
The WIP limit is important and tells us how many work
items we can have in each of our steps (columns on
the Kanban board).
When the limit is reached, we cannot pull any new
items into this step until another work item leaves this
step.
This pull system will act as an important stimulus for
continuous, incremental, and evolutionary changes to
the system because one of the main points is to
continuously optimize the process to let more items
pass through the system.

Manage Flow
We constantly need to monitor all stages of
our workflow.
We need to follow up, measure, and report
on the flow of our system. This way we can
more easily see the effects of a change in
the system.
Did it or didnt it work?

Manage Flow (cont.)

If a step in our workflow is full, we cannot bring any new

items into this step. Looking at the board, we can quite
easily see if we have a bottleneck in our flow.
If we discover that all columns to the right of the
development step on our board are empty, but the
development step is full, this means that something is
stopping development and the team cannot finalize their
work.
Then we should use idle resources to try and help the
developers solve what is stopping them so we can restart
the flow again and start pulling work items into the steps
again. By having this visibility, we can manage our flow and

Make Process Policies Explicit

It is often hard to improve, or even start a
discussion of improving a process, until the
mechanism of the process is made explicit.
We need to understand how things work in our
workflow and understand how we perform our
work.
This way we can reach a consensus around the
improvements we suggest. If we do not have an
understanding of these things, we often end up in

Improve Collaboratively
As we explained earlier, Kanban supports
small continuous, incremental, and
evolutionary changes that should stick to our
organization.
Small steps are easier to overcome than
revolutionary changes, something that David
Anderson soon discovered.

Improve Collaboratively (cont.)

If the small steps also have a great payback,
change is even easier to implement.
Anderson stresses that teams that have a shared
understanding of theories about work, workflow,
process, and risk are more likely to be able to
build a common understanding of the problem.
This, in turn, makes it easier to reach an
agreement on the improvement steps that are
necessary. The Kanban method suggests that we
use a scientific approach in order to implement

Classes of Service
WIP limit
2

DEV

TEST

EXPEDITE (FAST LANE)

BACKLOG ANALYSIS

= System
Improvements

=
Features

= Bugs

DEPLOY

DONE

URGE
NT
Different
Workflow
Swarm
immediately

Explicit Policies: Definition of

Done (DoD) for each Step

Classes of Service

Some types of work may need to flow faster through the

workflow than others. This is where the concept of classes
of service comes in handy.

By categorizing the work into classes of service, the

Kanban board will radiate with even more information. In
this example three classes of service are used:
Green System improvements (technical or
maintenance driven)
Blue Features (customer or roadmap driven)
Orange Bugs (errors in existing functionality, found

Classes of Service
Now policies can be created
For example, that X% of the work has to
be system improvements. Other things
can also be spotted, if the orange stickies
(bugs) are dominating we may have a
problem with quality, and so on.

Kanban Attributes

Kanban is flow based rather than time-boxed

Does not assume all estimation is unnecessary, but suggest

looking at value received for time invested

True value lies in its requirement that the team creates a

workflow with explicit defined rules and limits

Manage workflow by limiting the amount of WIP at any step in

the workflow

Team process rather than individual

Kanban focuses on how the workflow process can be improved

rather than blaming an individual

Transparent process allows management to be involved in

improving it

Scrum vs. Kanban

SCRUM
Fixed time-boxes
Tasks are Estimated
Track velocity
Scrum Master own the process
Cross-functional teams
prescribed
Cannot add items to ongoing
iteration

KANBAN
No time-boxes
No Tasks Estimates (optional)
Track flow (Queues, WIP, Cycle
time)
Team own the process
Cross-functional teams optional.
Specialist teams allowed
Can add new items whenever
capacity is

Prescribes roles (PO, SM, Team)

available
Doesnt prescribe any roles

Scrum vs. Kanban

Both are Lean and Agile,

Both are pull scheduling
Both Limit WIP
Both use transparency to drive process
improvement
Both focus on delivering releasable software
early and often
Both are based on self-organizing teams
Both require breaking the work into pieces

Discussion and Reflection

Evidence suggests that teams learn continuous process improvement
faster with Kanban. Some of the reasons are as follows:

Kanban reduces the fear of committing to a per-story estimate,

which is a significant risk for some teams. Fear always impedes
learning
Kanban is explicitly a team process rather than one for individuals. It
highlights the teams performance rather than individuals and can
reduce the fear of embarrassment.
Kanban focuses on how the workflow process can be improved
rather than blaming the individual
Kanban allows reflection about concrete measures such as, Should
WIP be 4 or 5? Reflection about concrete issues is often easier in
the beginning than reflecting about more abstract or personal issues

Exercise: Research these Terms

Batch Size
Bottleneck
Block work item
Concept to cash
Continuous improvement
Cost of delay
Cadence
Cumulative flow
Classes of services
Decentralize
Cycle time
Lead time
Drum-buffer-rope
Fast lane

Explicit
Kaizen
Lean
Kaikaku
Muda
Muri
Silver bullet
Queues
Process policies
Swim lanes
Throughput
Time to market
Value stream mapping
Transparency
Theory of constraints