Kanban A Lean approach to Agile software development JFokus January 26, 2010 Henrik Kniberg Agile/Lean coach www.crisp.se Board of directors henrik.kniberg@crisp.se 070 4925284
Goals of this tutorial Basic understanding of Kanban Where it came from What problem it tries to solve Underlying Lean principles How it looks like in practice How to get started Henrik Kniberg 2
Exercise Flow 3
Watch the baton, not the runner! Henrik Kniberg 4
Cycle time Cycle time / lead time = The reliable, repeatable time from customer need until that need is satisfied ( time to market) Examples: Time to get my hamburger Time to resolve support request Time to get home from work Time to deliver a feature Item in Your system & resources Item out Not to be confused with Iteration/Sprint length = release frequency / cadence length Henrik Kniberg 5
Minimize cycle time Watch the baton! Competitive advantage Detect defects earlier Less time for change to happen Henrik Kniberg 6
Problem: Invisible baton Team 1 Team 2 Managers who don t know how to measure what they want settle for wanting what they can measure Russel Ackoff Henrik Kniberg 7
Optimizing resource utilization = suboptimizing cycle time Baton in 100% runner utilization => Lose the race Baton out Car in Car out 100% Road utilization => Long time to get home Http://... CPU: 100% CPU: 100% <html>... Request in CPU: 100% 100% Server utilization => Long response time Response out Henrik Kniberg 8
Queuing theory: Little s law Smaller batch size => faster cycle time Little s law Total Cycle Time = Number of Things in Process Average completion rate 2 liters per second 2 liters per second slow Fast Henrik Kniberg 9
Minimize batch size Knowledge is perishable 1 fresh banana per day Monday Tuesday Wednesday Thursday Friday... or 5 rotten bananas per week? Monday Tuesday Wednesday Thursday Friday Henrik Kniberg 10
Little s law in action Focusing Short cycle time Total Cycle Time = Number of Things in Process Average completion rate 1 task in progress Task A Task B Task C Timeline Multitasking Long cycle time 3 tasks in progress A 1 A 2 A 3 B 2 B 3 B 1 C 3 C 1 C 2 Henrik Kniberg 11
Q: What causes multitasking? A: Optimizing for max resource utilization P T Project A Project B Project C Project D Q1 Q2 Q3 Q4 Henrik Kniberg 12
Value stream mapping Game backlog 8 Design-ready games 15 Production-ready games 12 2d Sam 2h 1m Concept pres. 4h 6m Lisa assigns resources 1d Graphics Sound design design Dev 1w 6m 6m 1m 3w 3m (1m+2m) Integr. & deploy 3w 3 m value added time 25 m cycle time = 12% Process cycle efficiency Cross-functional game team 3-4 m cycle time = 6-8x faster Game team (graphics, sound, dev, integrate) 3-4 months Henrik Kniberg 13
Optimize the whole I m fast! 6 months We re slow! Joe Dave Lisa Done! 3 months Joe We re alot faster! Dave Lisa I m a bit slower Done! January February March April May June July Henrik Kniberg 14
Problem: Invisible baton Team 1 Team 2 Managers who don t know how to measure what they want settle for wanting what they can measure Russel Ackoff Henrik Kniberg 15
It s hard to optimize something that you can t see 16
First step: Visualize the baton! Team 1 Team 2 Todo Doing Done this week Todo Doing Done this week Avg lead time: 20 days Avg lead time: 3 days Henrik Kniberg 17
Kaizen 18
Both are empirical Capacity (aka velocity) Lead time (aka cycle time) Quality (defect rate, etc) Predictability (SLA fulfillment, etc) Kanban is HIGHLY configurable Many small teams Few large teams Great! More options! Oh no, more decisions! Low WIP limits High WIP limits Few workflow states Many workflow states Short iterations Long iterations Little planning Lots of planning... etc...... etc... Henrik Kniberg 19
Almost always a good idea Visualize the workflow Limit WIP (work in process) Short feedback loops Focus on quality Cadences Henrik Kniberg 20
Exercise Pull 21
Limit work to capacity Input: 3 customers / hour Output capacity: 2 customers / hour Henrik Kniberg 22
Pull vs Push Assigning tasks = push Taking tasks = pull Push Pull Henrik Kniberg 23
Example: Supermarket pull Henrik Kniberg 24
Example: Feature pull Henrik Kniberg 25
Why feature pull is important Features and functions used in a typical system: Half of the features we build are never used! Never 45% Always 7% Rarely 19% Often 13% Sometimes 16% Source: Standish Group Study Reported at XP2002 by Jim Johnson, Chairman Henrik Kniberg 26
Kanban 27
Kanban 看 板 Visual Card Signaling system Visual Limited in supply Henrik Kniberg 28
Kanban @ Imperial Palace Gardens Henrik Kniberg 29
Kanban in your wallet Darn. Forgot to limit. Henrik Kniberg 30
Kanban @ Toyota Buyer Supplier Consume Detach Receive Ship Allocate Manufacture The tool used to operate the [Toyota Production] system is kanban. Taiichi Ohno Father of the Toyota Production System Henrik Kniberg 31
Kanban in SW development Visualize the workflow Limit WIP (work in progress) Measure & optimize flow Pioneered by David Anderson in 2004 Backlog Dev UAT Deploy Done 5 3 2 3 FLOW Avg lead time: 12 days Henrik Kniberg 32
Evolve your own board! Some of these photos courtesy of David Anderson, Mattias Skarin, and various other people Henrik Kniberg 33
One day in Kanban land 34
One day in Kanban land http://blog.crisp.se/henrikkniberg/tags/kanban/ Henrik Kniberg 35
Scenario 1 one piece flow Dev Backlog Next 3 2 Ongoing Done In production :o) G A B C J H M F L I K D E Henrik Kniberg 36
Scenario 1 one piece flow Dev Backlog Next 3 2 Ongoing Done In production :o) G F H J L M I K C D E A B Henrik Kniberg 37
Scenario 1 one piece flow Dev Backlog Next 3 2 Ongoing Done In production :o) G F H J L M I K C D E B A Henrik Kniberg 38
Scenario 1 one piece flow Dev Backlog Next 3 2 Ongoing Done In production :o) G C D B A F J H M L I K E Henrik Kniberg 39
Scenario 1 one piece flow. Dev Backlog Next 3 2 Ongoing Done In production :o) G D C B A F J H M L I K E Henrik Kniberg 40
Scenario 2 Deployment problem Dev Backlog Next 3 PO 2 Ongoing Done In production :o) G A B C J H M F L I K D E Henrik Kniberg 41
Scenario 2 Deployment problem Dev Backlog Next 3 PO 2 Ongoing Done In production :o) G F H J L M I K C D E A B Henrik Kniberg 42
Scenario 2 Deployment problem Dev Backlog Next 3 PO 2 Ongoing Done In production :o) G F C D A B J H M L I K E Henrik Kniberg 43
Scenario 2 Deployment problem Dev Backlog Next 3 PO 2 Ongoing Done In production :o) G D C B A F J H M L I K E Henrik Kniberg 44
Scenario 2 Deployment problem Dev Backlog Next 3 PO 2 Ongoing Done In production :o) G F D C!? A B J H M L I K E Henrik Kniberg 45
Scenario 2 Deployment problem Dev Backlog Nexet 3 PO 2 G D Ongoing!? Done A B In production :o) J H M F L I K E C Henrik Kniberg 46
Scenario 2 Deployment problem Dev Backlog Next 3 PO 2 Ongoing Done In production :o) G D A B J H M F L I K E C Henrik Kniberg 47
Scenario 2 Deployment problem Dev Backlog Next 3 PO 2 Ongoing Done In production :o) G D A B J H M F L I K E C Henrik Kniberg 48
Scenario 2 Deployment problem Dev Backlog Next 3 PO 2 Ongoing Done In production :o) G F H J L M I K D E C A B Henrik Kniberg 49
Bottlenecks 50
Theory of constraints Smooth Flow Goal Reality Strategy 51
Theory of constraints All systems have a bottleneck When you fix it, it jumps to somewhere elese. The whole system performs only as well as its bottleneck Ensure you have slack before & after the bottleneck Happens automatically with pull scheduling Use the slack to fix the bottleneck Henrik Kniberg 52
How to find your bottleneck Without WIP limits Busy at bottleneck Slack downstream Queue upstream Next Dev Test Integrate Deploy Expensive queue orem ipsum dolor Cheap queue With WIP limits Next 3 Dev 2 Test 2 Integrate Deploy 3 3 Henrik Kniberg 53
Knows a bit about many things Goal: T-shaped people Knows a lot about one thing I can test, but I m not so good at it. Lisa Joe Fred Jenny David Erik Team Skills matrix Test DB Web Java Domain CM I m good at Java! I don t know CM at all. But I m willing to learn! Henrik Kniberg 54
Kanban allows both specialists & generalists Backlog Design Fold Tape Trim Draw 3 2 2 1 4 3 Henrik Kniberg 55
Cumulative Flow Diagram (CFD) Day 4 Backlog Dev Test Prod Henrik Kniberg 56
Cadence 57
Daily standup meeting Source: Visual management blog Henrik Kniberg http://www.xqa.com.ar/visualmanagement/ 58 2009/04/daily-scrum-against-the-board/
Cadence Scrum team Kanban team 1 Plan & commit week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Sprint 1 Review (release?) Retrospective Sprint 2 Kanban team 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Retrospectives (4w) Planning cadence (2w) Release cadence (1w) Kanban team 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Retrospectives (4w) Planning (on demand) Release (on demand) Henrik Kniberg 59
Reduce transaction costs Next Dev Test Integrate Deploy 3 2 2 3 3 Trans cost Trans cost Cost of initializing test environment Cost of restarting server Economies of Scale We need to do big batches because transaction cost is high Economies of Flow (Lean) We need to minimize transaction cost so we can do smaller batches Automate init of test environment Implement hot-reload on server Henrik Kniberg 60
Quality 61
Quality Defects per unit of valued work Value demand Failure demand Henrik Kniberg 62
Lean principle: Stop the Line The build server is your friend! Really! Henrik Kniberg 63
Optimizing the WIP limit 64
Optimizing the WIP limit To do Doing Done People often idle Too low WIP limit 1 Slow flow (end-to-end) Zzzzzzzzz To do Doing Done Tasks rarely idle Just Right WIP limit 2 Fast flow To do Doing Done Too high WIP limit 5 People sometimes idle (slack) People never idle Slow flow Lack of wall space... Tasks often idle Henrik Kniberg 65
Use WIP limits to break vicious cycles Releasing is a Pain Release seldom Releasing is easy Release often Big releases Small releases WIP limits Long cycle time Low quality Short cycle time High quality High WIP Low WIP WIP limits Henrik Kniberg 66
Evolution of a Kanban board 67
Henrik Kniberg Next Analysis Development Acceptance Prod 2 3 3 2 Ongoing Kanban kick-start example Done 2009-09-01 sit amet, co sit nse amet, co nse adi pis cing elit nisl Ongoing 2009-08-30 sit amet, co adi pis cing elit nisl www.crisp.se/kanban/example 2009-09-08 Done Ongoing 2009-08-27 sit amet, adi pis cing elit nisl Done version 1.2 2009-11-16 2009-08-20 orem olor sit amet, co nse adi pis cing elit nisl xxxx kjd orem ipsum dj dolor d xxx 2009-09-02 Definition of Done: Goal is clear First tasks defined Story split (if necessary) 2009-08-29 sit amet, nse adi pis cing elit nisl Definition of Done: Code clean & checked in on trunk Integrated & regression tested Running on UAT environment Definition of Done: Customer accepted Ready for production 2009-08-25 sit adi pis cing elit nisl Feature / story Date when added to board 2009-08-20 2009-09-30 (description) Hard deadline (if applicable) = priority = panic Who is analyzing / testing right now Task / defect (description) (description) Why (description) (description) =task (description) = completed = blocked = who is doing this right now =defect What to pull first Panicfeatures (should be swarmed and kept moving. Interrupt other work and break WIP limits as necessary) Priority features Hard deadline features (only if deadline is at risk) Oldest features
Estimation & planning 69
Estimating is optional in Kanban Scrum Velocity = 11 4 2 1 4 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Kanban WIP limit = 3 Long running task Long running task Henrik Kniberg 70
Lightweight estimation techniques T-shirt sizing SLA service level agreement S M L S Hours? M Days? L Weeks? Example: SLA is 12 days Can we do this item within 12 days? If yes: just pull it in. If no: reject it, or break it down, or estimate/negotiate Henrik Kniberg 71
Example: estimation paradox Estimation is sometimes used to manage a problem that was caused by the estimation itself Prestudies, estimation, resource allocation, approval Develop, test, deploy 8 days work Process 5 months cycle time = 9 % cycle efficiency 5 month cycle time Scared of commitment 2 week cycle time Little fear of commitment Lots of Little or no estimation & estimation & WIP limits prestudy prestudy Henrik Kniberg 72
Using Kanban to visualize the problem Henrik Kniberg 73
Metrics 74
Metrics Cumulative Flow Diagram If we lower WIP limit from 6 to 2 in test we can probably halve the cycle time! WIP (work in progress) 3 4 6 3 Analyze Dev Test Deploy Release capacity (velocity) Last week we released8 things Average capacity during Q1 was 6 story points per week Quality Undecided 25% Value demand 15% Failure demand 60% Item #25 took 7 days Medium-sized MMFs take < 8 days 95% of the time. Cycle time Henrik Kniberg 75
Misc patterns & Tips & Tricks 76
Process = collection of policies Visible on the board Brief Continuously renegotiated as needed Created on-demand Examples: Definition of Done What to do when WIP limit is exceeded Who decides priorities When do we do planning? Which types of work items to we pull first Service level agreements Henrik Kniberg 77
2 tier board with feature swimlanes Henrik Kniberg 78 Source: David Anderson
2 tier board-within-board Henrik Kniberg 79 Source: David Anderson
Stopping dead projects FLOW Henrik Kniberg 80 Source: Mattias Skarin
Manager removing impediments 2 slots on manager s door If both are full, team can add a new one if they remove a less important one Team decides when issue is solved Henrik Kniberg 81 Source: Mattias Skarin
Bootstrapping Kanban 82
Typical Scrum => Kanban evolution Step 1 Step 2 Step 3 Feature Feature Feature Feature Feature Feature team 1 team 2 team 2 team 1 team 2 team 2 Scrum Scrum Scrum Scrum Scrum Scrum Feature team 1 Feature team 2 Feature team 2 Scrum Scrum Scrum Operations / support team Scrum Operations / support team Kanban Henrik Kniberg 83
Example: Kanbanizing a Scrum team Before sprint Sprint After sprint Henrik Kniberg 84
Kanban bootstrapping 1. Define your value stream Which part do you intend to control? Where is your input & output? 2. Define work item types 3. Meet with upstream & downstream stakeholders Policies, WIP limits Input coordination Output coordination Target cycle time (SLA service level agreement) 4. Create Kanban board (+ optionally electronic system) 5. Agree on time for daily standup 6. Agree on when to do retrospectives / operations reviews 7. Go! Iteratively improve. Task Henrik Kniberg 85 Bug
Wrapup 86
Recommendations Visualize existing process first, then optimize. Put the board in the team room Focus on exposing problems Keep the board clean & simple (just like your code...) Don t try to get it perfect from start. Let it evolve. Don t overuse metrics Involve the team & managers & stakeholders Take photos Make policies & agreements explicit. Negotiate. Consider getting a coach for Kanban bootstrapping Henrik Kniberg 87
The Lean & Agile toolkit Values & Principles Lean, Agile, Theory of Constraints, Systems Thinking, etc Kanban XP Other lean tools (Value Stream Mapping, Root Cause Analysis, etc) Scrum Henrik Kniberg 88
Perfection is a direction, not a place Henrik Kniberg 89
Expand your toolkit! www.crisp.se/utbildning Kanban starting points on the web: http://www.crisp.se/kanban http://www.limitedwipsociety.com Certified ScrumMaster & Kanban Feb 17-19 Kanban Applied Feb 23 Henrik Kniberg & Mattias Skarin Leading Lean Software Development March 4-5 Tom & Mary Poppendieck & Henrik Kniberg Kanban coaching workshop April 29-31 David Anderson Henrik Kniberg 90