Understanding variability in typical knowledge work activity such as software development. Planning large projects using probabilistic forecasting and modeling. Implementing with Kanban. Presented privately in Lisbon, Portugal, adapted from a key note at OOP 2012 the same month

1. Kanban at Scale
and why traditional approaches set
you up for failure
NSN
Lisbon
January 2012
David J. Anderson
David J. Anderson & Associates
dja@djaa.com
Twitter @agilemanager

2. Book Published
April 2010
Kanban
2012
A 72,000 word
intro to the topic

3. Portuguese (Brazilian)
published October 2011
Kanban
2012
Translation by
Andrea Pinto
Recife, Brazil

4. Published in Spanish
9th May 2011
Kanban
2012
Translated by
Masa K Maeda, PhD

5. Kanban on Big Projects
Estimating and planning, tracking,
managing & reporting
Kanban
2012

6. 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
Kanban
2012

7. Kanban daily standup meetings can
be very large
Kanban
2012
In this example more than 40 people
attend a standup for a large project
with 5 concurrent development
teams. The meeting is usually
completed in under 15 minutes

8. Observe Flow with a CFD
Avg. Lead Time
Time
Inventory
Started
Designed
Coded
Complete
30
-M
ar
23
-M
ar
16
-M
ar
9M
ar
Avg. Throughput
2M
ar
eb
24
-F
17
-F
eb
WIP
Kanban
2012
eb
240
220
200
180
160
140
120
100
80
60
40
20
0
10
-F
Features
Device Management Ike II Cumulative Flow

9. Little‟s Law
Throughput
=
WIP
Lead Time
Kanban
2012

10. Observe Flow with a spectral analysis histogram
of lead time
Lead Time Distribution
3.5
3
CRs & Bugs
2.5
2
1.5
1
0.5
1
4
7
0
3
6
8
14
14
13
12
12
11
10
99
92
85
78
71
64
57
50
43
36
29
22
8
15
1
0
Days
SLA expectation of
44 days with 85% on-time
Kanban
2012
Mean of
31 days
SLA expectation of
51 days with 98% on-time

11. Cumulative Flow and
Predictive Modeling with S-Curve
Inventory
Started
Designed
Coded
Complete
30
-M
ar
23
-M
ar
16
-M
ar
9M
ar
2M
ar
eb
Time
Kanban
2012
24
-F
eb
Typical S-curve
17
-F
eb
240
220
200
180
160
140
120
100
80
60
40
20
0
10
-F
Features
Device Management Ike II Cumulative Flow

12. Simulating S-Curve with a Z
60%
Slope in middle
3.5x - 5x slope
at ends
5x
20%
Time
Inventory
Started
Designed
Coded
Complete
30
-M
ar
23
-M
ar
16
-M
ar
9M
ar
2M
ar
eb
24
-F
eb
20%
Kanban
2012
17
-F
eb
240
220
200
180
160
140
120
100
80
60
40
20
0
10
-F
Features
Device Management Ike II Cumulative Flow

13. Track actual throughput against projection
Inventory
Started
Designed
Coded
Complete
30
-M
ar
23
-M
ar
16
-M
ar
9M
ar
2M
ar
eb
Time
Kanban
2012
24
-F
eb
Track delta between
planned and actual
each day
17
-F
eb
240
220
200
180
160
140
120
100
80
60
40
20
0
10
-F
Features
Device Management Ike II Cumulative Flow

14. Variability in Throughtput (velocity)
It is important to understand the role throughput
plays in long term planning in Kanban but why it
is not useful for short-term goal setting
Often velocity exhibits a +/-2x spread of variation
As a result velocity cannot be used as a shortterm planning tool
See following examples
Kanban
2012

15. Velocity Variation
Kanban
2012
South African Team from 2011plotted per Sprint (2 weekly)
Mean 29, UCL (+1 sigma) 43 (+1.5x), LCL (-1 sigma) 15 (- 2x)

