This document discusses techniques for delivering predictability with Kanban for different types of work like software maintenance and major projects. It recommends creating a regular delivery cadence, strong configuration management, and deployment capability for service work. For major projects, it suggests understanding peak throughput, modeling work completion with an S-curve, treating lead time as fixed, and using Little's Law to set WIP limits and staffing. The document also provides examples of modeling major project workflow and allocating capacity across classes of service.
Call Girls Zirakpur👧 Book Now📱7837612180 📞👉Call Girl Service In Zirakpur No A...
Key Note - Lean Kanban Central Europe 2011 - Predictability & Measurement with Kanban
1. Predictability & Measurement
with Kanban
Lean Kanban
Central Europe
Munich October 2011
David J. Anderson
David J. Anderson & Associates
dja@djandersonassociates.com
6. Create a regular delivery cadence
Develop a strong config management capability
Develop capability to deploy effectively
Build code with high quality
Advanced
Kanban
7. Understand capability by studying the natural
philosophy of the work
MARCH
Lead Time Distribution
2.5
# CRs
2
1.5
1
0.5
106
101
96
91
86
81
76
71
66
61
56
51
46
41
36
31
26
21
16
11
6
1
0
Days
Lead Time Distribution
APRIL
3.5
Majority of CRs range 30 -> 55
2
Outliers
1.5
1
0.5
Days
8
14
1
14
4
13
0
3
6
7
12
12
11
10
99
92
85
78
71
64
57
50
43
36
29
22
15
8
0
1
CRs & Bugs
2.5
Advanced
Kanban
3
8. For standard class items, offer a target lead time
based on the 2nd confidence interval
Advanced
Kanban
10. 51 days will not be good enough for some
feature requests, so offer a package of classes of
service
Advanced
Kanban
11. Package of Classes with SLAs
As soon as possible
100% on-time
providing 24 days advance notice
Up to 51 days
98% on-time guarantee
Up to 51 days
50% on-time
Advanced
Kanban
Full transparency
12. Lead time
Standard Class Items
Fixed Date Items
Advanced
Kanban
Expedite Item
Features Delivered
13. Allocate capacity across classes of service in
order to deliver against anticipated demand
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
4 = 20%
10 = 50%
6 = 30%
Advanced
Kanban
+1 = +5%
14. John Seddon has observed that
allocating capacity in this fashion
“damages capacity”!
While this is theoretically possible it will almost
never happen because
(a) a simple policy can be implemented to
temporarily re-allocate
(b) demand is rarely zero for a given type, though
Fixed Date class of service can be seasonal
Advanced
Kanban
(c) the tickets represent work, not workers, the
workforce is flexible. Classes of service &
capacity allocation insure people can keep busy
improving utilization not damaging it
18. Cumulative Flow and
Predictive Modeling with S-Curve
Time
Inventory
Started
Designed
Coded
Complete
30
-M
ar
23
-M
ar
16
-M
ar
9M
ar
2M
ar
eb
24
-F
17
-F
eb
Typical S-curve
Advanced
Kanban
eb
240
220
200
180
160
140
120
100
80
60
40
20
0
10
-F
Features
Device Management Ike II Cumulative Flow
19. Simulating S-Curve with a Z
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
24
-F
eb
20%
eb
17
-F
eb
60%
Advanced
Kanban
240
220
200
180
160
140
120
100
80
60
40
20
0
10
-F
Features
Device Management Ike II Cumulative Flow
20. Track actual throughput against projection
Time
Inventory
Started
Designed
Coded
Complete
30
-M
ar
23
-M
ar
16
-M
ar
9M
ar
2M
ar
eb
24
-F
17
-F
eb
Track delta between
planned and actual
each day
Advanced
Kanban
eb
240
220
200
180
160
140
120
100
80
60
40
20
0
10
-F
Features
Device Management Ike II Cumulative Flow
22. Make a long term plan to build
platform replacement
Device Management Ike II Cumulative Flow
Time
Inventory
Started
Designed
Coded
Complete
2008
30
-M
ar
23
-M
ar
16
-M
ar
5x
9M
ar
2M
ar
eb
24
-F
eb
2006
17
-F
eb
Slope in middle
3.5x - 5x slope
at ends
Advanced
Kanban
240
220
200
180
160
140
120
100
80
60
40
20
0
10
-F
Features
Required throughput (velocity)
23. We need average throughput (velocity) to peak
at 13 features per month over 24 months.
Advanced
Kanban
24. Little‟s Law
Determines staffing level
Target to achieve plan
Throughput
=
WIP
Lead Time
Treat as Fixed variable
Advanced
Kanban
From observed capability
25. 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
Advanced
Kanban
26. Plan based on currently observed
capability and current working
practices. Do not assume process
improvements.
Advanced
Kanban
If changing WIP to reduce
undesirable effects (e.g.
multitasking), get new sample data
(perform a spike) to observe the
new capability
27. Little‟s Law
Determines staffing level
Target to achieve plan
13 / month
=
WIP
0.25 months
If current working practice is 1 unit WIP per
person then 3 people are needed
Advanced
Kanban
WIP = 3.25, round up to 4.
Might be safe to
From observed capability
round down to 3.
28. Slightly over-allocate the intangible class of
service (green) to compensate against expediting
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
4 = 20%
12 = 60%
4 = 20%
Advanced
Kanban
+1 = +5%
30. For Service-oriented work, create
predictability with
a regular delivery cadence
a strong config management capability
capability to deploy effectively
code with high quality
For major projects
Advanced
Kanban
understand peak throughput (velocity)
model the s-curve on work complete
treat the avg. lead time as the fixed variable
use Little‟s Law to calculate WIP limits
and staffing levels
32. 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 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
Advanced
Kanban
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.