Kanban An Alternative Path to Agility

Transcription

1 Kanban An Alternative Path to Agility Presenter David J. Anderson CEO, Lean Kanban Inc. Agile Days Moscow March 2014 Release 1.0

2 The Meaning of Agile

3 What Agile Methods Seek to Achieve Agile methods ask us to Make Progress with Let s Enable Treat not bore a high work-in-progress you trust (yet culture imperfect information again) Create as if it eedback were a liability Loops & with a slide showing the Create The enable rather trust dividend eliminates Agile a than an asset Reworking Manifesto! craftsmanship a capability to adapt bureaucracy & encourages course correcting as work ethic collaborative new information arrives is better With Knowledge 1 risk st working gen Agile & is methods use perishable. of tacit this was knowledge management & faster than ocus limited on finishing to adapting things to changing quickly Encourage high delaying quality, for perfect well before requirements they go or stale scope engineered code that information is easily adapted (refactored) as new information arrives and requires very little rework due to errors

4 The Kanban Method an alternative path to agility!

5 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

6 The Kanban Method is not A project management or software development lifecycle process Nor, does it encourage a process-centric approach to improvement!

7 Don t do this!... Managers Imposes Designs Or Defines Process Coaches Process Workers ollow

8 Kanban Method Uses large boards to visualize invisible work and virtual signal card systems Creates an adaptive capability in your organization Enables adaptability in your business processes to respond successfully to changes in your business environment

9 Kanban Method Kanbanize your existing process Provoke existing processes to change and service delivery to improve Each workflow will evolve a uniquely tailored process solution, fitter for its context Customer & employee satisfaction will improve

10 Kanban has two meanings Kanban has two meanings in Japanese. Both meanings are incorporated into the Kanban Method Kanban written in Kanji (Chinese characters) 看板 means visual (or sign) board Kanban written in Japanese alphabet, hiragana, かんばん means signal cards(s) In Chinese, only the 看板 version exists. Hence, in Chinese, kanban can only mean sign board but the method was actually inspired by the signal cards system used in Japan.

11 6 Practices for Adaptive Capability The Generalized Version Visualize (with a kanban board ( 看板 )) Limit Work-in-progress (with kanban ( かんばん )) Manage low Make Policies Explicit Implement eedback Loops Improve Collaboratively, Evolve Experimentally (using models & the scientific method)

12 What is a kanban system? ( かんばん )

13 A Kanban Systems consists of kanban ( かんばん ) signal cards in circulation

14 Using a virtual kanban system

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

16 Backlog Pool of Ideas Engineering Ready 5 Commitment is deferred Test Development Ready Testing Ongoing Done UAT Deployment Ready Change Requests Pull G Ideas should remain optional & (ideally) unprioritized D Wish to avoid aborting after commitment E PTCs Commitment point We are committing to getting started. We are certain we want to take delivery. I

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

18 Pool of Ideas Upstream Kanban Prepares Options Biz Case Dev Requirements Analysis Ready for Engineering 4-12 Committed 4 Ongoing Development 3 Done Verification Testing 3 Min & Max limits insure sufficient options are always available K L J I D Options $$$ cost of acquiring options Committed Work Discarded O Reject P Q Commitment point

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

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

21 Specific delivery commitment may be deferred even later Pool of Ideas Engineering Ready 5 Test Development Ready Testing Ongoing Done UAT Deployment Ready Change Requests Pull PTCs G D We are now committing to a specific deployment and delivery date E Discarded I *This may happen earlier if I circumstances demand it 2 nd Commitment point*

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

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

24 low Efficiency low efficiency measures the Pool percentage Engin- of total lead time is Deployment of eering spent actually adding Ideas Ready Development value (or Testing Ready Done knowledge) versus waiting Ongoing Done Verification Acceptance Until then customer orders are merely available options low efficiency = Work Time x 100% low efficiencies of 2% have been reported*. 5% -> 15% D is normal, P1 > 40% is good! I G GY PB DE E MN AB Lead Time Multitasking means time spent in working columns is often waiting time Waiting Working Waiting Working Waiting Lead Time * Zsolt abok, Lean Agile Scotland, Sep 2012, Lean Kanban rance, Oct 2012

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

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

27 Pool of Ideas Allocate Capacity to Types of Work Engineering Ready Deployment Ready Development Testing Ongoing Done Verification Acceptance Done Change Requests 4 Consistent capacity allocation should bring more some consistency MN to delivery D rate of work AB of each type PB DE E Lead Time Production Defects I 3 G GY P1 Separate understanding of Lead of Lead Time Time for for each each type type of work of work Lead Time