16. DBA Team Velocity
90
80
Trend
70
60
50
Total Velocity
Small support tasks
40
30
Trend
20
10
(not included
in total velocity)
Week of Christmas
Mattias Skarin client based in Paris in 2009/2010, plotted weekly
Mean 42, +1 sigma = 55, -1 sigma = 29 (+/- 1.4x)
Kanban
2012
0

17. Kanban
2012
Investment Bank, London, Extreme Programming
Weekly Mean 10, Max = 16, Min = 6
Spread (+/- 1.6x)

18. Velocity Control Charts
Completion Velocity Chart
40
UCL
30
29.2
Completion Velocity
20
Completion
Velocity
UCL
10
CL
+2
7.206896552 Sigma
+1 Sigma
0
-10
1
2
3
-14.8
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Date
Motorola PCS 2003, FDD project plotted
Daily Mean 7.2, +1 sigma = 15, -1 sigma = 0 (+/- 2x)
Weekly Mean 36, +1 sigma = 63, -1 sigma = 11 (+ 1.7x, -3.3x)
Kanban
2012
-20
LCL

19. Variability in scope/requirements
It is also important to realize how much variability
there is in the scope/scale or requirements
and how this must be accommodated in our plans
Kanban
2012

20. Unplanned Work Report
Scope Creep
Dark Matter
(emergent features)
Original Scope
Kanban
2012
Dark matter planned as a 19% expansion over original scope
Actual Dark Matter over final original scope is 26%
Total scope compared to original commitment is 13% greater

21. Typical Agile teams using User Stories analysis
produce 40-60% dark matter
Stories are recognized as Epics and broken into
more stories.
The customer does not consider the scope to
have changed
Kanban
2012

22. TV/Movie Company in USA 2008
Kanban
2012
Initial Scope is 125 story points
Within days this total scope reaches 190 due to dark matter expansion
Management intervened on 4/21 to stop dark matter (deferring future scope
to product backlog)
Observed dark matter expansion is 52% but real number was much greater

23. Original CFD shows same top line
Dark matter quotient is 19%
Inventory
Started
Designed
Coded
Complete
30
-M
ar
23
-M
ar
16
-M
ar
9M
ar
2M
ar
eb
Time
Kanban
2012
24
-F
eb
Track delta between
planned and actual
each day
17
-F
eb
240
220
200
180
160
140
120
100
80
60
40
20
0
10
-F
Features
Device Management Ike II Cumulative Flow

24. Make a long term plan to build
platform replacement
Device Management Ike II Cumulative Flow
2008
30
-M
ar
23
-M
ar
16
-M
ar
9M
ar
2M
ar
5x
Kanban
2012
24
-F
eb
2006
eb
Slope in middle
3.5x - 5x slope
at ends
17
-F
eb
240
220
200
180
160
140
120
100
80
60
40
20
0
10
-F
Features
Required throughput (velocity)
During the middle 60% of the project schedule
Time
we need Throughput (velocity) to average 220
Inventory Started Designed Coded Complete
features per month

25. Little‟s Law
Determines staffing level
Target to achieve plan
Throughput
=
WIP
Lead Time
From observed capability
Kanban
2012
Treat as Fixed variable

26. Changing the WIP limit without
maintaining the staffing level ratio
represents a change to the way of
working. It is a change to the
system design. And will produce a
change in the observed „common
cause‟ capability of the system
Kanban
2012

27. Plan based on currently observed
capability and current working
practices. Do not assume process
improvements.
If changing WIP to reduce
undesirable effects (e.g.
multitasking), get new sample data
(perform a spike) to observe the
new capability
Kanban
2012

28. Little‟s Law
Determines staffing level
Target to achieve plan
55 / week
WIP
=
0.4 week
WIP = 22, round up to 25.
5 teams, 5 per team
If current working practice is 1 unit WIP per person
then 5 people are needed to per team
Kanban
2012
From observed capability

