@djaa_dja Kanban Briefly Explained Options, Commitment, Probabilistic Forecasting, Adaptation, Scaling

Transcription

1 Kanban Briefly Explained Options, Commitment, Probabilistic orecasting, Adaptation, Scaling

2 What is a kanban system?

3 A Kanban Systems consists of kanban signal cards in circulation

4 Kanban are (typically) virtual! Backlog Engineering 5 Change Requests Development Ongoing Done Test 5 Testing H UAT Deployment B Pull E virtual kanban These are the J G C Pull Boards are not required to do Kanban! I A The boarddis a visualization of the * The first system used database triggers workflow process, the work-in-progress to signal pull. There was no board! and the kanban PTCs Pull I

5 Commitment is deferred Backlog Pool of Ideas Change Requests Pull Engineering 5 H Development Ongoing Done 5 Testing UAT Items in the backlog remain optional and unprioritized D G PTCs Commitment point Test Deployment A C E Wish to avoid discard after commitment We are committing to getting started. We are certain we want to take delivery. I

6 Discard rates are often high Pool of Ideas Change Requests H Engineering Development 5 H Ongoing Done Test 5 Testing UAT Deployment The discard rate with XIT was 48%. ~50% is commonly observed. G Reject Deferring commitment Options have the and avoiding interrupting C value because future is uncertain Dworkers for estimates E there makes sense when 0% discard rate implies is no uncertainty theare future discard about rates high! PTCs I Discarded I A

7 Upstream Kanban Prepares Options Pool of Ideas Biz Case Dev Requifor rements EnginAnalysis eering K L Min & Max limits insure sufficient options are always available Committed 4 J I Development Ongoing Done Testing Verification H D Options $$$ cost of acquiring options Reject Discarded O P Committed Work $$$ cost of converting options Q Commitment point

8 Replenishment requency Pool of Ideas Engineering 5 Replenishment Change Requests Pull H G PTCs Discarded I Development Test Testing UAT 5 Done replenishment Ongoing requent is more agile. On-demand C replenishment is most D agile! E The frequency of system replenishment should reflect arrival rate of new information and the transaction & coordination costs of holding a I meeting Deployment A

9 Delivery requency Pool of Ideas Change Requests Pull Engineering Development Test Testing 5 Done 5requent deployment is more agile. Ongoing H Deployment buffer size can On-demand deployment reduce as frequency of delivery C D most increases agile! G PTCs Discarded I UAT is E The frequency of delivery should reflect the transaction & coordination costs of deployment plus costs & tolerancei of customer to take delivery Deployment Delivery A

10 Specific delivery commitment may be deferred even later Pool of Ideas Change Requests Pull Engineering 5 Development Ongoing Done H D G C Test 5 Testing A E PTCs Discarded *This may happen earlier if I circumstances demand it ses it u an omm b n Ka se C ha P 2 We are now committing to a specific deployment and delivery date I UAT Deployment 2nd Commitment point*

11 Defining Kanban System Lead Time Pool of Ideas Change Requests Pull Engineering 5 The clock starts Test ticking when we Testing accept the customers order,uat not Development Done when5 it is placed! Ongoing Deployment Until then customer orders are merely available options H D G A C E System Lead Time PTCs I Discarded I Lead time ends when the item reaches the first queue.

12 Little s Law & Cumulative low Delivery Rate Pool of Ideas = WIP Lead Time Avg. Lead Time WIP To Deploy Avg. Delivery Rate

13 Infinite Queues Decouple Systems Pool Enginof infinite eering The queuedevelopment decouples Ideas the systems. The deployment Done Ongoing system uses 2 batches and is separate from the kanban system The 2nd commitment is actually a commitment PBfor the downstream deployment system H DE The Kanban System gives us confidence to make that I downstream commitment GY Testing VerificationAcceptance D M N G Deployment Done C P1 E AB nt e itm ent m om loym C p d 2n r de o is f A 2nd Commitment point

