87
NSN Lisbon January 2012 Kanban at Scale and why traditional approaches set you up for failure David J. Anderson David J. Anderson & Associates [email protected] Twitter @agilemanager
| Date post: | 13-Sep-2014 |
| Category: |
Business |
| View: | 704 times |
| Download: | 4 times |
NSNLisbonJanuary 2012
Kanban at Scaleand why traditional approaches set
you up for failureDavid J. Anderson
David J. Anderson & [email protected]
Twitter @agilemanager
Kanban2012
Book PublishedApril 2010
A 72,000 wordintro to the topic
Kanban2012
Portuguese (Brazilian) published October 2011
Translation by Andrea PintoRecife, Brazil
Kanban2012
Published in Spanish9th May 2011
Translated byMasa K Maeda, PhD
Kanban2012
Kanban on Big Projects
Estimating and planning, tracking, managing & reporting
Kanban2012
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
Kanban2012
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
Kanban2012
Observe Flow with a CFD
Device Management Ike II Cumulative Flow
020406080
100120140160180200220240
Time
Feat
ures
Inventory Started Designed Coded Complete
WIP
Avg. Lead Time
Avg. Throughput
Kanban2012
Little’s Law
ThroughputLead Time
WIP=
Kanban2012
SLA expectation of51 days with 98% on-time
Lead Time Distribution
0
0.5
1
1.5
2
2.5
3
3.5
Days
CRs
& Bu
gs
SLA expectation of44 days with 85% on-time
Observe Flow with a spectral analysis histogram of lead time
Mean of 31 days
Kanban2012
Cumulative Flow andPredictive Modeling with S-Curve
Device Management Ike II Cumulative Flow
020406080
100120140160180200220240
Time
Feat
ures
Inventory Started Designed Coded Complete
Typical S-curve
Kanban2012
Simulating S-Curve with a Z
Device Management Ike II Cumulative Flow
020406080
100120140160180200220240
Time
Feat
ures
Inventory Started Designed Coded Complete
20%
60%
20%
Slope in middle3.5x - 5x slope
at ends 5x
Kanban2012
Track actual throughput against projection
Device Management Ike II Cumulative Flow
020406080
100120140160180200220240
Time
Feat
ures
Inventory Started Designed Coded Complete
Track delta between planned and actual
each day
Kanban2012
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
Kanban2012
Velocity Variation
South African Team from 2011plotted per Sprint (2 weekly)Mean 29, UCL (+1 sigma) 43 (+1.5x), LCL (-1 sigma) 15 (- 2x)
Kanban2012
Mattias Skarin client based in Paris in 2009/2010, plotted weeklyMean 42, +1 sigma = 55, -1 sigma = 29 (+/- 1.4x)
0
10
20
30
40
50
60
70
80
90
DBA Team Velocity
Total VelocitySmall support tasks
(not includedin total velocity)Trend
Week of Christmas
Trend
Kanban2012
Investment Bank, London, Extreme ProgrammingWeekly Mean 10, Max = 16, Min = 6 Spread (+/- 1.6x)
Kanban2012
Velocity Control Charts
UCL 29.2
CL 7.206896552
LCL -14.8
-20
-10
0
10
20
30
40
1 2 3 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
Com
plet
ion
Velo
city
Date
Completion Velocity Chart
Completion VelocityUCL
+2 Sigma
+1 Sigma
Motorola PCS 2003, FDD project plottedDaily Mean 7.2, +1 sigma = 15, -1 sigma = 0 (+/- 2x)Weekly Mean 36, +1 sigma = 63, -1 sigma = 11 (+ 1.7x, -3.3x)
Kanban2012
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
Kanban2012
Unplanned Work Report
Dark Matter
(emergent features)
Scope Creep
Original Scope
Dark matter planned as a 19% expansion over original scopeActual Dark Matter over final original scope is 26%Total scope compared to original commitment is 13% greater
Kanban2012
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
Kanban2012
TV/Movie Company in USA 2008
Initial Scope is 125 story pointsWithin days this total scope reaches 190 due to dark matter expansionManagement 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
Kanban2012
Original CFD shows same top lineDark matter quotient is 19%
Device Management Ike II Cumulative Flow
020406080
100120140160180200220240
Time
Feat
ures
Inventory Started Designed Coded Complete
Track delta between planned and actual
each day
Kanban2012
Make a long term plan to build platform replacement
Device Management Ike II Cumulative Flow
020406080
100120140160180200220240
Time
Feat
ures
Inventory Started Designed Coded Complete
Slope in middle3.5x - 5x slope
at ends 5x
Required throughput (velocity)
2006 2008
During the middle 60% of the project schedule we need Throughput (velocity) to average 220
features per month
Kanban2012
Little’s Law
ThroughputLead Time
WIP=
Target to achieve plan
From observed capability
Treat as Fixed variable
Determines staffing level
Kanban2012
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
Kanban2012
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
Kanban2012
Þ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
Little’s Law
55 / week0.4 week
WIP=
Target to achieve plan
From observed capability
Determines staffing level
Kanban2012
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
Kanban2012
Alt Exercise – Reviewing Kanban System Design
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 Lanes, colors, ticket designs, decorations
Decide capacity allocation and how it might vary dynamically over time
http://www.limitedwipsociety.org
Yahoo! Groups: kanbandevYahoo! Groups: kanbanops
http://leankanbanuniversity.com
LinkedIn Groups: Software Kanban
Kanban2012
Kanban2012
Cost of Delay
Kanban2012
t
Cos
t
t
Cos
t(a) Regulatory fine
within bound of usuallead time window
(b) Steep immediate impact / benefit
Cost of Delay for Expedite Items
tt
Impa
ct
Impa
ct
Typical lead time
Kanban2012
t
Cos
t
t
Cos
t(a) Regulatory Fine (b) Inability to trade
or, denial of capabilityon a fixed date in thefuture
Cost of Delay for Fixed Date Items
tt
Impa
ct
Impa
ct
Typical lead time
Kanban2012
t
Cos
t
Shallow slope, immediate or delayed impact / benefit
Both slope and length of delay before impact will factor in selection decisions
Cost of Delay for Standard Items
t
Impa
ct
Typical lead time
Standard Item
Expedite Item
tC
ost
t
Impa
ct
Standard Item
Kanban2012
To understand theopportunity 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
Roo
m N
ight
s
Desired Release Date
Kanban2012
Cost of 1 Month Delay based on Market Payoff Sketches
Cost of delay function for an online Easter holiday marketing delayed by 1 month from mid-January (diff of 2 integrals)
Linearapproximation
Treat as a Standard Class item
time
impa
ct
Kanban2012
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
Kanban2012
t
Cos
t
Flat line – no impact within foreseeable lead time window
Cost of Delay for Intangible Items
t
Impa
ctTypical lead time Intangible Item
0
Kanban2012Cost of delay changes over long period of time
Intangible class items are still importantIm
pact
2005 20092006 2007 2008 2010
0
Intangible Item
Standard Item
Fixed Date Item
Expedite Item
This is the cost of delay function is typical ofPlatform replacementsLegacy code replacementsMajor green-field (v1.0) projects
Kanban2012
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
Kanban2012
Kanban SystemDesign Examples
Kanban2012
Swim lanes are used to de-lineate types. Capacity is allocated across lanes
5 4 43 2 2 = 20 total
...
Change Req12
Maintenance2
Production Defect6
AllocationTotal = 20
InputQueue
DevReady In Prog Done
BuildReady Test
ReleaseReadyDoneIn Prog
DevelopmentAnalysis
Kanban2012
Color de-lineates class of service. Allocate capacity across classes
5 4 43 2 2= 20 total
Allocation
10 = 50%
...
+1 = +5%
4 = 20%
6 = 30%
InputQueue
DevReady In Prog DoneDoneIn Prog
DevelopmentAnalysis BuildReady Test
ReleaseReady
Kanban2012
5 4 2 2
...InputQueue In Prog DoneDoneIn Prog
Dev Analysis TestReady Test
ReleaseReady
“Split Column for Concurrent Activities”
Test Dev
4
4
4
In Prog
Split
Combine
Kanban2012
5 4 8 2 2
...InputQueue In Prog DoneDoneIn Prog
Analysis TestReady Test
ReleaseReady
“Open Column for Multiple Unordered
Activities”
UI DesignSecurityPersistenceBiz Logic
Kanban2012
5 4 2 2
...InputQueue
In Prog DoneDoneIn Prog UI Design
Analysis TestReady Test
ReleaseReady
“Split Column for Multiple Unorderd
Activities”4
Security
Persistence
Business Logic
UI DesignSecurityPersistenceBiz Logic
Req Done
Kanban2012
Classification byRequirement Market Risk of
Change
Kanban2012
Requirement Type by Market Role
• Table Stakes– Undifferentiated– Commodities– “must have”
• Differentiators– Drive customer choice/selection– Drive profits
• Spoilers– Spoil a competitors differentiators
• Cost Reducers• Reduce cost to produce, maintain or service and
increase margin
Kanban2012
Differentiator
Table Stakes
Spoiler
Cost Saver
Mar
ket R
isk
Highly likelyto change
Very unlikelyto change
Market Risk Varies by Requirement Type
Valu
e
Engi
neer
ing
MakeAgile/Lean
Buy/ReuseTraditional?
Regulatory – must have but subject to change
Misdirector – differentiator not aligned with strategic plan
Kanban2012
Kanban board with requirement type allocated by swim lane
InputQueue
Dev.ready In Prog Done
Buildready TestDoneIn Prog
5 4 43 2 2= 20 total
Table Stakes10
Cost Reducer2
Spoiler2
Differentiator6
AllocationTotal = 20
DevelopmentAnalysis
Kanban2012
Example of capacity allocation by cost of delay class of service. Large “green” allocation offsets
“unplanned urgent” work
5 4 43 2 2= 20 total
Allocation
12 = 60%
...
+1 = +5%
4 = 20%
4 = 20%
InputQueue
DevReady In Prog DoneDoneIn Prog
DevelopmentAnalysis BuildReady Test
ReleaseReady
Kanban2012
Capacity allocation by work item type based on shaping demand
5 4 43 2 2 = 20 total
...
Change Req12
Maintenance2
Production Defect6
AllocationTotal = 20
InputQueue
DevReady In Prog Done
BuildReady Test
ReleaseReadyDoneIn Prog
DevelopmentAnalysis
Kanban2012
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…
• Architectural/technical risk• Cost of delay risk• Risk of change• Risk in arrival rate (anticipatable,
planned/unplanned)• Aligned with strategic plan (or not)
• 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
Kanban2012
Scaling out with Service-Orientation
Kanban2012
Dependencies between teams create demand
Platform Development
AppDev 1
AppDev 2
AppDev 3
Customers
Demand
Demand
ServicePro
duct
Stra
tegy
Demand
Kanban Adoptions Starts Here
Viral Spread
Kanban2012
Demarkate waiting area(s) for external dependencies
5 4 43 2 2= 20 total
...InputQueue
DevReady In Prog DoneDoneIn Prog
DevelopmentAnalysis BuildReady Test
ReleaseReady
Waiting on External Group
Late against SLADots denote clock
ticking on SLA
Kanban2012
Emergence of Service-Oriented Organizational Structure
Tag Work Items with Shared Resource Dependency
Clearly mark as impeded Provides visibility onto the problem
Provide shared resource with separate Kanban board/system Offer SLA and track while waiting Escalate late items using issue management
system Treat Integration Items as Fixed Date class of
service Base fixed date on planned integration point
Kanban2012
Posit ScienceCase Study
Kanban2012
Areas of dissatisfaction
Internal Sources
FragmentationTasking – too busy, inaccurate
External Sources
Stories not finishedDeadlines missed
Kanban2012
Transition to “kanban” – October 2008
BEFORE AFTER
Iterations
Scrum Master, PO,
Sprint planning
Daily Standup Meeting
Product Owner accepts
Demo
Retrospective
Estimation By TASK By T-SHIRT SIZE
Other Per Person WIP LIMIT
Kanban2012
The sticky boardLimit 3 stories per person
Kanban2012
Stakeholder complaints
Too busy to discuss new workNot delivering current workEverything takes too long
Kanban2012
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
Priorities from stakeholders are unclear and shifting
Product Owner isn’t accepting completed stories
Kanban2012
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)
Clearer priorities from stakeholders
Kanban2012
Or…
Make flow even
Reduce work in progress
Reduce planning overhead
Make sure the work is important and focused
Hold Product Owner accountable
Kanban2012
Solutions
Better visibility
WIP limits to manage flow
Group and classify work to reduceGroup and classify work to prioritize
Kanban2012
Transition to “flow” – August 2009
BEFORE AFTER
Iterations 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
Other More detailed workflowOther Workflow WIP LIMITS
Kanban2012
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
Standard – blue; cost of delay linear over time; 4th priority
Kanban2012
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
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)____________________
Suggested stories (optional)
Kanban2012
Kanban2012
Kanban2012
Backlog(features)
No limit
21-day SLA for completing feature starts now!
PO must review
Top 10 (features)
Limit 10
Design/Specify(features into stories)Limit 3 features
In Progress(stories and features)Limit 3 features
Test(stories)
Limit 3
Accept(stories & features)Limit 5
Done(stories & features)
Deploy Limit 2
1
2
EX
3
Kanban2012
Kanban2012
Kanban2012
Kanban2012Accomplished
Better visibility
WIP limits to manage flow
Group and classify work to reduceGroup and classify work to prioritize
Kanban2012Accomplished
Only highest priority work in progress
Smoother flow (more predictable)
Easier and accurate planning
Stakeholder collaboration!
Kanban2012
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]
Kanban2012
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)
Kanban2012
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 Is the activity core to the
self-image of the individuals Which roles will resist? Is the activity a method for
establishing social hierarchy?
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?
Kanban2012
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
Kanban2012
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 List the activities (use verbs) Does the knowledge discovery activity
span across people/teams and show collaborations?
Are there any concurrent activities? Are there any specialist activities?
Do these affect a subset of work or a particular type of work
Kanban2012
Exercise – Overcoming Resistance to WIP limit Introduction
List reasons people might object to WIP limits. What are they afraid of? Write each fear on a sticky note Are the objections emotional or logical?
For each emotional resistance… 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… What logical argument is needed to
overcome it? Which body of knowledge is needed? Is
training required?
Kanban2012
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
What information is needed to enable team members to make good quality pull decisions?
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?