29. 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
Kanban
2012

30. Alt Exercise – Reviewing Kanban System Design









Lanes, colors, ticket designs, decorations
Decide capacity allocation and how
it might vary dynamically over time
Kanban
2012
Take 20 minutes
Draw some example cost of delay
curves for features/projects
Do any patterns/clusters emerge?
Discuss classes of service each
type of delay curve
Discuss other categorization
schemes that might be useful
Discuss risk profiles in those
schemes
Decide how to visualize several
dimensions of risk profile

31. http://leankanbanuniversity.com
http://www.limitedwipsociety.org
LinkedIn Groups: Software Kanban
Yahoo! Groups: kanbandev
Yahoo! Groups: kanbanops

32. Kanban
2012

33. Cost of Delay
Kanban
2012

34. Typical lead time
Impact
Cost
Impact
Cost
Cost of Delay for Expedite Items
t t
t t
(b) Steep immediate
(a) Regulatory fine
impact / benefit
within bound of usual
lead time window
Kanban
2012

35. Impact
Cost
Impact
Cost
Cost of Delay for Fixed Date Items
t t
(a) Regulatory Fine
Typical lead time
Kanban
2012
t t
(b) Inability to trade
or, denial of capability
on a fixed date in the
future

36. Cost of Delay for Standard Items
Expedite Item
Typical lead time
Impact
Cost
Impact
Cost
Standard Item
t t
Shallow slope, immediate or
delayed impact / benefit
t
t
Kanban
2012
Both slope and length of delay
before impact will factor in
selection decisions
Standard Item

37. Room Nights
To understand the
opportunity cost of delay sketch
market payoff functions
Cost of delay function for an online Easter holiday marketing
promotion is difference in integral under two curves
Kanban
2012
Desired Release Date

38. impact
Cost of 1 Month Delay based on
Market Payoff Sketches
Treat as a Standard Class item
Linear
approximation
time
Kanban
2012
Cost of delay function for an online Easter holiday marketing
delayed by 1 month from mid-January (diff of 2 integrals)

39. Exercise – Alternative Project



Consider a Valentine‟s Day
promotion
Sketch the market payoff function
Now compare the Easter project
with the Valentine‟s Day project
under a risk of a 1-month delay
Kanban
2012

40. Typical lead time
Impact
Cost
Cost of Delay for Intangible Items
Intangible Item
0
t t
Flat line – no impact
within foreseeable lead
time window
Kanban
2012

41. Impact
Intangible class items are still important
This is the cost of delay function is typical of
Platform replacements
Legacy code replacements
Major green-field (v1.0) projects
Expedite Item
Fixed Date Item
Standard Item
Intangible Item
2005
2006
2007
2008
2009
Cost of delay changes over long period of time
2010
Kanban
2012
0

42. Exercise – Project Cost of Delay



Determine the factors that affect
cost of delay - $$$, politics,
regulation, competitive landscape
Sketch the cost of delay function for
each factor
From this information narrow down
a desired delivery date or range of
delivery dates
Kanban
2012

43. Kanban System
Design Examples
Kanban
2012

44. Swim lanes are used to de-lineate types.
Capacity is allocated across lanes
5
Allocation
Total = 20
4
Analysis
Input
Queue In Prog Done
3
4
Development
Dev
Ready In Prog Done
2
Build
Ready
2
Test
= 20 total
Release
Ready
...
Change Req
12
Production Defect
6
Kanban
2012
Maintenance
2

45. Color de-lineates class of service. Allocate
capacity across classes
5
4
Analysis
Input
Queue In Prog Done
3
4
Development
Dev
Ready In Prog Done
2
Build
Ready
2 = 20 total
Test
Release
Ready
...
Allocation
+1 = +5%
10 = 50%
6 = 30%
Kanban
2012
4 = 20%

