Successfully reported this slideshow.
Kanban at Scale
and why traditional approaches set
you up for failure
NSN
Lisbon

January 2012

David J. Anderson
David J....
Book Published
April 2010

Kanban
2012

A 72,000 word
intro to the topic
Portuguese (Brazilian)
published October 2011

Kanban
2012

Translation by
Andrea Pinto
Recife, Brazil
Published in Spanish
9th May 2011

Kanban
2012

Translated by
Masa K Maeda, PhD
Kanban on Big Projects
Estimating and planning, tracking,
managing & reporting
Kanban
2012
Major Project with two-tiered kanban board using swim
lanes for feature sets

Swim lanes control WIP limit –
Requirement W...
Kanban daily standup meetings can
be very large

Kanban
2012

In this example more than 40 people
attend a standup for a l...
Observe Flow with a CFD

Avg. Lead Time

Time
Inventory

Started

Designed

Coded

Complete

30
-M
ar

23
-M
ar

16
-M
ar
...
Little‟s Law

Throughput

=

WIP

Lead Time

Kanban
2012
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
...
Cumulative Flow and
Predictive Modeling with S-Curve

Inventory

Started

Designed

Coded

Complete

30
-M
ar

23
-M
ar

1...
Simulating S-Curve with a Z

60%
Slope in middle
3.5x - 5x slope
at ends

5x

20%

Time
Inventory

Started

Designed

Code...
Track actual throughput against projection

Inventory

Started

Designed

Coded

Complete

30
-M
ar

23
-M
ar

16
-M
ar

9...
Variability in Throughtput (velocity)
It is important to understand the role throughput
plays in long term planning in Kan...
Velocity Variation

Kanban
2012

