Kanban An Alternative Path to Agility

Transcription

1 Kanban An Alternative Path to Agility What is Kanban? How do you implement it? What are the benefits? Path to Agility Columbus, Ohio 2013

2 The Meaning of Agile

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

8 Kanban Method Uses visualization of invisible work and virtual kanban systems Installs evolutionary DNA 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 6 Practices for Evolutionary DNA The Generalized Version Visualize Limit Work-in-progress Manage Flow Make Policies Explicit Implement Feedback Loops Improve Collaboratively, Evolve Experimentally (using models & the scientific method)

11 What is a kanban system?

12 A Kanban Systems consists of kanban signal cards in circulation

13 Using a virtual kanban system

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

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

16 Pool of Ideas Change Requests F F F F Reject PTCs Discard rates are often high Engineering Ready 5 G Test Development Ready Testing Ongoing Done The discard 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

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

18 Engineering Pool Ready of Ideas 5 Replenishment Change Requests Pull F F F F F F F PTCs Discarded Replenishment Frequency G I Test Development Ready Testing Ongoing Done Frequent 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

19 Delivery Frequency Change Requests Pull Pool of Ideas F F F F F F F Engineering Ready Ongoing Done Frequent 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 Iof customer to take delivery

20 Pool of Ideas Specific delivery commitment may be deferred even later Engineering Ready 5 Test Development Ready Testing Ongoing Done UAT Deployment Ready Change Requests Pull F F F F F F F 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*

21 Pull Defining Kanban System Lead Time Pool of Ideas Change Requests F F F F F F F PTCs 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

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

23 Flow Efficiency Flow efficiency measures the Pool percentage Engineerinment of total lead time is Deploy- of 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 optionsflow efficiency = Work Time x 100% Flow efficiencies of 2% have been reported*. F 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 Fabok, Lean Agile Scotland, Sep 2012, Lean Kanban France, Oct 2012

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

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

26 Allocate Capacity to Types of Work Pool of Ideas Engineering Ready Deployment Ready Development Testing Ongoing Done Verification Acceptance Done Change Requests F 4 Consistent capacity allocation should bring some more 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 of Lead Lead Time Time for for each each type type of work of work Lead Time

27 Infinite Queues Decouple Systems F DE GY D G MN AB E Pool Engineering The of infinite queue Ideas Ready Development decouples Testing the systems. The deployment Ongoing Done Verification Acceptance system uses batches and is separate from the kanban system Deployment Ready 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 2 nd Commitment point

28 Pool of Ideas Engineering Ready Identifying Buffers Deployment Ready Development Testing 3 3 Ongoing Done verification Acceptance 2 Done F I G GY 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

29 Pool of Ideas Engineering Ready Visualizing Pull Signals Deployment Ready Development Testing 3 3 Ongoing Done verification Acceptance 2 Done F 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

30 Pull Pool of Ideas Change Requests F F F F F F F PTCs Defining Customer Lead Time Engineering Ready 5 G 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

31 The Optimal Time to Start If we start too early, we forgo the option and opportunity to do something else that may provide value. impact 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

32 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 Flow efficiency, value versus failure demand (rework), initial quality, and impact of blocking issues are also useful

33 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

34 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!

35 Kanban Kata

36 Feedback Loops Operations Review The Kanban Kata Improvement Kata Standup Meeting

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

38 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

39 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

40 6 Practices for Evolutionary DNA The More Specific Version Visualize work, workflow & business risks (using large physical or electronic boards in communal spaces) Implement Virtual Kanban Systems Manage Flow 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 Options & Liquidity

41 Scaling out across an organization

42 Treat each service separately Demand Observed Capability Observed Capability Demand Demand Observed Capability

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

44 Organizational Improvements Emerge

45 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!

46 Scaling up and down (big projects, portfolios & personal work)

47 Scaling up (large projects, 2-tiered systems)

48 Scaling Up - Planning a big project Features Feb Device Management Ike II Cumulative Flow 17-Feb Required (local average) delivery rate Slope in middle 3.5x -5x slope at ends Feb 2-Mar 9-Mar During the middle 60% of the project schedule we Time need Throughput (velocity) to average 220 features Inventory Started Designed Coded Complete per month 5x 16-Mar 23-Mar 30-Mar

49 Delivery Rate Target to achieve plan Little s Law Calculated based on known lead time capability & required Plan delivery based on Changing rate currently the observed WIP limit without capability maintaining and current the working staffing level ratio practices. Do represents not assume a change process to the way of improvements. working. It is a change to the process and will produce WIP a change = If changing WIP in to the reduce observed undesirable common cause effects (e.g. multitasking), capability get of the new system sample data (perform a spike) to observe the new capability Lead Time Determines staffing level From observed capability Treat as a fixed variable

50 Target to achieve plan Using Little s Law Calculated based on known lead time capability & required At this point perhaps just a little delivery rate black magic and experience may If our current working be required. practices/process exhibited an average Rounding 22 up WIP to 25 = would 22 WIP of 1 item per 55/week conveniently = person then we require 25 people organized provide in 5 for 5 teams teams of 5 people with a to WIP complete limit of the 5 items each 0.4 weeks project on-time Determines staffing level From observed capability Treat as a fixed variable

51 2-tiered board Kanban System within a Kanban System 1 lane per team

52 WIP in this area should be 25 items* *photo taken early in the project before it was fully staffed/loaded Lead time Median lead time target is 2 days Alert managers if beyond 5 days

53 Scaling Down - Personal Kanban A mutation that emerged in my office in 2008 by Jim Benson & Corey Ladas For individuals & small teams (2 or 3 ppl) Visualize Limit WIP Simple To Do-Next-Doing-Done boards

54 Scaling Up - Portfolio Kanban Another mutation that emerged in 2009 in various places such as mobile.de in Berlin Focus on limiting projects in a portfolio No real workflow Visualize project completion through physical position of ticket Visualize business risks

55 Hedging Investment Risk against Product Lifecycle in a Portfolio Kanban Allocation of personnel Total = 100% Complete 0% Horizontal position shows percentage complete Projects-in-progress Complete 100% Cash Cows 10% budget A B Size of ticket indicates scale or size of project Growth Markets 60% budget C D Innovative/New 30% budget E F G Color may indicate cost of delay (or other risk) K H

56 Summary of Benefits

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

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

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

60 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

61 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%

62 Learn More For best results, work with an accredited trainer (AKT) or credentialed Kanban Coaching Professional (KCP) Part of a global conference series promoting Kanban and related concepts for improved business performance

63 Thank you!

64 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 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 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.

65 Acknowledgements Hakan Forss 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.

66 David J Anderson & Associates, Inc.

67 Appendix

68 Example Distributions Fixed Date Intangible Standard Expedite

69