46. “Split Column for
Concurrent Activities”
5
2
4
4
2
4
Analysis
Input
Queue In Prog Done
Dev
In Prog
Done
Test
Ready
Test
Release
Ready
...
Combine
4
Split
Test Dev
In Prog
Kanban
2012

47. “Open Column for
Multiple Unordered
Activities”
5
4
Analysis
Input
Queue In Prog Done
In Prog
2
Done
Test
Ready
2
Test
Release
Ready
...
Kanban
2012
UI Design
Security
Persistence
Biz Logic
8

48. “Split Column for
Multiple Unorderd
Activities”
5
4
Analysis
Input
Queue In Prog Done
2
4
In Prog
UI Design
Done
Test
Ready
2
Test
Release
Ready
...
Security
Req Done
Business
Logic
Kanban
2012
UI Design
Security
Persistence
Biz Logic
Persistence

49. Classification by
Requirement Market Risk of
Change
Kanban
2012

50. Requirement Type by Market Role
•
Table Stakes
–
–
–
•
Differentiators
–
–
•
Drive customer choice/selection
Drive profits
Spoilers
–
Spoil a competitors differentiators
Cost Reducers
•
Reduce cost to produce, maintain or service and
increase margin
Kanban
2012
•
Undifferentiated
Commodities
“must have”

51. Market Risk Varies by Requirement Type
Make
Highly likely
Agile/Lean
to change
Misdirector – differentiator
not aligned with strategic plan
Spoiler
Cost Saver
Regulatory – must have but
subject to change
Kanban
2012
Table Stakes
Buy/Reuse Very unlikely
Traditional? to change
Value
Market Risk
Engineering
Differentiator

52. Kanban board with requirement type allocated by
swim lane
5
Allocation
Total = 20
Input
Queue
4
Analysis
In Prog Done
3
Dev.
ready
4
2
Development
In Prog
Done
Build
ready
2= 20 total
Test
Table Stakes
10
Cost Reducer
2
Differentiator
6
Kanban
2012
Spoiler
2

53. Example of capacity allocation by cost of delay
class of service. Large “green” allocation offsets
“unplanned urgent” work
5
4
Analysis
Input
Queue In Prog Done
3
4
Development
Dev
Ready In Prog Done
2
Build
Ready
2 = 20 total
Test
Release
Ready
...
Allocation
+1 = +5%
12 = 60%
4 = 20%
Kanban
2012
4 = 20%

54. Capacity allocation by work item type based
on shaping demand
5
Allocation
Total = 20
4
Analysis
Input
Queue In Prog Done
3
4
Development
Dev
Ready In Prog Done
2
Build
Ready
2
Test
= 20 total
Release
Ready
...
Change Req
12
Production Defect
6
Kanban
2012
Maintenance
2

55. Exercise – Risk Classification Scheme
•
•
•
Take 15 minutes
Same groups as before
Think about ways of classifying risk
for features/requirements in your
projects. Think about…
•
•
•
•
•
•
Consider a capacity allocation
across the risk classification
How would the allocation vary over time
(seasonally, through project lifecycle)
What policies or guidelines would
you give for a class of service for
each category of risk
Kanban
2012
•
•
Architectural/technical risk
Cost of delay risk
Risk of change
Risk in arrival rate
(anticipatable, planned/unplanned)
Aligned with strategic plan (or not)

56. Scaling out with ServiceOrientation
Kanban
2012

57. Dependencies between teams create demand
Product Strategy
Kanban Adoptions Starts Here
Customers
Demand
App
Dev 1
App
Dev 2
App
Dev 3
Demand
Service
Platform Development
Viral Spread
Kanban
2012
Demand

58. Demarkate waiting area(s) for external
dependencies
5
4
3
Analysis
Input
Queue In Prog Done
4
2
Development
Dev
Ready In Prog Done
Build
Ready
2 = 20 total
Test
Release
Ready
...
Waiting on
External
Group
Late against SLA
Kanban
2012
Dots denote clock
ticking on SLA

