kanban systems for software engineering - scrum...
TRANSCRIPT
ScrumSense
Cape Town
February 2010
Kanban Systems for Software Engineering
David J. Anderson
Independent Management Consultant
http://www.limitedwipsociety.org
Yahoo! Groups: kanbandev
http://www.kanban101.com
Taiichi Ohno…
TPS = JIT + Deming
Kanban is the tool that enables these
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Kanban is a hot topic in the Agile community
Open Space at Agile 2007 attracted 25 people
Yahoo! Group now has 1050+ members and growing
Implementations at countless companies since August
2007 and on 5 continents
BBC is best known adopter with more than 20 teams in
London using kanban
Other adopters include Software Engineering
Professionals (Indianapolis), BNP Parisbas (London),
IPC Media (London), and Robert Bosch
Corey Ladas published Scrumban, a book about
adding Kanban to Scrum
Henrik Kniberg & Matthias Skarin , Kanban and Scrum
published in Winter/Spring 2010
Davd J. Anderson, Kanban: catalyzing Lean in your
technology organization, due in Spring 2010
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Managing with Queues back in 2004
0
20
40
60
80
100
120
140
160
180
200
220
240
Fe
atu
res
Time
Device Management Ike II Cumulative Flow
Inventory Started Designed Coded Complete
WIP
Avg Lead Time
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Donald Reinertsen’s Advice
Immediately focus on reducing
waste through improved quality
measured as defects per unit of
valued work
Reduce work in progress
Together these will always have an
immediate impact
Given the groundwork on tracking
and cumulative flow, the elements
are in place to implement a kanban
system
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
With Don’s advice I developed myRecipe for Success
Focus on Quality
Reduce Work-in-Progress, Release Often
Balance Demand against Throughput
Prioritize
And for advanced credit…
– Reduce variability and improve the process
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
What is a kanban (pull) system?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Definition of Kanban
5 Core Properties
•Limit Work-in-Progress
•Visualize Workflow
•Measure & Optimize Flow
•Make Process Policies Explicit
•Manage Quantitatively
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Definition of Kanban (part 2)
5 Emergent Properties
•Prioritize Work by Cost of Delay
•Optimize Value with Classes of Service
•Spread Risk with Capacity Allocation
•Encourage Process Innovation
•Use Models* to Recognize Improvement
Opportunities
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Let’s take a break for 15 minutes
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Case Study Microsoft 2004/2005
XIT one of Microsoft’s 8 IT departments
XIT Sustained Engineering
Small team
Change requests
Supports over 80 applications (and growing)
Engineering responsibilities moved from Redmond
(Washington, USA) to Hyderabad (India) in 2004
Hyderabad vendor is CMMI Level 5 and uses
TSP/PSP
Initial quality is very high
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Dark Days in July 2004
Dev Mgr Test MgrPM
ProductManagers
User Acceptance Test
Backlog 155 Days
ChangeRequests
Demand is outstripping supply and the queue is growing
Manager resigns end June
2004 – open position Q3
2004
Backlog is 80+ and
growing about 20 per
quarter
Lead time is 155 days
Customer satisfaction –
lowest in IT department
Jan-04Apr-04
Jul-04Supply
0
10
20
30
40
50
60
70
80
90
Change Requests
Quarters
Sustained Engineering Supply v Demand
Supply Demand
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Estimation (ROM) was Top Priority
Dev Mgr Test MgrPM
ProductManagers
User Acceptance Test
Backlog 155 Days
ChangeRequests
ROM
ROM
Open and Read Source Code
Read Application Guide
Whole process about 1 day per developer and tester
SLA – 48 hours to return a rough order of magnitude estimate (ROM)
All change requests are ROM estimated
ROMs are expedited as top priority due to SLA
3 Developers,3 Testers
But…80 Applications
What happens?...
Estimation was using33%-40%
of available capacity!!!
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Estimates were used to facilitate cost accounting
Dev Mgr Test MgrPM
ProductManagers
User Acceptance Test
Backlog 155 Days
ChangeRequests
ROM
ROM
Use ROM x Fixed Rate
per hour to calculate
Cost of Change
Request
Evaluate ROI of
request
( Value/Cost )
Assign costs against
“bucket of funding” from
customer group
$600K*
$200K
$100K
$100K
BudgetFunding
*Numbers are indicative only
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Estimates were also used to facilitate monthly rescheduling
Dev Mgr Test MgrPM
ProductManagers
User Acceptance Test
Backlog 155 Days
ChangeRequests
ROM
ROM
Monthly rescheduling
meeting
Assign “urgency” to
each request on
backlog
Reschedule entire
backlog based on
urgency and ROM
estimate
(every month!)
But…
Throughput was
approximately
7 per month
Backlog > 80Rescheduling at least70 requests that cannotbe worked every month
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Actual effort was miniscule compared to lead time of 155 days
Dev Mgr Test MgrPM
ProductManagers
User Acceptance Test
Backlog 155 Days
ChangeRequests
ROM
ROM
Historical data gathered over
9 months showed that a
typical change request took
approx 5 business days to
process through
development
Low end was 1 day
High end 15 days
1 to 23 to 5
6 to 1011 to
15> 15
0
5
10
15
20
25
Ch
an
ge
Re
qu
es
ts
Effort in Days
Dev Test
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Are Estimates waste?
Dev Mgr Test MgrPM
ProductManagers
User Acceptance Test
Backlog 155 Days
ChangeRequests
ROM
ROM
Only 52% of requests were actually ever completed
Other 48%
Too big(bigger than 15 days)
Too expensive (low value versus cost)
Overtaken by events, application decommissioned before request is processed
ROMs are taking 40% of capacity but 48% of ROMs represent analysis that is never used beyond estimate, schedule and go/no go decision!
Knowledge work is perishable. ROM analysis is done months before work is conducted and there is no guarantee that ROM is conducted by same engineer who will code or test.
Conclusion – all ROMs are waste
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Could it get worse? Expediting
Dev Mgr Test MgrPM
ProductManagers
User Acceptance Test
Backlog 155 Days
ChangeRequests
ROM
ROM
PTCNon-code Fix
Production Text Change
E.g. graphical changes, data changes, anything that didn’t require a developer
Must be expedited
Need to make formal QA pass
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Backlog Dev Queue
Dev
New
Approved
StartedOn
Hold
Test Queue
Test
StartedOn
Hold
Resolved
Failed
UAT Queue
UAT
Started
Failed,
Scope Changed
Passed
SOX
Production Queue
Complete
Passed
ClosedReleased
Transferred to Proj Team
Pending Future Project
By Design
Duplicate
Won’t Fix
No Repro
New
Analysis
More Info
Info
Received
Abandoned
XIT Change Request
Resolved
(needs
exception)
Re-opened
State Model
WIP limit initially
8 = 3 (dev) + 5 (q)
WIP imit initially
8 = 3 (test) + 5 (q)
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Intervention 1Pace the Line from Development
Local Mgr
PM
ProductManagers
User Acceptance Test
Backlog
ChangeRequests
Kanban8 cards(3 WIP
5 Queue)
Kanban8 cards
PTCExpedite
25 Days
Development Kanban Typically enough for WIP + 7 days
Test Kanban Typically enough for WIP + 7 days
Pace line at rate of consumption
At times of high expediting levels, kanban insures that line is paced from Test not Dev
Reduces lead time by insuring single-tasking
Focuses customer acutely on selection of highest priority (urgency) requests for insertion into empty buffer slots
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Intervention 2 – Stop Estimating
Local Mgr
PM
ProductManagers
User Acceptance Test
Backlog
ChangeRequests
Kanban8 cards(3 WIP
5 Queue)
Kanban8 cards
25 Days
Stop cost accounting
No such thing as a cost of change request
Costs are fixed
Funding is spent with vendor on 12 month contract and paid out on
monthly burn rate
All changes would be treated equally for cost purposes
Based on average of 5 business days through development
PTCExpedite
ROM activity abandoned
Freed up 40% capacity
Instant boost to productivity
numbers
Edge cases
Too big (take risk, identify once
in development)
Too expensive (don’t care)
Following Deming’s advice –
manage for the normal and treat
exceptions as exceptional
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Intervention 3 - Balancing the Line
Local Mgr
PM
ProductManagers
User Acceptance Test
Backlog
ChangeRequests
Kanban8 cards
25 Days
PTCExpedite
Kanban9 cards(4 WIP
5 Queue)
Kanban system and eradication of estimation should introduce
slack in test
Historical data suggested ratio of dev:test is 2:1 but XIT SE has 1:1
ratio (July 2004)
Visited India to observe team after first two interventions
Confirmed belief that test was not fully utilized
Ask vendor to reallocate resource from test to dev to 4:2
Note: Change to kanban size for Dev
Instant improvement in productivity (36 to 45) – 25%
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Intervention 4 - Invest for Yet More Throughput
Local Mgr
PM
ProductManagers
User Acceptance Test
Backlog
ChangeRequests
Kanban8 cards
25 Days
PTCExpedite
Kanban11 cards(5 WIP
6 Buffer)
Kanban9 cards(4 WIP
5 Buffer)
Having eliminated waste and balanced the production process
Removed ROM estimate waste
Removed slack from test
And changed policies that were causing muda to occur
Ceased cost accounting
removed ROM estimate waste
Re-wrote SLAs with customer
Changed prioritization and delayed commitment
Total Improvement of 155% in productivity, but more was needed…
Increase staff to 5:3 dev:test ratio in July 2005
Maintains balance in line
gains a total 217% productivity improvement since July 2004
Note further adjustment to kanban limit
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Zero Backlog – Nov 22nd 2005
After 12 months team hits zero backlog of
change requests
November 2004 – backlog is 80 and trending
upwards
A combination of falling demand and 200%
productivity improvement meant supply was
greater than demand and the backlog was
depleted
Team wins XIT Team Excellence Award for
H2 2005
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Throughput
Sep-04Dec-04
Mar-05Jun-05
Sep-05Dec-05
0
10
20
30
40
50
60
45
56
17
and Cost
45
Zero Backlog achieved
Some idle timeLowers metrics
$7500
$2900$3300
Lowest cost
Highest
Productivity
per person
Shortest lead time
Highest customer
satisfaction
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Productivity (per resource)
Ma
r-0
4
Ma
y-0
4
Ju
l-0
4
Se
p-0
4
No
v-0
4
Ja
n-0
5
Ma
r-0
5
Ma
y-0
5
Ju
l-0
5
Se
p-0
5
No
v-0
5
Dev
0
5
10
15
20
25
Ch
an
ge
Re
qu
es
ts
Quarters
Productivity per Resource
Dev Test
5
12
23
Zero Backlog achieved
Some idle timeLowers metrics
9
15
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Why Lead Time is the best metric
XIT-SE TTR
From 5 Months To 3 Weeks in 5 Quarters
0
20
40
60
80
100
120
140
160
180
FY04 Q4 FY05 Q1 FY05 Q2 FY05 Q3 FY05 Q4 FY06 Q1 FY06 Q2
Quarter
Ca
len
da
r D
ay
s
Other Sev TTR
Sev 1• New Manager
• No More ROMs
• New Prioritization
Process
• Flow Management
Changed dev : test ratio
from 3:3 to 4:2
Increased dev : test from
4:2 to 5:3
Lowest cost
Highest
Productivity
per person
Shortest lead time
Highest customer
satisfaction
Zero Backlog
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Let’s take lunch
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Kanban board and daily standup meeting were introduced in early February 2007 to add a sense of urgency and
team collaboration
More personal responsibility and accountability
Resulted in better visual control
Enabled more self-organization
Less management supervision
Better productivity
Spontaneous quality circles and frequent Kaizen events
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
WIP limits create a kanban pull system &a white board provides visualization of flow
Pull
Flow – from Engineering
Ready to Release Ready
WIP Limit – regulates
work at each stage in
the process
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Kanban board design
Input
Queue
Dev
Ready In Prog Done
Build
ReadyTest Release
ReadyStage Prod.
DoneIn Prog
5 4 43 2 2
Courtesy Olav Maassen QNH
DevelopmentAnalysis
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Kanban board simulation
5 4 43 2 2
Flow
Courtesy Olav Maassen QNH
Input
Queue
Dev
Ready In Prog Done
Build
Ready
Test Release
Ready
Stage Prod.DoneIn Prog
DevelopmentAnalysis
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
… or use one of the many electronic kanban tools now on the market
Agile Zen
LeanKit Kanban
Silver Catalyst
Target Process
RadTrack
Flow.io
Kanbanery
Jira + Greenhopper v4.0
FogBugz + Plugin
VersionOne
Rally(?)
Mingle (??)
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Sticky Buddy scheme was instituted to allow remote workers to keep kanban board up-to-date and
synchronized with electronic tracking
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Exercise 1 – Value-stream Modeling
Take 15 minutes
Split the room into small groups (approx 5 people per group)
Collaborate
Pick someone in the group. Ask them to describe a workflow from their organization and map the value-stream
Create a kanban board to map and track the value-stream
Ask Questions – you don’t know everything you need to know to complete the exercise! For example, how to model concurrency
of tasks?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Define Work Item Types
Change Requests and
Production Bugs – Customer
valued and prioritized by
governing board
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
De-lineate non customer-valued work
Engineering Defects – direct
indicator of quality impact on
productivity, linked to yellow
sticky, not counted against
kanban limit
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Reserve capacity for essential maintenance & upgrades
IT Maintenance Work –
Technology department reserving
capacity for its own maintenance
– difficult to prioritize with
business – count against kanban
limits
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Work Item Types
Types can be derived based on…
Source
E.g. Regulatory Requirement, Field Sales Request,
Strategic Planning Feature
Workflow
Items that flow through different steps (or in a
different sequence) should be different types, tracked
on same board
Size
Order of magnitude
T-shirt sizes
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Use swim lanes to lineate type & allocate capacity across lanes
5 4 43 2 2
Adapted from design courtesy Olav Maassen QNH
= 20 total
...
Change Req
12
Maintenance
2
Production Defect
6
Allocation
Total = 20Input
Queue
Dev
Ready In Prog Done
Build
Ready Test
Release
ReadyDoneIn Prog
DevelopmentAnalysis
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Exercise 2 – Work Item Type Definition
Take 15 minutes
Same groups as before
Collaborate
Define a set of work item types that flow through the value-stream defined in exercise 1
Decide how to visually communicate work item type for each item in the system
Ask Questions – you don’t know everything you need to know to complete the exercise! For example, how to model hierarchical
work item types?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Classes of Service
Change Requests and
Production Bugs – Customer
valued and prioritized by
governing board
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Expediting – the Silver Bullet
Process allows for a single Silver
Bullet expedite request
Silver bullet is hand carried through
the system
Personal attention from project
manager
Automatically jumps queues
Required specialist resources drop
other work in preference to working
the silver bullet
Release dates may be adjusted to
accommodate required delivery date
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Fixed delivery dates are allowed but not encouraged
There are strict rules for date
dependent work items
E.g. date constrained by legal
commitment with customer or supplier,
or regulatory requirement (typically in
financial systems)
Generally, delivery dates are not
allowed
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Temporary classes of work may be introduced tactically to maximize exploitation of the system
Extra Bug – Special class of
production bug, worked by slack
developer resources and
specially selected not to impact
solutions analysis. Tested by
developers not testers. Allows
maximum exploitation for
improved throughput
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Generally speaking class of service should be defined according to
cost of delay function
Cost of delay function for an online Easter holiday marketing
promotion is difference in integral under two curves
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Example classes of service
Expedite
Fixed Delivery Date
Unit step cost of delay function (or near
approximation)
Standard Class
Linear tangible cost of delay function
Intangible Class
Intangible cost of delay
Examples brand identity change, usability fix
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Policies for Expedite Class of Service
Expedite requests will be shown with white colored
cards.
Only one expedite request will be permitted at any
given time. In other words, a kanban limit of 1 is
assigned to the Expedite class of service.
Expedite requests will be pulled immediately by a
qualified resource. Other work will be put on-hold
to process the expedite request.
The kanban limit at any point in the workflow may
be exceeded in order to accommodate the
expedite request.
If necessary a special (off-cycle) release will be
planned to put the expedite request in production
as early as possible.
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Policies for Fixed Date Class of Service
Fixed delivery date items will use purple colored cards.
The required delivery date will be displayed on the bottom right hand
corner of the card.
Fixed delivery dates will receive some analysis and an estimate of
size and effort may be made to assess the flow time. If the item is
large it may be broken up into smaller items. Each smaller item will
be assessed independently to see whether it qualifies as a fixed
delivery date item.
Fixed delivery date items will be held in the backlog until close to the
point where they must enter the system in order to be delivered on-
time given the flow time estimate.
Fixed delivery date items will be given priority of selection for the
input queue at the appropriate time.
Fixed delivery date items will be pulled in preference to other less
risky items. In this example, the will be pulled in preference to
everything except expedite requests.
Unlike expedite requests, fixed delivery date items will not involve
putting other work aside or exceeding the kanban limit.
If a fixed delivery date items gets behind and release on the desired
date becomes less likely it may be promoted in class of service to an
expedite request.
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Policies for Standard Class of Service
Standard class items will use yellow colored cards
Standard class items will be prioritized into the input queue
based on an agreed mechanism such as democratic voting
and will typically be selected based on their cost of delay or
business value
Standard class items will use First in, First out (FIFO)
queuing approach to prioritize their pull through the system.
Typically when given an option a team member will pull the
oldest standard class item from an available set of standard
class items ready for the next step in the process
Standard class items will queue for release when they are
complete and ready for release. They will be released in the
next scheduled release
No estimation will be performed to determine a level of effort
or flow time.
Standard class items may be analyzed for size. Large items
may be broken down into smaller items. Each item may be
queued and flowed separately
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Policies for Intangible Class of Service
Intangible class items will use green colored cards.
Intangible class items will be prioritized into the input queue based
on an agreed mechanism such as democratic voting and will typically
be selected based on their intangible business value.
Intangible class items will be pulled through the system in an ad hoc
fashion. Team members may choose to pull an intangible class item
regardless of its entry date so long as a higher class item is not
available as a preference.
Intangible class items will queue for release when they are complete
and ready for release. They will be released in the next scheduled
release.
No estimation will be performed to determine a level of effort or flow
time.
Intangible class items may be analyzed for size. Large items may be
broken down into smaller items. Each item may be queued and
flowed separately.
Typically, the preference would be to put aside an intangible class
item in order to process an expedite request.
It is therefore sensible and shows a good spread of risk when
intangible class items are flowing through the system.
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Use Color to de-lineate class of service and allocate capacity across classes to manage risk
5 4 43 2 2
Adapted from design courtesy Olav Maassen QNH
= 20 total
Allocation
10 = 50%
...
1 = 5%
4 = 20%
6 = 30%
Input
Queue
Dev
Ready In Prog DoneDoneIn Prog
DevelopmentAnalysis Build
Ready Test
Release
Ready
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Exercise 3 – Classes of service
Take 15 minutes
Same groups as before
Discuss the different classes of service that might apply
Draw some example cost of delay curves
Show how cost of delay is driving your choice of classes of service
Define policies for processing each classes of service
Decide how to visually communicate classes of service note that class of service should be
unambiguous from work item type
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Kanban tickets hold a lot of information that enable decentralized control and local decision
making when deciding priority of items to pull through the system
Electronic ID number
Date Accepted – clock
starts on SLA
Signifies item that has exceeded
SLA – indicates that item should be
prioritized if possible
Hard delivery date –
for regulatory, legal, or
strategic reasons
Issue attached to
change request –
indicates management
attention required
Assigned engineer
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Exercise 4 – Design Work Item Tracking Card
Take 15 minutes
Same groups as before
Collaborate
Design the layout of a kanban wall card
What information will you and the team need in order to adequately self-organize and flow work through the system
Ask Questions – you don’t know everything you need to know to complete the exercise! For example, how will pull prioritization
be decided?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
WIP limits should be set based on policies and empirically adjusted up/down over time
WIP Limit – defined
via policies
tuned to organizational
maturity
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Examples of WIP Limit Policies
Each person should work on no more than 2
items at a time
Hence, limit = number of people x 2
Prioritization cadence and coordination
meeting will be once per week
Hence, input queue must be large enough for one
week of pull
Mathematically, input queue should be 3 sigma
upper control limit of mean throughput (rate of pull)
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
General Observations about Kanban Limits
Lower limits are better
Less work-in-progress (WIP)
Lower cycle times
More agile
More value delivery
Tight lower limits inflict pain on the
organization
Tight limits will cause work to stall (no flow)
Requires good skill in issue management &
resolution (impediment removal)
Requires capability in root cause analysis and
resolution
Lower maturity organizations should have
looser limits
Higher maturity organizations tighter limits
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Kanban limits can be grouped across work columns and queues (or buffers)
Kanban Limit – of 4
for analysis and
analysis complete
queue
Kanban Limit – similar
policy for development
and development
complete
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Exercise 5 – Setting Kanban Limits
Take 15 minutes
Same groups as before
Collaborate
Discuss policies for queues
Discuss policies for work columns
Discuss organizational maturity
Set limits according to agreed policies and maturity
Ask Questions – you don’t know everything you need to know to complete the exercise! For example, would separating out
different sizes of work item, allow us to reduce queue sizes?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Scaling Kanban
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Major Project with two-tiered kanban board using swim lanes for feature sets
Swim lanes control WIP limit –
Requirement WIP (green)
controlled by number of lanes
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Small generalist team assigned to each swim lane responsible for feature breakdown and flow
Feature Team – names of team
members assigned to swim lane
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Cross-functional resources are shown with small orange tickets attached to features
Shared resources – e.g.
enterprise data architect
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Handling Cross-team Dependency
Tag Work Items with Shared
Resource Dependency Clearly mark as impeded
Provides visibility onto the problem
Provide shared resource with separate
Kanban board/system Allow several sources of dependency to compete
for scarce resource
Treat Integration Items as Fixed Date class of
service
Base fixed date on agreed integration point
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
End of Day 1 Retrospective
Take 5 minutes
From today’s tutorial, what have you learned?
What questions do you have for tomorrow?
Where do you believe Kanban would be useful?
In what situations might Kanban be inappropriate or sub-optimal to implement? Why?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Models(to identify improvement
opportunities)
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
3 Sources of Improvement
Manage Bottlenecks
(improve flow, deliver more value)
Improve Economic Costs
(reduce waste/overheads)
Reduce Variability
(Chance & Assignable Cause)
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Economic Costs(waste identification)
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
What is efficiency?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
What’s the most efficient way to paint a fence?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Focusing on efficiency produces better cost accounting results for large batch sizes
Task Wait
CleanupSetup
Q
Time
Task WaitQueue
Task WaitQueue
Task WQueue
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Because the transaction costs (in this case, the setup and cleanup)
can be amortizedover a greater number of value items
(in this case, painted sections of fence)
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
But there are also coordination costs in knowledge work problems
Task Wait
CleanupSetup
Q
Time
Task WaitQueue
Task WaitQueue
Task WQueue
Communication
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
And in knowledge work problems, coordination costs grow non-linearly with batch size
Task Wait
CleanupSetup
Q
Time
Task WaitQueue
Task WaitQueue
Task WQueue
Communication
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
The prevailing paradigm in Western management was that overheads
(transaction and coordination costs) were inevitable and efficiency was
achieved through economies of scale(i.e. large batch sizes)
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Sources of Waste
Transaction Costs
Coordination Costs
Failure Load
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Waste is Waste
Thinking of startup,
coordination and delivery
tasks as “waste” is
perplexing for most
knowledge workers. Call
them “costs” instead
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Value-added Work
Tra
nsacti
on
Co
sts
Coordination Costs
Failure LoadTra
nsacti
on
Co
sts
time
co
st
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Good
Bad
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Sources of Economic Costs
Transaction Costs
Coordination Costs
Failure Load
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Exercise 6 – Cadence
Take 15 minutes
What’s the correct release cadence for your kanban system?
What are the transaction costs of a release? (training, deployment, governance) and the lead times involved (e.g. training lead time)?
What is the appropriate input / prioritization cadence?
How quickly are things changing? (in the business)
If you reduce waste how might this affect cadence?
Does it make sense for release cadence and prioritization to be the same?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Exercise 7 – Economic Cost Identification
Take 15 minutes
Same groups
Identify transaction costs in your project work
Identify coordination costs
How much of the total effort on projects, do you estimate is transaction or coordination costs (rather than value-added) effort?
Estimate Failure load – internal (bugs) and external (escaped) sources
Draw a sketch of economic cost model based on data
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Focus on Quality(Reduce Failure Load)
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Too much WIP increases defect rates in a non-linear fashion
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Defects have an opportunity cost
Blue tickets are defects –defects increase WIP, reduce the team’s ability to work on valuable new features and lengthen lead time
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Quantity of blue tickets on the board is an immediate indicator of development quality that is
impeding flow of customer valued work and reducing throughput
Engineering Defects – direct
indicator of quality impact on
productivity
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Defects have an opportunity cost
In turn defects increase WIP, lengthen lead
times and may result in yet more defects
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Track WIP!WIP is directly related to Lead Time and Quality
Device Management Ike II Cumulative Flow
0
20
40
60
80
100
120
140
160
180
200
220
240
10-F
eb
17-F
eb
24-F
eb
2-M
ar
9-M
ar
16-M
ar
23-M
ar
30-M
ar
Time
Fe
atu
res
Inventory Started Designed Coded Complete
WIP
Lead Time
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Too much WIP, 3 month lead time led to a 30x reduction in quality compared to 1 week
lead time
Project B Cumulative Flow
0
25
50
75
100
125
150
175
9-O
ct
23-O
ct
6-N
ov
20-N
ov
4-D
ec
18-D
ec
1-J
an
15-J
an
29-J
an
12-F
eb
26-F
eb
11-M
ar
Time
Fe
atu
res
Inventory Started Designed Coded Complete
Lead Time
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Defects have an opportunity cost
In turn defects increase WIP, lengthen lead
times and may result in yet more defects
Too much WIP increases complexity and
adds additional communication overhead
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Defects have an opportunity cost
In turn defects increase WIP, lengthen lead
times and may result in yet more defects
Too much WIP increases complexity and
adds additional communication overhead
By far the easiest way to increase throughput and
reduce lead time is to focus on quality
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Focus on Quality
• Measure, Track and Manage WIP
• Employ policies to minimize defects– Design and Code reviews
– Static and Dynamic Code Analysis
– Test-first development
– Automated unit tests
– Continuous integration
– Formal system testing by professional testers
– Develop and test in small batches
– Provide developers with defect feedback as early
as possible and as often as possible
– Enforce as much quality discipline with your
configuration management tool as possible
• E.g. no check-in without passing unit tests
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Exercise 10 – Policies for Quality
Take 15 minutes
What policies might you set to positively affect quality?
How will these policies affect workflow?
Will kanban limits have to be adjusted?
Which policies might be overridden when required?
Can quality policies be related to classes of service?
Ask Questions – you don’t know everything you need to know! For example, how should defects be
handled in the workflow?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Manage Bottlenecks
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Manage bottlenecks to increase productivity
1. Identify - Current CCR is System Test – 30 per month2. Exploit - Testers relieved of all non-essential tasks, extra
PMs assigned to complete administrative tasks, analysts assigned to future test plans
3. Subordinate - Requirements release restricted to ~30 per month
4. Elevate - Plan to recruit temporary testing staff immediately
Idea Analysis Design Code
Unit
Test
System
Test
Acceptance
Test
Working
Code
ErrorErrorError
~90 ~80 ~50 ~50
~80 ~30 ~50
Schedule
Quality
Schedule
Quality
~40How do I trim 25% off the schedule for
a project going through this system?
Known max productivity
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Iteration 1 Burndown
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Iteration 1 Cumulative Flow
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Burndownversus Cumulative Flow Comparison
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Cumulative Flow
CR Only CR, Bugs and PDUs
WIP growth due to additional
resource allocation (good) and
some sloppy management of
kanban limits (bad)
Business
encouraged to
re-triage backlog
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Non-instant Availability
Looks like a bottleneck
Same thinking process applies
Management approach is similar but policies
will be different depending on type of
bottleneck CCR vs NIA
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Exercise 6 – Bottleneck Management
• Take 15 minutes
• Same groups as before
• Where do you think there are bottlenecks in your workflow?
• Is it a CCR or an NIA type bottleneck?
• What actions would you take to maximize the utilization of your bottleneck resource?
• What policies are required to subordinate everything else to your exploitation decision?
– What policies would you remove or change?
– What new policies must you introduce?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Understanding Variability
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
How do event planners do it?
Scheduling Wimbledon isn’t an exact science
Games last different lengths of time and weather conditions can stop play altogether but the Men’s
Final always happens on the 2nd Sunday
If only we could project manage like this!
Wimbledon comes in on time every year
Except 2004 when it rained on Sunday and
the final was on Monday ;-)
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Where is the constraint now?
1. Variability – variation in Design, Code or Unit Test can move the constraint
2. Plan Insecure – Plan based on System Test as CCR is insecure
3. Reduce Variability – Change methods in Design, Code & System Test to reduce variability
4. CCR has Narrowest Variability – System Test as CCR should have narrowest variability
Idea Analysis Design Code
UnitTest
SystemTest
AcceptanceTest
WorkingCode
ErrorErrorError
~90+-10 ~80+-20 ~50+-10 ~50+-10
~80+-10 ~40+-15 ~50+-5~40+-5
~50+-5 ~50+-5
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Quantity of pink issue tickets on board directly indicates flow impacting problems that need
attention from management
Issues are the exception –
attached to work items that are
blocked for external reasons and
call attention to problems
preventing smooth flow
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Issue Management Cumulative Flow
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Exercise 7 – Classifying Variability
Take 15 minutes
Same groups as before
List the policies under your control that affect the time taken to complete value-added work e.g. Code Inspections, Customer
Review
What levers can you pull and how might they affect risk? e.g. removing code inspections
List typical events out of your control that randomize your plans and schedules
What actions might you take to mitigate the effects of these external events Can classes of service be used to help
with risk mitigation?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Kaizen Culture
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Map the value stream and track work on a white board
Hold a standup meeting every day in front of the board
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
… or create an application that looks like a whiteboard but provides the archival advantage of an electronic
system
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Kanban uses a daily standup meeting as a central enabler of a Kaizen
culture
In this example more than 40 people
attend a standup for a large project
with 6 concurrent development
teams. The meeting is usually
completed in approximately 10
minutes. Never more than 15.
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Manage quantitatively and objectively using only a few simple metrics
• Quality
• WIP (work-in-progress)
• Lead time (against target and DDP)
• Issue & Blocked Work
• Throughput
• Cycle Time Efficiency
Across these:
Trend
Variation
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Hold a monthly Operations Review and present all the data, invite anyone
who wants to come
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Kanban sets an expectation of High Maturity
Root cause analysis on
defects
“stop the line”
CAR
Kaizen events
OID
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Educate the workforce to recognize process problems that
affect performance
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Look how the board has changed by March! Empirically adjusted Kanban limits reacting to
industrial engineering issues. Much neater presentation – pride in the process is forming
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
And again in April, more changes to Kanban limits and forward extension of the process to business analysis
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Waste bin spontaneously introduced by team to visually communicate rejected CRs that wasted energy and
sucked productivity
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
A report was created to detail rejected or cancelled work items (muda)
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Kanban has allowed us to observe known industrial engineering issues
Expediting impacts throughput and lead time
Tends to increase WIP
Overly large CRs cause ragged flow, blow out lead time
Larger variation in CR size has required larger queues and buffers – extending lead time
Non-constraints exhibit ragged flow behavior due to non-instant availability
e.g. integration build
Bottlenecks create ragged flow (e.g. Test) but also experience idle time from upstream ragged flow from non-instant availability stations (e.g. Build)
Big items are now broken up, temporarily breaks the Kanban limit but pull system means no new items enter WIP until overflow is depleted. Result is smoother flow even with big items
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Spontaneous Quality Circles started forming
Kanban board gives visibility into process issues –ragged flow, transaction costs of releases or transfers through stages in process, bottlenecks
Daily standup provides forum for spontaneous association to attack process issues affecting productivity and lead time
For example, 3 day freeze on test environment was a transaction cost on release that caused a bottleneck at “build” state. This was reduced to 24 hours after a 3 person quality circle formed to investigate the policies behind the freeze. Result was improved smooth flow resulting in higher throughput and shorter lead time
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Other spontaneous quality circle kaizen events
Empirically adjusted kanban limits several times E.g. test kanban too small, causing ragged flow
UAT state added Prompted by test who were experiencing slack time
Expanded kanban limit on Build Ready state, added Test Ready state Introduced to smooth flow post release due to
environment outage transaction cost
Introduced kanban board, daily standup, colored post-it notes for different classes of service, notations on the post-its
Poor requirements causing downstream waste resulted in an upstream inspection to eliminate issues with poorly specified requests
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
In general, empirical observation of ragged flow or visibility of waste generates a quality circle resulting in a
kaizen event
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
September 2007 – Business Analysis and Systems Analysis merged eliminating 25% of lead time consumed
as queuing waste
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
And the process spread inside Corbis …
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
And externally at companies like Yahoo! …
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
… this one on the Mash social network team
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
And the technique is being introduced to major projects with much longer time horizons. This example has a
monthly “integration event” rather than a release every two weeks
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
5 months later significant changes are evident
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Major project with two-tiered kanban board
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Major Project with two-tiered kanban board using swim lanes for feature sets
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Less mature major project in trouble adopts kanban to bring a focus to daily routine and visibility to work-in-
progress to team and management
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Next Day – Team is maturing quickly and has refactored the board with swim lanes for functional areas
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
More and more reports were demanded to facilitate management decisions. In this case, new reports to
facilitate weekly prioritization
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Completed items are collected on the wall to the right hand side of the board. Visual indicator of cumulative total
of value delivered
Management instituted
a “bottle tops” saving
scheme where
completed items are
“traded” against morale
events to celebrate
success
E.g. movie tickets,
bowling evening, trip
to Gameworks
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Executive Dashboard
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Mean Lead Time Trend
Mean Lead Time Trend
0.0
10.0
20.0
30.0
40.0
50.0
60.0
Dec Jan Feb Mar Apr May
Da
ys CRs
Bugs
Combo
SLA
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Due Date Performance Detail
Lead Time Distribution
0
0.5
1
1.5
2
2.51 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
101
106
Days
# C
Rs
MARCH
Lead Time Distribution
0
0.5
1
1.5
2
2.5
3
3.5
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99106
113120
127134
141148
Days
CR
s &
Bug
s
APRIL
Outliers
Majority of CRs range 30 -> 55
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Exercise 12 – Metrics
Take 15 minutes
What metrics would you track?
Who is the audience for the metrics?
Can you identify day-to-day (leading indicator) metrics used for management intervention?
Versus weekly, monthly, quarterly (lagging indicator) metrics used for executive reporting, customer satisfaction and assessment of continuous improvement?
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Summary
Culture Change Trust, empowerment, objective data measurement,
collaborative team working and focus on quality
Policy Changes Late-binding release scope, no estimating, late-
binding prioritization
Cycle time, Release Cadence and Prioritization Cadence are decoupled
Cross-functional collaboration Previously unheard of VP level selfless
collaboration on business priority
Self-regulating process robust to gaming and abuse
Continuous Improvement Increased throughput, high quality, process
continually evolving, kanban limits empirically adjusted
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
And finally, staff take a pride in their achievements
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Day 2 Retrospective – What will you change?
Take 5 minutes
What have you learned today?
What one thing will you implement as a change in your organization when you get back to the office this week?
How far do you think Lean/Kanban can take your organization?
Take 5 minutes to discuss your results and share with the group
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
Thank you!
http://www.agilemanagement.net/
Ma
na
ge
me
nt C
on
su
lting
for K
no
wle
dg
e W
ork
ers
Da
vid
J. A
nd
ers
on
& A
ss
oc
iate
sK
anb
an
2010
About…David Anderson is a thought leader in managing effective software teams. He leads a consulting firm dedicated to improving economic performance of knowledge worker businesses – improving agility, reducing cycle times, improving productivity and efficiency in technology development.
He has 25+ years experience in the software industry starting with computer games in the early 1980’s. He has led software teams delivering superior productivity and quality using innovative agile methods. He developed MSF for CMMI Process Improvement for Microsoft. He is a co-author of the SEI Technical Note, CMMI and Agile: Why not embrace both!
David’s book, Agile Management for Software Engineering – Applying the Theory of Constraints for Business Results, introduced many ideas from Lean and Theory of Constraints into software engineering.
David was a founder of the Lean Software & Systems Consortium, a not for profit dedicated to promoting better standards of professionalism and effectiveness in software engineering. Email… [email protected]