This Thing Called Kanban

Transcription

1 This Thing Called Kanban A presentation for Agile Richmond Slide 1

2 Announcing Innovate Virginia! Accelerate Delivery with Lean and Agile! Friday Sept 16, 2011 Lewis Ginter Botanical Gardens Leading experts from business and technology communities Intimate forum with limited attendance Relaxing and Creative Atmosphere Virginia themed Sessions for the entire team Leadership Practitioner nical Novice Web Site Coming Very Soon Slide 2

3 Tonight s Agenda Introductions Let s Play Muraball What is Kanban? Adopting Kanban Q & A Slide 3

4 Who are we? Ryan Shriver Managing Consulting with Dominion Digital Leads IT Performance Improvement Solution 15 years in software industry blog: Robin Dymond Managing Partner with Innovel providing Lean Agile consulting and training internationally 21 years in software industry blog: Slide 4

5 Tonight s Theme: Mura, Muri, Muda Mura is Flow Muri is Overburden Muda is Waste Slide 5

6 Rules for MuraBall 1. Goal for the team: See how much throughput you can get 2. 1 ball is counted when it is touched by every person on the team 3. Balls must have airtime when they are passed between team members 4. Keep the balls moving 5. Team member jobs: Everyone participates Team must track average cycle time appoint a timer Team must track work in progress appoint a counter Team must calculate ball throughput per minute same counter Team must track changes to process appoint a note taker The customer decides what they need processed appoint a customer 6. Use the Scorecard for keeping track between rounds 7. We ll run a few rounds making adjustments between rounds 8. At the end we ll debrief on lessons learned Slide 6

