10. An example of a virtual kanban system overlaid on a
software development process
PTC
Eng Mgr
Change PM
Requests Developers Testers
Kanban Kanban
8 cards 8 cards
(3 WIP
5 Queue)
User Acceptance Test
Product Backlog 25 Days
Managers
11. We started visualizing these flows
on white boards and holding
standup meetings in front of it
Provides the 1st (team) level of
process capability feedback
12. WIP limits create a pull system and white
board provides visualization of flow
WIP Limit – regulates
“inventory” at each
stage in the process
Pull
Flow – from Engineering
Ready to Release Ready
13. Queue Replenishment & delivery run on
independently determined cadence
Queue
Replenishment Delivery Cadence
How often can we How often can
reasonably meet with customers (or
business downstream functions)
stakeholders? economically take
delivery?
14. Colors represent
classes of service
Expedite
Fixed Delivery Date
Significant delay incurred on or
from a specific date in near future
Standard Class
(Near) linear cost of delay
beginning immediately
Intangible Class
No tangible cost of delay within
reasonable lead time to delivery
window
15. We discovered that standup meetings
could be scaled to a large size
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 approximately 10
minutes. Never more than 15.
16. Major Project with two-tiered kanban board using swim
lanes for each development team
Swim lanes control WIP limit –
Requirement WIP (green)
controlled by number of lanes
17. Monthly Operations Review using quantitative
measures of capability & demand provides the 2nd
(organization) level of process feedback
30. My motivation for adopting
kanban systems was to
prevent overburdening, & control
variability that affects flow
and encourage an
evolutionary
approach to change
31. In developing the
Kanban Method, a
change management approach that
uses kanban systems to provoke
change, we are enabling the
emergence of Lean
software development in
organizations
33. Kanban is based on 3 principles
1. Start with what you do now
2. Agree to pursue incremental,
evolutionary change
3. Initially, respect current roles,
responsibilities & job titles
34. Then…
then adopt 5 core
practices that are observed
to be present in successful Kanban
implementations
35. 5 core practices for successful
Kanban adoption
Shallow
1. Visualize
2. Limit Work-in-Progress
Depth
3. Manage Flow
4. Make Process Policies
Explicit
5. Improve Collaboratively
(using models & scientific method) Deep
36. It‟s not a question of right or
wrong …
Shallow
It‟s a question of shallow or
deep!
Depth
Shallow implementations
tend to produce fewer, less
dramatic results
Deep
37. When…
When all 5 core practices are adopted
they form the seed conditions for
complex
Kanban as a
adaptive system that
enables a Lean(er) way of working to
emerge
42. Observe Flow with a CFD
Device Management Ike II Cumulative Flow
240
220
200
180
160
Features
140
120 Avg. Lead Time
100
80
60 WIP Avg. Throughput
40
20
0
ar
ar
eb
eb
eb
ar
ar
ar
M
M
-M
-M
-M
-F
-F
-F
2-
9-
10
17
24
16
23
30
Time
Inventory Started Designed Coded Complete
43. From the simple geometry we can observe
Little‟s Law
WIP
Throughput =
Lead Time
From observed capability
45. Observe Flow with a spectral analysis histogram
of lead time
Lead Time Distribution
3.5
3
2.5
CRs & Bugs
2
1.5
1
0.5
0
6
3
0
7
4
1
8
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
10
11
12
12
13
14
14
Days
SLA expectation of
Mean of 51 days with 98% on-time
31 days
SLA expectation of
44 days with 85% on-time
46. Development is a Bottleneck
This is an example of using a
model to identify an
improvement opportunity
52. Without a WIP limit the Idle &
Stuck comments may never
emerge
53. The team has a choice to break
the WIP limit and ignore the
issues, or face up to the issues
and address them using the
models
54. The WIP limit simply provokes the
conversation.
Leadership encourages discussion about
improvement. Use of Models and other
evidence leads to an improvement
suggestion and implementation
56. 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
57. Kanban daily standup meetings can
be very large
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
58. Spontaneous Quality Circles form after the standup to
focus on immediate process issues
Daily standup provides forum for spontaneous
association to attack process issues affecting
productivity and lead time
3 day freeze on test environ was a transaction
cost on release that caused a bottleneck at
“build” state. Reduced to 24 hrs. Result was
improved smoother flow resulting in higher
throughput and shorter lead time.
59. Sticky Buddy scheme was instituted to allow remote
workers to keep kanban board up-to-date and
synchronized with electronic tracking
“Cancelled” area
With trash can
For partially worked
Items obe.
61. Cumulative Flow and
Predictive Modeling with S-Curve
Device Management Ike II Cumulative Flow
240
220
200
180
160
Features
140 Typical S-curve
120
100
80
60
40
20
0
ar
ar
eb
eb
eb
ar
ar
ar
M
M
-M
-M
-M
-F
-F
-F
2-
9-
10
17
24
16
23
30
Time
Inventory Started Designed Coded Complete
62. Simulating S-Curve with a Z
Device Management Ike II Cumulative Flow
240
220 60%
200
180
160 Slope in middle
Features
140
3.5x - 5x slope
120
100 at ends 5x
80
60 20% 20%
40
20
0
ar
ar
eb
eb
eb
ar
ar
ar
M
M
-M
-M
-M
-F
-F
-F
2-
9-
10
17
24
16
23
30
Time
Inventory Started Designed Coded Complete
63. Track actual throughput against projection
Device Management Ike II Cumulative Flow
240
220
200
180
160
Features
140
120
100
80
Track delta between
60
40 planned and actual
20 each day
0
ar
ar
eb
eb
eb
ar
ar
ar
M
M
-M
-M
-M
-F
-F
-F
2-
9-
10
17
24
16
23
30
Time
Inventory Started Designed Coded Complete
64. 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 short-
term planning tool
See following examples
65. Velocity Variation
South African Team from 2011plotted per Sprint (2 weekly)
Mean 29, UCL (+1 sigma) 43 (+1.5x), LCL (-1 sigma) 15 (- 2x)
66. DBA Team Velocity
90
80
70 Trend
60
50
Total Velocity
Small support tasks
40
30
20 Trend
(not included
in total velocity)
10
Week of Christmas
0
Mattias Skarin client based in Paris in 2009/2010, plotted weekly
Mean 42, +1 sigma = 55, -1 sigma = 29 (+/- 1.4x)
67. Investment Bank, London, Extreme Programming
Weekly Mean 10, Max = 16, Min = 6
Spread (+/- 1.6x)
69. 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
70. Unplanned Work Report
Scope Creep
Dark Matter
(emergent features)
Original Scope
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
71. 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
72. TV/Movie Company in USA 2008
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
73. Original CFD shows same top line
Dark matter quotient is 19%
Device Management Ike II Cumulative Flow
240
220
200
180
160
Features
140
120
100
80
Track delta between
60
40 planned and actual
20 each day
0
ar
ar
eb
eb
eb
ar
ar
ar
M
M
-M
-M
-M
-F
-F
-F
2-
9-
10
17
24
16
23
30
Time
Inventory Started Designed Coded Complete
74. Make a long term plan to build
platform replacement
Device Management Ike II Cumulative Flow
Required throughput (velocity)
240
220
200
180
160
Features
140 Slope in middle
120 3.5x - 5x slope
100
at ends 5x
80
60
40
20
0
2006 2008
ar
ar
eb
eb
eb
ar
ar
ar
M
M
-M
-M
-M
-F
-F
-F
2-
9-
10
17
24
16
23
30
During the middle 60% of the project schedule
Time
we need Throughput (velocity) to average 13
Inventory Started Designed Coded Complete
features per month
75. Little‟s Law
Determines staffing level
Target to achieve plan
WIP
Throughput =
Lead Time
From observed capability
Treat as Fixed variable
76. 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
77. 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
78. Little‟s Law
Determines staffing level
Target to achieve plan
WIP
13 / month =
0.25 months
WIP = 3.25, round up to 4.
Might be safe to
From observed capability
round down to 3.
If current working practice is 1 unit WIP per person
then 3 people are needed to work this project exclusively
81. Manage bottlenecks to increase
throughput
Known max productivity
Idea Analysis Design Code
~90 ~80 ~50 ~50
Error Error Error
Working Acceptance System Unit
Code Test Test
How do I trim 25% Test
~80 ~30
~40 ~50
off the schedule for Quality
a project going
Schedule
1. Identify - Current CCR is System Test – 30
through this system?
per month
2. 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
Quality
4. Elevate - Plan to recruit temporary testing staff immediately
Schedule
82. 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
83. Wimbledon comes in on time every year
How do event planners do it?
Scheduling Wimbledon isn’t an exact
science
Except 2004 when it
rained on Sunday and
the final was on
Monday ;-)
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!
84. 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
86. But there are also coordination costs in knowledge
work problems
Communication
Queue Task W
Queue Task Wait
Setup Cleanup
Queue Task Wait
Q Task Wait
Time
87. And in knowledge work problems, coordination
costs grow non-linearly with batch size
Communication
Queue Task W
Queue Task Wait
Setup Cleanup
Queue Task Wait
Q Task Wait
Time
93. respect
The team must the
WIP limit and value the
conversations it
provokes about problems
94. Leadership is the secret
sauce! Encourage it from any team
member regardless of position,
experience or authority
95. Enable the team with transparency of
process (visualization of invisible
work & process dynamics.) Use models for
understanding problems and
improvements will occur.
100. 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… dja@agilemanagement.net
Editor's Notes
Kanban board gives visibility into process issues – ragged flow, transaction costs of releases.Daily standup provides forum for spontaneous association to attack process issues affecting productivity and lead timeFor ex: 3 day freeze on test environment was a transaction cost on release that caused a bottleneck at “build” state. Reduced to 24 hrs. Result was improved smoother flow resulting in higher throughput and shorter lead time.