South African Team from 2011plotted per Sprint (2 weekly)
Mean 29, UCL (+1 sigma) 43 (+1....
DBA Team Velocity
90

80

Trend

70

60

50
Total Velocity
Small support tasks

40

30

Trend

20

10

(not included
in to...
Kanban
2012

Investment Bank, London, Extreme Programming
Weekly Mean 10, Max = 16, Min = 6
Spread (+/- 1.6x)
Velocity Control Charts
Completion Velocity Chart
40
UCL

30

29.2

Completion Velocity

20

Completion
Velocity
UCL

10

...
Variability in scope/requirements
It is also important to realize how much variability
there is in the scope/scale or requ...
Unplanned Work Report
Scope Creep

Dark Matter
(emergent features)

Original Scope

Kanban
2012

Dark matter planned as a ...
Typical Agile teams using User Stories analysis
produce 40-60% dark matter
Stories are recognized as Epics and broken into...
TV/Movie Company in USA 2008

Kanban
2012

Initial Scope is 125 story points
Within days this total scope reaches 190 due ...
Original CFD shows same top line
Dark matter quotient is 19%

Inventory

Started

Designed

Coded

Complete

30
-M
ar

23
...
Make a long term plan to build
platform replacement
Device Management Ike II Cumulative Flow

2008

30
-M
ar

23
-M
ar

16...
Little‟s Law

Determines staffing level

Target to achieve plan

Throughput

=

WIP
Lead Time
From observed capability

Ka...
Changing the WIP limit without
maintaining the staffing level ratio
represents a change to the way of
working. It is a cha...
Plan based on currently observed
capability and current working
practices. Do not assume process
improvements.
If changing...
Little‟s Law

Determines staffing level

Target to achieve plan

55 / week

WIP

=

0.4 week
WIP = 22, round up to 25.
5 t...
Major Project with two-tiered kanban board using swim
lanes for feature sets

Swim lanes control WIP limit –
Requirement W...
Alt Exercise – Reviewing Kanban System Design
















Lanes, colors, ticket designs, decorations

Decide ...
http://leankanbanuniversity.com
http://www.limitedwipsociety.org

LinkedIn Groups: Software Kanban

Yahoo! Groups: kanband...
Kanban
2012
Cost of Delay

Kanban
2012
Typical lead time

Impact
Cost

Impact
Cost

Cost of Delay for Expedite Items

t t

t t
(b) Steep immediate
(a) Regulatory...
Impact
Cost

Impact
Cost

Cost of Delay for Fixed Date Items

t t
(a) Regulatory Fine
Typical lead time

Kanban
2012

t t
...
Cost of Delay for Standard Items
Expedite Item

Typical lead time

Impact
Cost

Impact
Cost

Standard Item

t t
Shallow sl...
Room Nights

To understand the
opportunity cost of delay sketch
market payoff functions

Cost of delay function for an onl...
impact

Cost of 1 Month Delay based on
Market Payoff Sketches
Treat as a Standard Class item

Linear
approximation

time

...
Exercise – Alternative Project





Consider a Valentine‟s Day
promotion
Sketch the market payoff function
Now compare ...
Typical lead time

Impact
Cost

Cost of Delay for Intangible Items

Intangible Item

0
t t
Flat line – no impact
within fo...
Impact

Intangible class items are still important
This is the cost of delay function is typical of
Platform replacements
...
Exercise – Project Cost of Delay






Determine the factors that affect
cost of delay - $$$, politics,
regulation, com...
Kanban System
Design Examples

Kanban
2012
Swim lanes are used to de-lineate types.
Capacity is allocated across lanes
5
Allocation
Total = 20

4

Analysis
Input
Que...
Color de-lineates class of service. Allocate
capacity across classes
5

4

Analysis
Input
Queue In Prog Done

3

4

Develo...
“Split Column for
Concurrent Activities”

5

2

4

4

2

4
Analysis
Input
Queue In Prog Done

Dev
In Prog

Done

Test
Read...
“Open Column for
Multiple Unordered
Activities”

5

4

Analysis
Input
Queue In Prog Done

In Prog

2

Done

Test
Ready

2
...
“Split Column for
Multiple Unorderd
Activities”

5

4

Analysis
Input
Queue In Prog Done

2

4

In Prog
UI Design

Done

T...
Classification by
Requirement Market Risk of
Change
Kanban
2012
Requirement Type by Market Role
•

Table Stakes
–
–
–

•

Differentiators
–
–

•

Drive customer choice/selection
Drive pr...
Market Risk Varies by Requirement Type
Make
Highly likely
Agile/Lean
to change

Misdirector – differentiator
not aligned w...
Kanban board with requirement type allocated by
swim lane
5
Allocation
Total = 20

Input
Queue

4
Analysis
In Prog Done

3...
Example of capacity allocation by cost of delay
class of service. Large “green” allocation offsets
“unplanned urgent” work...
Capacity allocation by work item type based
on shaping demand
5
Allocation
Total = 20

4

Analysis
Input
Queue In Prog Don...
Exercise – Risk Classification Scheme
•
•
•

Take 15 minutes
Same groups as before
Think about ways of classifying risk
fo...
Scaling out with ServiceOrientation

Kanban
2012
Dependencies between teams create demand

Product Strategy

Kanban Adoptions Starts Here

Customers

Demand

App
Dev 1

Ap...
Demarkate waiting area(s) for external
dependencies
5

4

3

Analysis
Input
Queue In Prog Done

4

2

Development
Dev
Read...
Emergence of Service-Oriented
Organizational Structure


Tag Work Items with Shared
Resource Dependency





Provide s...
Posit Science
Case Study

Kanban
2012
Areas of dissatisfaction
Internal Sources

Fragmentation
Tasking – too busy, inaccurate
External Sources

Stories not fini...
Transition to “kanban”
– October 2008

BEFORE

AFTER

Iterations
Scrum Master, PO,
Sprint planning
Daily Standup Meeting
P...
The sticky board

Limit 3 stories per person

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

Kanban
2012
Complaints, per retrospectives
Too much context switching!
Too much work in progress!
Planning is disruptive and cumbersom...
Goals of new “flow” system
Reduce context switching

Reduce work in progress
Steadier workflow for QA & Deploy

Reduce mas...
Or…
Make flow even

Reduce work in progress
Reduce planning overhead

Make sure the work is important and focused
Hold Pro...
Solutions
Better visibility

WIP limits to manage flow
Group and classify work to reduce
Group and classify work to priori...
Transition to “flow”
– August 2009
BEFORE
Iterations

AFTER
SLA

Scrum Master, PO
Sprint planning

Triggered, per feature
...
Example Classes of Service
Expedite – pink; critical and immediate cost of
delay; can exceed other kanban limit (bumps
oth...
Feature Request

Requested by:______________________________________ Date Requested_____________
Feature name_____________...
Kanban
2012
Kanban
2012
Top 10
(features)
Limit 10

Design/
Specify

In Progress

(features into
stories)

(stories and
features)

Limit 3 feature...
Kanban
2012
Kanban
2012
Kanban
2012
Accomplished
Better visibility

WIP limits to manage flow
Group and classify work to reduce
Group and classify work to pri...
Accomplished
Only highest priority work in progress

Smoother flow (more predictable)
Easier and accurate planning

Stakeh...
Thank you!

Kanban
2012

dja@djaa.com
http://djaa.com/
About…
David Anderson is a thought leader in
managing effective software teams. He leads
a consulting firm dedicated to im...
Exercise – Context for Change &
Demand Analysis


Define work item types,
think about







Source
Destination
Work...
Exercise – Identifying initial changes






Take your sources of
dissatisfaction from before
List those that you would...
Understanding workflow doesn‟t need to be
difficult



Map state changes in work items
States tend to reflect the domina...
Exercise – Map the Knowledge Discovery
Process




Sketch the workflow for a few types
of work (any method is acceptable...
Exercise – Overcoming Resistance to WIP limit
Introduction


List reasons people might object to
WIP limits. What are the...
Exercise - Initial Kanban System Design


Design a Kanban System






Types of work & Workflow states
Hierarchy (pa...
Upcoming SlideShare
Loading in …5
×

OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure

1,950 views

Published on

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

Published in: Business, Technology
  • Be the first to comment

OOP 2012 - Kanban at Scale and why traditional approaches set you up for failure

  1. 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. 2. Book Published April 2010 Kanban 2012 A 72,000 word intro to the topic
  3. 3. Portuguese (Brazilian) published October 2011 Kanban 2012 Translation by Andrea Pinto Recife, Brazil
  4. 4. Published in Spanish 9th May 2011 Kanban 2012 Translated by Masa K Maeda, PhD
  5. 5. Kanban on Big Projects Estimating and planning, tracking, managing & reporting Kanban 2012
  6. 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. 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. 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. 9. Little‟s Law Throughput = WIP Lead Time Kanban 2012
  10. 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. 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. 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. 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. 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. 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. 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. 17. Kanban 2012 Investment Bank, London, Extreme Programming Weekly Mean 10, Max = 16, Min = 6 Spread (+/- 1.6x)
  18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. http://leankanbanuniversity.com http://www.limitedwipsociety.org LinkedIn Groups: Software Kanban Yahoo! Groups: kanbandev Yahoo! Groups: kanbanops
  32. 32. Kanban 2012
  33. 33. Cost of Delay Kanban 2012
  34. 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. 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. 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. 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. 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. 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. 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. 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. 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. 43. Kanban System Design Examples Kanban 2012
  44. 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. 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. 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. 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. 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. 49. Classification by Requirement Market Risk of Change Kanban 2012
  50. 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. 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. 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. 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. 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. 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. 56. Scaling out with ServiceOrientation Kanban 2012
  57. 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. 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. 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. 60. Posit Science Case Study Kanban 2012
  61. 61. Areas of dissatisfaction Internal Sources Fragmentation Tasking – too busy, inaccurate External Sources Stories not finished Deadlines missed Kanban 2012
  62. 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. 63. The sticky board Limit 3 stories per person Kanban 2012
  64. 64. Stakeholder complaints Too busy to discuss new work Not delivering current work Everything takes too long Kanban 2012
  65. 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. 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. 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. 68. Solutions Better visibility WIP limits to manage flow Group and classify work to reduce Group and classify work to prioritize Kanban 2012
  69. 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. 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. 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. 72. Kanban 2012
  73. 73. Kanban 2012
  74. 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. 75. Kanban 2012
  76. 76. Kanban 2012
  77. 77. Kanban 2012
  78. 78. Accomplished Better visibility WIP limits to manage flow Group and classify work to reduce Group and classify work to prioritize Kanban 2012
  79. 79. Accomplished Only highest priority work in progress Smoother flow (more predictable) Easier and accurate planning Stakeholder collaboration! Kanban 2012
  80. 80. Thank you! Kanban 2012 dja@djaa.com http://djaa.com/
  81. 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. 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. 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. 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. 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. 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. 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?

×