This Thing Called Kanban a Presentation for Agile Richmond

This Thing Called Kanban A presentation for Agile Richmond

• Leading experts from business and technology communities • Intimate forum with limited attendance • Relaxing and Creative Atmosphere • Virginia themed Accelerate Delivery with Lean and Agile! • Sessions for the entire team – Leadership – Practitioner Friday Sept 16, 2011 – Technical Lewis Ginter Botanical Gardens – Novice

Web Site Coming Very Soon…

• Introductions • Let’s Play Muraball • What is Kanban? • Adopting Kanban • Q & A

Ryan Shriver Robin Dymond [email protected] [email protected]

• Managing Consulting with Dominion Digital • Managing Partner with Innovel providing • Leads IT Performance Improvement Lean Agile consulting and training Solution internationally • 15 years in software industry • 21 years in software industry • blog: www.theagileengineer.com • blog: www.innovel.net • twitter: @ryanshriver • twitter: @robindymond

Mura is Flow Muri is Overburden Muda is Waste

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

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

Five core properties of Kanban

1. Visualize Workflow 2. Limit Work-in-Progress 3. Measure and Manage Flow 4. Make Process Policies Explicit

• Created by David Anderson 5. Use Models to Recognize based on Theory of Constraints Improvement Opportunities • Approach is Evolutionary not Revolutionary • www.limitedwipsociety.org

• 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

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

Slide 10 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 Testing Testing

WIP = 4 WIP = 6 WIP = 4 WIP = 10 WIP = 12

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech

Story

Defect

Standard Work Types

Work is pulled from the customer request to release

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech Story Story Story Story Story Tech Story Story Tech Story

Story Story Tech Story Story Story Story Story Defect

Defect Story Story Defect Defect Defect

Defect Defect Standard Work Types

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech Story Story Story Story Story Tech Story Story Tech Story

Story Story Tech Story Story Story Story Story Defect

Defect Story Story Defect Defect Defect

Defect Defect Standard Work Types

Two work items were just released, creating room for more work

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech Story Story Story Story Story Tech Story Story Defect Tech Story

Story Story Tech Story Story Story Story Story Defect

Defect Story Story Defect Defect

Defect Defect Standard Work Types

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech Story Story Story Story Story Tech Story Defect Tech Story

Story Story Tech Story Story Story Story Story Defect

Defect Story Story Defect Defect Story

Defect Defect Standard Work Types

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech Story Story Story Story Story Tech Defect Story Defect Tech Story

Story Story Tech Story Story Story Story Story Defect

Defect Defect Story Story Defect Story

Defect Standard Work Types

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech Story Story Story Story Story Defect Story Defect Tech Story

Story Story Tech Story Tech Story Story Story Defect

Defect Defect Story Story Defect Story Story

Defect Standard Work Types

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech Story Story Story Story Story Defect Story Defect Tech Story

Story Story Tech Defect Story Tech Story Story Story Defect

Defect Story Story Slot Defect Story Defect Story

Standard Work Types

We have available capacity to handle an additional piece of work when design is completed

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech Story Story Story Story Story Defect Story Defect Tech Story

Story Story Tech Defect Story Tech Story Story Story Defect

Defect Story Slot Defect Story Defect Story

Standard Work Types

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech Story Story Story Story Story Defect Story Defect Tech Story

Story Story Tech Defect Story Tech Story Story Story Defect

Defect Story Defect Story Defect Story

Standard Work Types

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech Story Story Story Story Story Defect Story Defect Tech Story

Story Story Slot Tech Defect Story Tech Story Story Story Defect

Defect Story Defect Story Defect Story

Standard Work Types

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

Tech Story Story Story Story Story Defect Story Defect Tech Story

Story Story Slot Tech Defect Story Tech Story Story Story Defect

Defect Story Defect Story Defect Story

Standard Work Types

Backlog Analysis Design Development Functional Regression Release Testing Testing

WIP = 4 WIP = 4 WIP = 6 WIP = 6 WIP = 5

Doing Done Doing Done Doing Done Doing Done Doing Done

New Defect Defect Tech Story Story Story Story Story Story Story Tech Story

New Story Defect Defect Defect Story Story Tech Story Tech Story Story Story

Defect Story Defect Story Defect Story

Standard Work Types

Two new pieces of work enter the analysis process

• Name Story: Register New Account • Brief Description ! • Work Type (often by color of card) Requested Date: Jan 4 Started Date: Jan 8 • Class of Service (often by sticker) Due Date: Jan 28 Class of Service: Fixed Date • Blocked (often by post-it note) Description: This functionality will enable… • Requested Date • Start Date Defect: Profile page not • Released Date rendering correctly in IE 6 • Due Date (depending on SLA) Requested Date: Jan 2 • Assigned Person (Avatars are fun!) Started Date: Jan 8 Class of Service: Standard Blocked due to test • Unique ID (for traceability) Description: This defect occurs when…. region being unavailable

Work Types help standardize the work Classes of Service help define a team does for better consistency and expectations for priorities internally and performance tracking externally

Common Work Types Examples Common Classes Examples of Service (SLA’s) Enhancements Features, User Stories, Use Cases, etc. Standard Complete and release as soon as possible Defects Bugs, Issues, etc. Fixed Date Must be completed by a Technical Tasks Software upgrades, specific date. Implies there’s Refactoring, etc. 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

Copyright © 2011 – Ryan Shriver and Robin Dymond Slide 25 Measuring Progress in Kanban Instead of a Burndown Chart, Kanban prefers a cumulative flow diagram for tracking progress Work (# of items) (# Work

Time (days)

Backlog Analysis Design Development Functional Regression Testing Testing

Doing Done Doing Done Doing Done Doing Done Doing Done

Entry Exit Entry Exit Entry Exit Entry Exit Entry Exit Gate Gate Gate Gate Gate Gate Gate Gate Gate Gate

The entry criteria is designed to: The exit criteria is designed to: • Ensure certain pre-conditions are met • Ensure certain post-conditions are met before effort is spent on the work in that before work is passed downstream phase • Ensure consistency in how work is evaluated • Ensure consistency in how work is as “done” evaluated as “ready” • Minimize rework and wasted effort further • Minimize rework and wasted effort spent downstream due to quality issues introduced on requests that aren’t ready in a specific phase

S,M,L,XL

Story Points T-Shirt Sizing

Stand Up Planning

Frequency: Daily Frequency: Depends (weekly/monthly/on- Participation: Entire Team demand) Purpose: Synchronize schedules for the Participation: Depends (entire team/ day to coordinate work for the team subset of team) Where: In front of Kanban Board Purpose: Plan work for the team for some period of time Where: Wherever

Operations Review Governance

Frequency: Monthly Frequency: Depends (weekly/bi-weekly/ Participation: Entire Team monthly) Purpose: Part retrospective for Participation: Governance Team (subset continuous improvement, part review of of team) performance (using actual metrics) Purpose: Similar to Operations Review, Where: Wherever but with process governance team Where: Wherever

Assess Improve Sustain

2-6 weeks* 6 weeks – 4 months* As long as the team is around

Ready for Change? Visualize Workflow Continuous Improvement Awareness & Training Limit Work-in-Progress Optimize Flow Understand Current State Measure and Manage Flow Remove Waste Establish Transition Goals Establish Clear Policies Increase Maturity

• 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: www.limitedwipsociety.org – Lean Software and Systems Consortium: www.leanssc.org – Mailing List: [email protected]

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

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

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

Mura is Flow Muri is Overburden Muda is Waste