7 Scoreboard for Muraball Work in progress (total balls) Cycle time (elapsed seconds to touch each team member) Throughput (# balls every 10 seconds) Improvements and notes Slide 7

8 What is Kanban? Five core properties of Kanban Created by David Anderson based on Theory of Constraints Approach is Evolutionary not Revolutionary 1. Visualize Workflow 2. Limit Work-in-Progress 3. Measure and Manage Flow 4. Make Process Policies Explicit 5. Use Models to Recognize Improvement Opportunities Slide 8

9 Kanban has roots in Lean Thinking The term Lean was coined by Womack, Jones and Roos in 1990 to describe the Toyota Production System (TPS) TPS was originally developed by Taiichi Ohno and has been refined over 60 years to deliver cars at the rate of customer demand 1 Kanban leverages many of the proven concepts from Lean including: Defining Value from the Customer s perspective Limiting Work in Progress (WIP) Identifying and Removing Waste Identifying and Removing barriers to Flow Culture of Continuous Improvement Kanban, like Lean Software Development (Poppendieck), translates these principles originating in manufacturing to technology product and service organizations 1 Quote by John Seddon Slide 9

10 Comparing Kanban & Scrum (Agile) Similarities Both based on pull scheduling Both limit WIP Both use transparency to drive process improvement Both focus on delivering releasable software early and often Both are based on selforganizing teams Both require breaking the work into pieces In both cases the release plan is continuously optimized based on empirical data (velocity / lead time) Free Book Download: Scrum and Kanban Making the most of both Copyright 2011 Ryan Shriver and Robin Dymond Differences Scrum (Agile) Timeboxed iterations prescribed Team commits to a specific amount of work for this iteration. Uses Velocity as default metric for planning and process improvement. Cross-functional teams prescribed. Items broken down so they can be completed within 1 sprint. Burndown chart prescribed WIP limited indirectly (per sprint) Estimation prescribed Cannot add items to ongoing iteration. A sprint backlog is owned by one specific team Prescribes 3 roles (PO/SM/Team) A Scrum board is reset between each sprint Prescribes a prioritized product backlog Kanban Timeboxed iterations optional Commitment optional Uses Lead time as default metric for planning and process improvement. Cross-functional teams optional. Specialist teams allowed. No particular item size is prescribed. No particular type of diagram is prescribed WIP limited directly (per workflow state) Estimation optional Can add new items whenever capacity is available A kanban board may be shared by multiple teams or individuals Doesn t prescribe any roles A kanban board is persistent Prioritization is optional. Slide 10

11 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Explicit Limits to Work-in-Progress (WIP) based on current capacity Backlog Analysis Design Development Functional Regression Release WIP = 10 WIP = 12 Doing Done Doing Done Doing Done Doing Done Doing Done Standard Work Types Work is pulled from the customer request to release Slide 11

12 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done Standard Work Types Slide 12

13 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done Standard Work Types Two work items were just released, creating room for more work Slide 13

14 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done Standard Work Types Slide 14

15 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done Standard Work Types Slide 15

16 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done Standard Work Types Slide 16

17 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done Standard Work Types Slide 17

18 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done Slot Standard Work Types We have available capacity to handle an additional piece of work when design is completed Slide 18

19 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done Slot Standard Work Types Slide 19

20 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done Standard Work Types Slide 20

21 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done Slot Standard Work Types Slide 21

22 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done Slot Standard Work Types Slide 22

23 The Kanban Board The way to visualize all work in process for a team is through a Kanban board Backlog Analysis Design Development Functional Regression Release WIP = 5 Doing Done Doing Done Doing Done Doing Done Doing Done New New Standard Work Types Two new pieces of work enter the analysis process Slide 23

24 What Info is Found on a Card? Examples of the type of information found on a card includes the followoing Name Brief Description Work Type (often by color of card) Class of Service (often by sticker) Blocked (often by post-it note) Requested Date Start Date Released Date Due Date (depending on SLA) Assigned Person (Avatars are fun!) Unique ID (for traceability) : Register New Account Requested Date: Jan 4 Started Date: Jan 8 Due Date: Jan 28 Class of Service: Fixed Date Description: This functionality will enable : Profile page not rendering correctly in IE 6 Requested Date: Jan 2 Started Date: Jan 8 Class of Service: Standard Blocked due to test Description: This defect occurs when. region being unavailable! Slide 24

25 Work Types and Classes of Service (SLA s) Work Types and Classes of Service (aka SLA s) are related but separate concepts Work Types help standardize the work a team does for better consistency and performance tracking Classes of Service help define expectations for priorities internally and externally Common Work Types Enhancements s nical Tasks Examples Features, User Stories, Use Cases, etc. Bugs, Issues, etc. Software upgrades, Refactoring, etc. Common Classes of Service (SLA s) Standard Fixed Date Examples Complete and release as soon as possible Must be completed by a specific date. Implies there s a penalty for missing this date (i.e. regulatory fine) or opportunity (i.e. trade show) Expedite Must be completed as quickly as possible superseding all other work in process Slide 25

26 Measuring Progress in Kanban Instead of a Burndown Chart, Kanban prefers a cumulative flow diagram for tracking progress Work (# of items) Time (days) Slide 26

27 Quality Gates One way to make process policies explicit is through the use of clearly defined Entry and Exit criteria Backlog Analysis Design Development Functional Regression Doing Done Doing Done Doing Done Doing Done Doing Done Entry Gate Exit Gate Entry Gate Exit Gate Entry Gate Exit Gate Entry Gate Exit Gate Entry Gate Exit Gate The entry criteria is designed to: Ensure certain pre-conditions are met before effort is spent on the work in that phase Ensure consistency in how work is evaluated as ready Minimize rework and wasted effort spent on requests that aren t ready The exit criteria is designed to: Ensure certain post-conditions are met before work is passed downstream Ensure consistency in how work is evaluated as done Minimize rework and wasted effort further downstream due to quality issues introduced in a specific phase Slide 27

28 Common Estimation Models Although Kanban prescribes no single estimation model, these are popular in practice S,M,L,XL Points T-Shirt Sizing Slide 28

29 Common Meetings Although Kanban prescribes no set of meetings, these are popular in practice Stand Up Frequency: Daily Participation: Entire Team Purpose: Synchronize schedules for the day to coordinate work for the team Where: In front of Kanban Board Planning Frequency: Depends (weekly/monthly/ondemand) Participation: Depends (entire team/ subset of team) Purpose: Plan work for the team for some period of time Where: Wherever Operations Review Frequency: Monthly Participation: Entire Team Purpose: Part retrospective for continuous improvement, part review of performance (using actual metrics) Where: Wherever Governance Frequency: Depends (weekly/bi-weekly/ monthly) Participation: Governance Team (subset of team) Purpose: Similar to Operations Review, but with process governance team Where: Wherever Slide 29

30 Kanban Adoption Approach While each team s route to Kanban will be different, we see these basic phases Assess 2-6 weeks* Improve 6 weeks 4 months* Sustain As long as the team is around Ready for Change? Awareness & Training Understand Current State Establish Transition Goals Visualize Workflow Limit Work-in-Progress Measure and Manage Flow Establish Clear Policies Continuous Improvement Optimize Flow Remove Waste Increase Maturity * Actual adoption times depend on many factors, these represent typical ranges in practice Slide 30

31 Kanban Adoption Guidance Educate Yourself and Find a Guide Make evolutionary changes starting from your existing process The basic steps include: Visualize Work-in-Progress with a Kanban board Establish explicit WIP Limits Measure and Manage Flow (transitioning to pull) Set Clear and Transparent Policies Evolve and Continually Improve Establish a governance structure for rolling out changes and guidance Focus initially on Flow and Overburden, then removing Waste Reach out to the community for support Limited WIP Society: Lean Software and Systems Consortium: Mailing List: kanbandev@yahoogroups.com Slide 31

32 Transitioning Teams to Kanban A natural place to pilot Kanban is for software maintenance work Less planned work, more just-in-time work Desire by customers for quick turnaround (especially for severe defects or routine changes) More frequent releases with smaller change sets Kanban works equally as well for software development Can be used in place of (or in conjunction with) Scrum A more evolutionary step towards being agile (especially for waterfall teams) Transparency of information including actual metrics can improve predictability and expectations And other business processes too Marketing Sales Operations Any change, even a change for the better, is always accompanied by drawbacks and discomforts Arnold Bennett Slide 32

33 Case Study: Using Kanban with Scrum In 2010, a Dominion Digital software delivery team piloted Kanban with Scrum 95 user stories were delivered using a combination of Scrum and Scrum + Kanban Using Kanban the team met weekly to plan but would only demo when user stories were done (not according to schedule) The results: Team felt less pressured to hit committed sprint dates, freer to do the right thing for quality solution Time to Market was slightly better with Scrum + Kanban than Scrum alone (at right) Quality also improved with fewer reported defects Cycle Times for User Stories (in days) Scrum 1 week 23 Scrum 2 week th Percentile (in days) Average (in days) Scrum + Kanban 1 week Slide 33

34 Case Study: Kanban in Corporate IT Since March I have been working with several software teams within an IT organization transitioning to Kanban Delivery teams range from persons The teams current methodology includes: ScrumBut (aka Broken Scrum) Waterfall While each team is making progress at their own pace, visualizing the work is just the first step. Transitioning the hearts and minds to working in a new way is not without its challenges Adoption Challenges Visualizing ALL Work-in- Progress Geographically Dispersed Teams Changing from Maximizing Utilization to Maximizing Flow Sticking within the WIP Limits (to achieve pull) Slide 34

35 Tonight s Theme: Mura, Muri, Muda Mura is Flow Muri is Overburden Muda is Waste Slide 35

36 Q & A Slide 36