59. Emergence of Service-Oriented
Organizational Structure

Tag Work Items with Shared
Resource Dependency



Provide shared resource with separate
Kanban board/system



Clearly mark as impeded
Provides visibility onto the problem
Offer SLA and track while waiting
Escalate late items using issue management
system

Base fixed date on planned integration point
Kanban
2012
Treat Integration Items as Fixed Date class of
service

60. Posit Science
Case Study
Kanban
2012

61. Areas of dissatisfaction
Internal Sources
Fragmentation
Tasking – too busy, inaccurate
External Sources
Stories not finished
Deadlines missed
Kanban
2012

62. Transition to “kanban”
– October 2008
BEFORE
AFTER
Iterations
Scrum Master, PO,
Sprint planning
Daily Standup Meeting
Product Owner accepts
Demo
Retrospective
Other
By TASK
By T-SHIRT SIZE
Per Person WIP LIMIT
Kanban
2012
Estimation

63. The sticky board
Limit 3 stories per person
Kanban
2012

64. Stakeholder complaints
Too busy to discuss new work
Not delivering current work
Everything takes too long
Kanban
2012

65. Complaints, per retrospectives
Too much context switching!
Too much work in progress!
Planning is disruptive and cumbersome
Uneven workflow for QA
Massive workload at start of each iteration
Product Owner isn‟t accepting completed stories
Kanban
2012
Priorities from stakeholders are unclear and shifting

66. Goals of new “flow” system
Reduce context switching
Reduce work in progress
Steadier workflow for QA & Deploy
Reduce massive workload at start of each iteration
(balance workload with capability)
Kanban
2012
Clearer priorities from stakeholders

67. Or…
Make flow even
Reduce work in progress
Reduce planning overhead
Make sure the work is important and focused
Hold Product Owner accountable
Kanban
2012

68. Solutions
Better visibility
WIP limits to manage flow
Group and classify work to reduce
Group and classify work to prioritize
Kanban
2012

69. Transition to “flow”
– August 2009
BEFORE
Iterations
AFTER
SLA
Scrum Master, PO
Sprint planning
Triggered, per feature
Daily Standup Meeting
Product Owner accepts
Demo
Calendar
Retrospective
Calendar
Estimation
By STORY
By FEATURE per SLA
More detailed workflow
Other
Workflow WIP LIMITS
Kanban
2012
Other

70. Example Classes of Service
Expedite – pink; critical and immediate cost of
delay; can exceed other kanban limit (bumps
other work); 1st priority - limit 1
Fixed date – orange; cost of delay goes up
significantly after deadline; 2nd priority
Accelerating - yellow; cost of delay goes up
increasingly over time; 3rd priority
Kanban
2012
Standard – blue; cost of delay linear over time;
4th priority

71. Feature Request
Requested by:______________________________________ Date Requested_____________
Feature name__________________________________________________________________
Format: [customer] [action] [purpose]
Description____________________________________________________________
________________________________________________________________________
________________________________________________________________________
Cost of Delay Classification (required)
Check  the type of Feature per the cost of delay.
 Expedite – critical and immediate cost of delay
 Fixed date – cost of delay goes up significantly after deadline….date:_________
 Accelerating - cost of delay goes up increasingly over time
 Standard – cost of delay linear over time
Suggested stories (optional)
Kanban
2012
Provide information on one or more of the following (optional)
 Projected Revenue______________________________________
 Opportunity Cost

Estimated 6 month revenue loss if not implemented_____________________________

Estimated 6 month operating expenses if not implemented_______________________

Estimated cost of man hours or other resources if not implemented_________________

Qualitative Value (customer experience, quality of service, etc)____________________

72. Kanban
2012

73. Kanban
2012

74. Top 10
(features)
Limit 10
Design/
Specify
In Progress
(features into
stories)
(stories and
features)
Limit 3 features Limit 3 features
Accept
Test
(stories)
Limit 3
(stories & Done
Deploy features) (stories &
features)
Limit 2
Limit 5
PO must
review
Backlog
1
(features)
No limit
2
3
EX
Kanban
2012
21-day SLA
for
completing
feature
starts now!

