oop 2012 - kanban at scale and why traditional approaches set you up for failure
Post on 13-Sep-2014
703 views
DESCRIPTION
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 monthTRANSCRIPT
![Page 1: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/1.jpg)
NSNLisbonJanuary 2012
Kanban at Scaleand why traditional approaches set
you up for failureDavid J. Anderson
David J. Anderson & [email protected]
Twitter @agilemanager
![Page 2: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/2.jpg)
Kanban2012
Book PublishedApril 2010
A 72,000 wordintro to the topic
![Page 3: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/3.jpg)
Kanban2012
Portuguese (Brazilian) published October 2011
Translation by Andrea PintoRecife, Brazil
![Page 4: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/4.jpg)
Kanban2012
Published in Spanish9th May 2011
Translated byMasa K Maeda, PhD
![Page 5: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/5.jpg)
Kanban2012
Kanban on Big Projects
Estimating and planning, tracking, managing & reporting
![Page 6: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/6.jpg)
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
![Page 7: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/7.jpg)
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
![Page 8: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/8.jpg)
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
![Page 9: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/9.jpg)
Kanban2012
Little’s Law
ThroughputLead Time
WIP=
![Page 10: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/10.jpg)
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
![Page 11: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/11.jpg)
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
![Page 12: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/12.jpg)
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
![Page 13: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/13.jpg)
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
![Page 14: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/14.jpg)
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
![Page 15: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/15.jpg)
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)
![Page 16: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/16.jpg)
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
![Page 17: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/17.jpg)
Kanban2012
Investment Bank, London, Extreme ProgrammingWeekly Mean 10, Max = 16, Min = 6 Spread (+/- 1.6x)
![Page 18: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/18.jpg)
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)
![Page 19: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/19.jpg)
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
![Page 20: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/20.jpg)
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
![Page 21: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/21.jpg)
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
![Page 22: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/22.jpg)
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
![Page 23: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/23.jpg)
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
![Page 24: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/24.jpg)
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
![Page 25: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/25.jpg)
Kanban2012
Little’s Law
ThroughputLead Time
WIP=
Target to achieve plan
From observed capability
Treat as Fixed variable
Determines staffing level
![Page 26: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/26.jpg)
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
![Page 27: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/27.jpg)
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
![Page 28: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/28.jpg)
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
![Page 29: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/29.jpg)
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
![Page 30: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/30.jpg)
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
![Page 31: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/31.jpg)
http://www.limitedwipsociety.org
Yahoo! Groups: kanbandevYahoo! Groups: kanbanops
http://leankanbanuniversity.com
LinkedIn Groups: Software Kanban
![Page 32: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/32.jpg)
Kanban2012
![Page 33: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/33.jpg)
Kanban2012
Cost of Delay
![Page 34: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/34.jpg)
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
![Page 35: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/35.jpg)
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
![Page 36: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/36.jpg)
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
![Page 37: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/37.jpg)
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
![Page 38: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/38.jpg)
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
![Page 39: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/39.jpg)
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
![Page 40: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/40.jpg)
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
![Page 41: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/41.jpg)
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
![Page 42: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/42.jpg)
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
![Page 43: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/43.jpg)
Kanban2012
Kanban SystemDesign Examples
![Page 44: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/44.jpg)
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
![Page 45: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/45.jpg)
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
![Page 46: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/46.jpg)
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
![Page 47: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/47.jpg)
Kanban2012
5 4 8 2 2
...InputQueue In Prog DoneDoneIn Prog
Analysis TestReady Test
ReleaseReady
“Open Column for Multiple Unordered
Activities”
UI DesignSecurityPersistenceBiz Logic
![Page 48: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/48.jpg)
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
![Page 49: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/49.jpg)
Kanban2012
Classification byRequirement Market Risk of
Change
![Page 50: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/50.jpg)
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
![Page 51: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/51.jpg)
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
![Page 52: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/52.jpg)
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
![Page 53: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/53.jpg)
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
![Page 54: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/54.jpg)
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
![Page 55: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/55.jpg)
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
![Page 56: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/56.jpg)
Kanban2012
Scaling out with Service-Orientation
![Page 57: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/57.jpg)
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
![Page 58: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/58.jpg)
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
![Page 59: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/59.jpg)
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
![Page 60: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/60.jpg)
Kanban2012
Posit ScienceCase Study
![Page 61: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/61.jpg)
Kanban2012
Areas of dissatisfaction
Internal Sources
FragmentationTasking – too busy, inaccurate
External Sources
Stories not finishedDeadlines missed
![Page 62: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/62.jpg)
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
![Page 63: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/63.jpg)
Kanban2012
The sticky boardLimit 3 stories per person
![Page 64: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/64.jpg)
Kanban2012
Stakeholder complaints
Too busy to discuss new workNot delivering current workEverything takes too long
![Page 65: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/65.jpg)
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
![Page 66: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/66.jpg)
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
![Page 67: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/67.jpg)
Kanban2012
Or…
Make flow even
Reduce work in progress
Reduce planning overhead
Make sure the work is important and focused
Hold Product Owner accountable
![Page 68: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/68.jpg)
Kanban2012
Solutions
Better visibility
WIP limits to manage flow
Group and classify work to reduceGroup and classify work to prioritize
![Page 69: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/69.jpg)
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
![Page 70: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/70.jpg)
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
![Page 71: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/71.jpg)
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)
![Page 72: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/72.jpg)
Kanban2012
![Page 73: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/73.jpg)
Kanban2012
![Page 74: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/74.jpg)
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
![Page 75: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/75.jpg)
Kanban2012
![Page 76: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/76.jpg)
Kanban2012
![Page 77: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/77.jpg)
Kanban2012
![Page 78: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/78.jpg)
Kanban2012Accomplished
Better visibility
WIP limits to manage flow
Group and classify work to reduceGroup and classify work to prioritize
![Page 79: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/79.jpg)
Kanban2012Accomplished
Only highest priority work in progress
Smoother flow (more predictable)
Easier and accurate planning
Stakeholder collaboration!
![Page 81: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/81.jpg)
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]
![Page 82: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/82.jpg)
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)
![Page 83: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/83.jpg)
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?
![Page 84: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/84.jpg)
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
![Page 85: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/85.jpg)
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
![Page 86: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/86.jpg)
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?
![Page 87: OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure](https://reader037.vdocuments.us/reader037/viewer/2022110113/541343137bef0a40598b6522/html5/thumbnails/87.jpg)
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?