14 Identifying Buffers Pool of Ideas Engineering 2 Ongoing H I Development GY Done verificationacceptance C I am a buffer! D G Testing Deployment P1 PB DE The clue is is in in my name The clue my name E M N AB I am buffering non-instant availabilityororanactivity availability activitywith witha a cyclical cadence Done A

15 Defining Customer Lead Time Pool of Ideas Change Requests Pull Engineering 5 Development Ongoing Done Test 5 Testing UAT The clock still starts ticking when we accept the customers order, not when it is placed! Deployment Done H D G C A E Customer Lead Time PTCs Discarded I The frequency of delivery cadence will affect customer lead timei in addition to system capability

16 low Efficiency low efficiency measures the Pool Enginpercentage of total lead time is of eering spent actually adding value (or Development Ideas knowledge) versus waiting 2 Ongoing Done Testing VerificationAcceptance Deployment Until then customer orders are merely available options low efficiency = Work Time low efficiencies of 2% have been reported*. 5%D-> 15% C isp1 normal,g> 40% is good! H I GY PB DE Lead Time Working N Waiting Working Waiting Lead Time * Zsolt abok, Lean Agile Scotland, Sep 2012, Lean Kanban rance, Oct 2012 x 100% A Multitasking means time spent in Eworking columns is often waiting M time AB Waiting Done

17 Observe Lead Time Distribution as an enabler of a Probabilistic Approach to Management Lead Time Distribution.5 CRs & Bugs Days Thisisismulti-modal multi-modal data! This data! Mean of 1 days TheSLA work isexpectation of two types: of Change Requests (new 105 and days with 98 % features); Production Defects SLA expectation of 44 days with 85% on-time on-ti

18 Change Requests Production Defects ilter Lead Time data by Type of Work (and Class of Service) to get Single Mode Distributions Mean 5 days 98% at 25 days 85% at 10 days Mean 50 days 98% at 150 days 85% at 60 days

19 Allocate Capacity to Types of Work Pool of Ideas Engineering 2 Change Request s 4 H I Ongoing Done Testing VerificationAcceptance E allocation Consistent capacity M should should bring bring some more consistency to N D AB of each type delivery rate of work Productio n Defects Development PB DE Lead Time C G P1 GY Separate understanding of Separate understanding of Lead Lead Time each type of work Time forfor each type of work Lead Time Deployment Done A

20 The Optimal Time to Start impact If we start too early, we forgo the option and opportunity to do something else that may provide value. If we start too late we risk incurring the cost of delay Ideal Start When we need it Here With a 6 in 7 chance of on-time delivery, we can always expedite to insure on-time delivery 85th percentile Commitment point

21 Metrics for Kanban Systems Cumulative flow integrates demand, WIP, approx. avg. lead time and delivery rate capabilities Lead time histograms show us actual lead time capability low efficiency, value versus failure demand (rework), initial quality, and impact of blocking issues are also useful

22 Psychology of Probabilistic versus Deterministic Approaches

23 Change Requests The psychology of a probabilistic approach can be challenging I don t want to take the risk of being longer than 60 days. Mean I need 50 a precise estimate of when it will days be delivered! 98% at 150 days 85% at 60 days

24 Classes of Service Help Improve Trust Engineering 2 Development Ongoing Done Testing VerificationAcceptance Deployment Done Different distributions for different 1 of service increases the level of trust that an item will be C delivered in a timely manner AB P1 Expedit e classes ixed Date 2 E D PB Standard Intangibl e H G GY 1 M N I DE A

25 A lack of organizational social capital A lack of organizational social capital may prevent in the kanban system emerging. There istrust a trust in individual peoplefrom rather than thethe result is a degeneration to a deterministic system. system. Individuals are held accountable via their commitments. Everything must have an estimate. Plans are drawn deterministically. and rework Deterministic planning meansoverhead a high likelihood of (of plans) is incurred as things change. Early and broken promises. specific commitments are requested People take the blame!