28 Infinite Queues Decouple Systems DE GY D G MN AB E Deployment Ready Pool Engin- The of infinite eering queue Ideas Ready Development decouples Testing the systems. The deployment Ongoing Done Verification Acceptance system uses batches and is separate from the kanban system The 2 nd commitment is actually a commitment PB for the downstream deployment system The Kanban System gives us confidence to make that downstream commitment I P1 Done

29 Pool of Ideas Engineering Ready Identifying Buffers Deployment Ready Development Testing 3 3 Ongoing Done verification Acceptance 2 Done I G D PB DE I am a buffer! P1 The The clue clue is is in in my E my name Ready MN AB I am buffering non-instant availability or or an activity with a a cyclical cadence

30 Pool of Ideas Engineering Ready Visualizing Pull Signals Deployment Ready Development Testing 3 3 Ongoing Done verification Acceptance 2 Done I G GY D PB DE P1 E MN AB I indicate pullable I am not a separate queue The WIP limit for development applies to on-going or completed pullable work

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

32 impact The Optimal Time to Start 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 Here When we need it With a 6 in 7 chance of on-time delivery, we can always expedite to insure on-time delivery 85 th percentile Commitment point

33 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

34 Implementing a Virtual Kanban System Do not copy an existing (virtual) kanban system! Each system must be designed from 1 st principles using the system thinking approach to implementing kanban A study of demand including business risks & capability is essential to design an appropriate (virtual) kanban system for any given knowledge work service

35 Reminder The Kanban Method is not. A project management or software development lifecycle process Nor, does it encourage a process-centric approach to improvement! You must kanbanize your existing processes and workflows!

36 Kanban Kata

37 eedback Loops Operations Review The Kanban Kata Service Delivery Review Standup Meeting

38 Standup Meeting Disciplined conduct and acts of leadership lead to improvement opportunities Improvement discussions & process evolution happen at after meetings

39 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 or desired outcomes Agreement upon counter-measures actions taken to improve capability resulting in process evolution

40 Operations Review Monthly meeting Disciplined review of demand and capability for each kanban system Provides system of systems view and understanding Kanban system design changes & process evolution suggested by attendees

41 The Kanban Method Prescriptive Practices Visualize work, workflow & business risks (using large physical or electronic boards in communal spaces) Implement Virtual Kanban Systems Manage low Make Policies Explicit Implement Kanban Kata Educate your workforce to enable collaborative evolution of policies & ways of working based on models of workflow from bodies of knowledge such as Theory of Constraints, Deming s Profound Knowledge, Lean, Risk Management ideas such as Real Option Theory & Liquidity

42 Scaling out across an organization

43 Demand Demand Demand Treat each service separately Observed Capability Observed Capability Observed Capability

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

45 Organizational Improvements Emerge

46 Scaling Kanban Each Kanban System is designed from first principles around a specific service 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. Let evolution work!

47 Summary of Benefits

48 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)

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

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

51 Change Management Benefits Significantly reduced resistance to change Processes uniquely tailored to business environment and risk under management Evolutionary changes reduce impact during change and lower risk of failure Change led from the middle and enacted by the workforce. Reduced need for coaching and process specialists

52 Kanban Improves Agility Lead times gradually reduce Predictability of delivery gradually improves Organizational social capital improves Governance, risk management are improved Empowerment without loss of control Improves are often dramatic! 700% increase in delivery rate at BBC On-time delivery often greater than 90% Delivery times often reduced by up to 90%

53 Learn More Yahoo! Groups Kanbandev Kanbanops Limited WIP Society Local meetup groups Meldstrong (

54 Thank you!

55 Upcoming Training in Europe Leading Change & Managing Risk Masterclasses Stockholm March Vienna March 31 April 4 Berlin May

56 About David Anderson is a thought leader in managing effective software teams. He leads a training, consulting, publishing and event planning business dedicated to developing, promoting and implementing sustainable evolutionary He has 30 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 leads Lean Kanban Inc., a global management training, events & publishing business dedicated to offering high quality, innovative, modern management training for the creative knowledge worker industries of the 21 st Century.

57 Acknowledgements The data on slide 15 was provided by Raymond Keating of CME Group. Troy Magennis has pioneered the use of Douglas Hubbard s statistical techniques in conjunction with Kanban and introduced Monte Carlo simulation to replace the 3-phase Z-model presented here Klaus Leopold has been pioneering the use of blocker clustering to encourage project managers to focus on the greater added value of risk management and managing average lead time by curbing opportunity for long tail distributions

58 ixed Date Intangible Standard Expedite Example Distributions

59