Henrik Kniberg - risp gile coach & Java guy Kanban vs Scrum practical guide eep Lean, Stockholm May 19, 009 ofounder / TO of Goyada (mobile services) 30 developers Lead architect at ce Interactive (gaming) 0 developers hief of development at Tain (gaming) 40 developers gile coach at various companies henrik.kniberg@crisp.se +46 70 49584
Introduction Purpose of this presentation: larify Kanban and Scrum by comparing them...so you can figure out how these may come to use in your environment. Henrik Kniberg
Scrum in a nutshell Split your product Split your organization Optimize business value Large group spending a long time building a big thing Small team spending a little time building small thing... but integrating regularly to see the whole Optimize process $$$ Split time January pril $ Henrik Kniberg 3
Kanban in a nutshell Visualize the workflow Limit WIP (work in progress) Measure & optimize flow To do ev Test Release 5 H K 3 G LOW 3 one! Henrik Kniberg 4
Roots of Kanban (Toyota) uyer 看 板 Kan an Visual ard Supplier onsume etach Receive Ship llocate Manufacture The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban. Taiichi Ohno ather of the Toyota Production System Henrik Kniberg 5
Kanban in software development Henrik Kniberg 6
Kanban and Scrum are both process tools Physical tools Process tools a.k.a. organizational patterns Product Owner role Pair programming rownbag meetings Henrik Kniberg 7
Prescriptive vs adaptive More prescriptive More adaptive RUP (10+) XP (13) Scrum (9) Kanban (3) o Whatever (0) rchitecture Reviewer usiness esigner usiness-model Reviewer usiness-process nalyst apsule esigner hange ontrol Manager ode Reviewer onfiguration Manager ourse eveloper atabase esigner eployment Manager esign Reviewer esigner Graphic rtist Implementer Integrator Process ngineer Project Manager Project Reviewer Requirements Reviewer Requirements Specifier Software rchitect Stakeholder System dministrator System nalyst Technical Writer Test nalyst Test esigner Test Manager Tester Tool Specialist User-Interface esigner rchitectural analysis ssess Viability of architectural proof-of-concept apsule design lass design onstruct architectural proof-ofconcept atabase design escribe distribution escribe the run-time architecture esign test packages and classes evelop design guidelines evelop programming guidelines Identify design elements Identify design mechanisms Incorporate design elements Prioritize use cases Review the architecture Review the design Structure the implementation model Subsystem design Use-case analysis Use-case design nalysis model rchitectural proof-of-concept ill of materials usiness architecture document usiness case usiness glossary usiness modeling guidelines usiness object model usiness rules usiness use case usiness use case realization usiness use-case model usiness vision hange request onfiguration audit findings onfiguration management plan ata model eployment model eployment plan esign guidelines esign model evelopment case evelopment-organization assessment nd-user support mateirla Glossary Implementation model Installation artifacts Integration build plan Issues list Iteration assessment Iteration plan Manual styleguide Programming guidelines Quality assurance plan Reference architecture Release notes Requirements attributes Requirements management plan Review record Risk list Risk management plan Software architecture document Software development plan Software requirements specification Stakeholder requests Status assessment Supplementary business specification Supplementary specification Target organization assessment Test automation architecture Test cases Test environment configuration Test evaluation summary Test guidelines Test ideas list Test interface specification Test plan Test suite Tool guidelines Training materials Use case model Use case package Use-case modeling guidelines Use-case realization Use-case storyboard User-interface guidelines User-interface prototype Vision Work order Workload analysis model Whole team oding standard T ollective ownership ustomer tests Pair programming Refactoring Planning game ontinuous integration Simple design Sustainable pace Metaphor Small releases Scrum Master Product Owner Team Sprint planning meeting aily Scrum Sprint review Product backlogt Sprint backlog Urndown chart Miyamoto Musashi 17 th century samurai Visualize the workflow Limit WIP Measure and optimize lead time o not develop an attachment to any one weapon or any one school of fighting Henrik Kniberg 8
Scrum prescribes roles PO SM Henrik Kniberg 9
Scrum prescribes iterations week 1 week week 3 week 4 week 5 week 6 week 7 week 8 Scrum team Kanban team 1 Plan & commit Sprint 1 emo (release?) Retrospective Sprint Kanban team week 1 week week 3 week 4 week 5 week 6 week 7 week 8 Retrospectives (4w) Planning cadence (w) Release cadence (1w) Kanban team 3 week 1 week week 3 week 4 week 5 week 6 week 7 week 8 Retrospectives (4w) Planning (on demand) Release (on demand) Henrik Kniberg 10
oth limit WIP, but in different ways Scrum board Kanban board To do Ongoing one :o) To do Ongoing one :o) LOW LOW WIP limited per unit of time (iteration) WIP limited per workflow state Henrik Kniberg 11
oth are empirical apacity (aka velocity) Lead time (aka cycle time) Quality (defect rate, etc) Predictability (SL fulfillment, etc) Kanban is more configurable Many small teams ew large teams Great! More options! Oh no, more complicated! Low WIP limits High WIP limits ew workflow states Many workflow states Short iterations Long iterations Little planning Lots of planning... etc...... etc... Henrik Kniberg 1
xample: xperimenting with WIP limits Monday, Week 1 Monday, Week Monday, Week 3 Monday, Week 4 To do Ongoing one :o) 1 ZZZZzzzzzz We re idle & bored! Let s increase WIP limit to 8! Monday, Week 5 To do Ongoing one :o) N O P 4 L M J K To do Ongoing one :o) G 8 To do Ongoing one :o) H I 8 G Problem with integration server. an t finish &! We ll work on & G instead! To do Ongoing one :o) L 8 I J K Oops. WIP limit reached. Now we HV to stop and fix the integration server! Let s reduce WIP limit to 4, so we react earlier next time! Henrik Kniberg 13
Scrum doesn t allow change in mid-iteration Scrum Wait until next sprint! Kanban PO I d like to have! Wait until a To o slot becomes available! Or swap out or! To do Ongoing one :o) To do Ongoing one :o) LOW LOW Henrik Kniberg 14
Scrum board is reset between each iteration Scrum irst day of sprint Mid-sprint Last day of sprint Kanban ny day Henrik Kniberg 15
Scrum prescribes cross-functional teams Scrum Kanban example 1 Kanban example ross-functional team ross-functional team Specialist ross-functional team Specialist team Henrik Kniberg 16
Scrum backlog items must fit in a sprint Scrum Sprint 1 Sprint Sprint 3 Sprint 4 Kanban WIP limit = 3 Long running task Long running task Henrik Kniberg 17
In Scrum, estimation and velocity is prescribed V= 8 V= 7 V= 9 1 3 1 1 1 3 1 1 Likely velocity: 8 per sprint (sustainable pace?) Sprint 1 Sprint Sprint 3 Henrik Kniberg 18
oth allow working on multiple products simultaneously Scrum example 1 Kanban example 1 olor-coded tasks Green Product Green team Yellow Product Yellow team Scrum example Scrum example 3 ll products ross-product team ll products ross-product team Kanban example olor-coded swimlanes Henrik Kniberg 19
oth are Lean and gile 1. Individuals and Interactions over Processes and Tools. Working Software over omprehensive ocumentation 3. ustomer ollaboration over ontract Negotiation 4. Responding to hange over ollowing a Plan 1. ase your management decisions on a Long-Term Philosophy, ven at the xpense of Short-Term inancial Goals. reate ontinuous Process low to ring Problems to the Surface 3. Use Pull Systems to void Overproduction 4. Level Out the Workload (Heijunka) 5. uild a ulture of Stopping to ix Problems, to Get Quality Right the irst Time 6. Standardized Tasks are the oundation for ontinuous Improvement and mployee mpowerment 7. Use Visual ontrols So No Problems are Hidden 8. Use Only Reliable, Thoroughly Tested Technology That Serves Your People and Processes 9. Grow Leaders Who Thoroughly Understand the Work, Live the Philosophy, and Teach It to Others 10. evelop xceptional People and Teams Who ollow Your ompany s Philosophy 11. Respect Your xtended Network of Partners and Suppliers by hallenging Them and Helping Them Improve 1. Go and See for Yourself to Thoroughly Understand the Situation (Genchi Genbutsu) 13. Make ecisions Slowly by oncensus, Thoroughly onsidering ll Options; Implement ecisions Rapidly 14. ecome a Learning Organization Through Relentless Reflection (Hansei) and ontinuous Improvement (Kaizen) Lean Quality ost Lead Time People Just in Time Kaizen Stop the Line Waste reduction Henrik Kniberg 0 Operational stability
Minor difference: Scrum prescribes a prioritized product backlog Scrum: Product backlog must exist hanges to product backlog take effect next sprint (not current sprint) Product backlog must be sorted by business value... but many teams combine these approaches Kanban: Product backlog is optional hanges to product backlog take effect as soon as capacity becomes available ny prioritization scheme can be used. or example: Take any item lways take the top item lways take the oldest item 0% on maintainance items, 80% on new features Split capacity evenly between product and product lways take red items first Henrik Kniberg 1
Minor difference: Scrum prescribes daily meetings... but many Kanban teams do that anyway. Henrik Kniberg
Minor difference: In Scrum, burndown charts are prescribed No specific types of diagrams prescribed in Kanban. Teams use whatever they need. Henrik Kniberg 3
xample: Scrum board vs Kanban board Scrum Product backlog G H G J M HL I K Sprint backlog ommitted Ongoing one :o) Kanban ev acklog Selected 3 Ongoing one In production :o) H J M L G I K X Q R Henrik Kniberg 4
Scenario 1 one piece flow ev acklog Selected 3 Ongoing one In production :o) G J H M L I K Henrik Kniberg 5
Scenario 1 one piece flow ev acklog Selected 3 Ongoing one In production :o) G H J L M I K Henrik Kniberg 6
Scenario 1 one piece flow ev acklog Selected 3 Ongoing one In production :o) G H J L M I K Henrik Kniberg 7
Scenario 1 one piece flow ev acklog Selected 3 Ongoing one In production :o) G J H M L I K Henrik Kniberg 8
Scenario 1 one piece flow ev acklog Selected 3 Ongoing one In production :o) G J H M L I K Henrik Kniberg 9
Scenario 1 one piece flow ev acklog Selected 3 Ongoing one In production :o) G J H M L I K Henrik Kniberg 30
Scenario eployment problem ev acklog Selected 3 Ongoing one In production :o) G J H M L I K Henrik Kniberg 31
Scenario eployment problem ev acklog Selected 3 Ongoing one In production :o) G H J L M I K Henrik Kniberg 3
Scenario eployment problem ev acklog Selected 3 Ongoing one In production :o) G J H M L I K Henrik Kniberg 33
Scenario eployment problem ev acklog Selected 3 Ongoing one In production :o) G J H M L I K Henrik Kniberg 34
Scenario eployment problem ev acklog Selected 3 Ongoing one In production :o) G!? J H M L I K Henrik Kniberg 35
Scenario eployment problem ev acklog Selected 3 Ongoing G!? one In production :o) J H M L I K Henrik Kniberg 36
Scenario eployment problem ev acklog Selected 3 Ongoing one In production :o) G J H M L I K Henrik Kniberg 37
Scenario eployment problem ev acklog Selected 3 Ongoing one In production :o) G J H M L I K Henrik Kniberg 38
Scenario eployment problem ev acklog Selected 3 Ongoing one In production :o) G H J L M I K Henrik Kniberg 39
Kanban vs Scrum Summary Similarities oth are Lean and gile oth based on pull scheduling oth limit WIP oth use transparency to drive process improvement oth focus on delivering releasable software early and often oth are based on self-organizing teams oth require breaking the work into pieces In both cases the release plan is continuously optimized based on empirical data (velocity / lead time) www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf ifferences Scrum Timeboxed iterations prescribed. Kanban Timeboxed iterations optional. Team commits to a specific amount ommitment optional. of work for this iteration. Uses Velocity as default metric for Uses Lead time as default metric for planning and process improvement. planning and process improvement. ross-functional teams ross-functional teams optional. prescribed. Specialist teams allowed. Items broken down so they can be No particular item size is prescribed. completed within 1 sprint. urndown chart prescribed No particular type of diagram is prescribed WIP limited indirectly (per sprint) WIP limited directly (per workflow state) stimation prescribed stimation optional annot add items to ongoing an add new items whenever iteration. capacity is available sprint backlog is owned by one kanban board may be shared specific team by multiple teams or individuals Prescribes 3 roles (PO/SM/Team) oesn t prescribe any roles Scrum board is reset between kanban board is persistent each sprint Prescribes a prioritized product Prioritization is optional. 40 backlog Henrik Kniberg 40
Most importantly: Start with retrospectives! volve the right process for your context. on t worry about getting it right from the start. xpand your toolkit. xperiment! Henrik Kniberg 41