75. Kanban
2012

76. Kanban
2012

77. Kanban
2012

78. Accomplished
Better visibility
WIP limits to manage flow
Group and classify work to reduce
Group and classify work to prioritize
Kanban
2012

79. Accomplished
Only highest priority work in progress
Smoother flow (more predictable)
Easier and accurate planning
Stakeholder collaboration!
Kanban
2012

80. Thank you!
Kanban
2012
dja@djaa.com
http://djaa.com/

81. 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.
Kanban
2012
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… dja@agilemanagement.net

82. Exercise – Context for Change &
Demand Analysis

Define work item types,
think about





Source
Destination
Workflow
Order of Magnitude in Size
For each type of work
analyze demand…


Arrival Rate (seasonal
fluctuations?)
Nature of Demand
(stochastic, burst, seasonal,
batches, chaotic)
Customer Expectations –
demanded class of service
(even if unreasonable)
Describe Sources of
Internal /Team
Dissatisfaction



Variability that
randomizes the process
Prevents work being
delivered on-time, with
good quality etc
Describe Sources of
Customer
Dissatisfaction


Reasons customers are
unhappy / expectations
not met
(or points of customer
conflict)
Kanban
2012



83. Exercise – Identifying initial changes



Take your sources of
dissatisfaction from before
List those that you would
like to design out or fix
Analyze “fix” based on
likelihood of resistance



Prioritize the fixes you
want to make / design
For items that may
meet with emotional
resistance


How might you mitigate
the resistance?
How might you motivate
people with a stronger
emotion in order to
overcome the
resistance?
Kanban
2012

Is the activity core to the
self-image of the individuals
Which roles will resist?
Is the activity a method for
establishing social
hierarchy?


84. Understanding workflow doesn‟t need to be
difficult


Map state changes in work items
States tend to reflect the dominant activity for
discovering knowledge at that stage in the
workflow


E.g. analysis, design, test development, coding,
testing, etc…
Workflow states and their transitions tend to
be far simpler than the value-network of
handoffs between people involved in creating
the work
For example, analysis and design still continue
during development or test activities. The work
would still be considered “in test” even though an
analyst may have been required to provide input
Kanban
2012


85. Exercise – Map the Knowledge Discovery
Process


Sketch the workflow for a few types
of work (any method is acceptable
e.g. Flowchart, Stick man drawing,
Statechart etc.)
Discuss the dominant knowledge
discovery activities performed to
create the work and sequence them



Are there any concurrent activities?
Are there any specialist activities?

Do these affect a subset of work or a
particular type of work
Kanban
2012

List the activities (use verbs)
Does the knowledge discovery activity
span across people/teams and show
collaborations?

86. Exercise – Overcoming Resistance to WIP limit
Introduction

List reasons people might object to
WIP limits. What are they afraid of?



For each emotional resistance…



Write each fear on a sticky note
Are the objections emotional or logical?
How might we mitigate (provide a crutch
for) the resistance?
What stronger emotion might help us
overcome it? How might we design a
visualization to raise awareness
For each logical resistance…

Kanban
2012

What logical argument is needed to
overcome it?
Which body of knowledge is needed? Is
training required?

87. Exercise - Initial Kanban System Design

Design a Kanban System





Types of work & Workflow states
Hierarchy (parent-child)? Dependencies?
Classes of service
WIP Limits / Policies
Ticket Design



Allocate capacity for types/lanes/classes
Visualization




Columns for workflow states?
Rows for types?
Colors for classes of service?
Blockers? Bugs?
People allocation – Lanes? Avatars?
Which areas of dissatisfaction do you
want to raise awareness of?
Kanban
2012


What information is needed to enable
team members to make good quality pull
decisions?