26 replace trust with comfort & reassurance planning provides a level of comfort. WhenDeterministic people take the blame, replacing the people Deterministic seem accurate and plausible. provides a level ofplans comfort that remedial action has been taken. When promises are broken it further undermines the social capital in in athe organization. The organization is caught vicious cycle of distrust, individual commitment, disappointment, blame and repercussions!

27 What is the Kanban Method?

28 Kanban Method A management & cultural approach to improvement View creative knowledge work as a set of services Encourages a management focus on demand, business risks and capability of each service to supply against that demand

29 Kanban Method Uses visualization of invisible work and virtual kanban systems Installs evolutionary DNA in your organization Enables organizational adaptability to respond successfully to changes in your business environment

30 6 Practices for Evolutionary DNA The Generalized Version Visualize Limit Work-in-progress Manage low Make Policies Explicit Implement eedback Loops Improve Collaboratively, Evolve Experimentally (using models & the scientific method)

31 Kanban Kata

32 eedback Loops The Kanban Kata Operations Review Improvement Kata Standup Meeting

33 Standup Meeting Disciplined conduct and acts of leadership lead to improvement opportunities Kaizen events happen at after meetings

34 Improvement Kata A mentor-mentee relationship Usually (but not always) between a superior and a sub-ordinate A focused discussion about system capability Definition of target conditions Discussion of counter-measures actions taken to improve capability

35 Operations Review Meet monthly Disciplined review of demand and capability for each kanban system Provides system of systems view and understanding Kaizen events suggested by attendees

36 Scaling out across an organization

37 Treat each service separately Demand Observed Capability Demand Observed Capability Demand Observed Capability

38 Some systems have dependencies on others Demand Observed Capability Demand Observed Capability Demand Observed Capability

39 Organizational Improvements Emerge

40 Scaling Kanban Each Kanban System is designed from first principles around a service provided Scale out in a service-oriented fashion Do not attempt to design a grand solution at enterprise scale The Kanban Kata are essential! Allow a better system of systems to emerge over time

41 Summary of Benefits

42 Collaboration Benefits Shared language for improved collaboration Shared understanding of dynamics of flow Emotional engagement through visualization and tactile nature of boards Greater empowerment (without loss of control)

43 Tangible Business Benefits Improved predictability of lead time and delivery rate Reduced rework Improved risk management Improved agility Improved governance

44 Organizational Benefits Improved trust and organizational social capital Improved organizational maturity Emergence of systems thinking Management focused on system capability through policy definition Adaptability (to shifts in demand and risks under management)

45 Trustworthy Kanban Training Global standards & trade association Certificate issuing body Standardized curriculum High Quality accredited trainers Train-the-trainer program

46 Thank you!

47 About David Anderson is a thought leader in managing effective software teams. He leads a consulting, training and publishing and event planning business dedicated to developing, promoting and implementing sustainable evolutionary approaches for management of knowledge workers. He has 0 years experience in the high technology industry starting with computer games in the early 1980 s. He has led software teams delivering superior productivity and quality using innovative agile methods at large companies such as Sprint and Motorola. David is the pioneer of the Kanban Method an agile and evolutionary approach to change. His latest book, published in June 2012, is, Lessons in Agile Management On the Road to Kanban. David is a founder of the Lean-Kanban University Inc., a business dedicated to assuring quality of training in Lean and Kanban for knowledge workers throughout the world.

48 Acknowledgements Hakan orss of Avega Group in Stockholm has been instrumental in defining the Kanban Kata and evangelizing its importance as part of a Kaizen culture. Real options & the optimal exercise point as an improvement over last responsible moment emerged from discussions with Chris Matts, Olav Maassen and Julian Everett around The inherent need for evolutionary capability that enables organizational adaptation was inspired by the work of Dave Snowden.

49 David J Anderson & Associates, Inc.

50 Appendix

51 ixed Date Intangible Standard Expedite Example Distributions

52