Kanban vs Scrum Making the most of both

Transcription

1 Kanban vs Scrum Making the most of both QCon, San Francisco Nov 18, 2009 Henrik Kniberg Agile/Lean Crisp, Stockholm Background: developer, manager, entreprenuer Board of directors henrik.kniberg@crisp.se

2 Purpose of this presentation To clarify Kanban and Scrum by comparing them...so you can figure out how these may come to use in your context. Henrik Kniberg 2

3 Scrum in a nutshell Split your product Split your organization Optimize business value Large group spending a long time building a huge thing Small team spending a little time building a small thing... but integrating regularly to see the whole Optimize process $$$ Split time January April $ Henrik Kniberg 3

4 Typical Scrumboard Henrik Kniberg 4

5 The bottom line If you achieve these you can ignore the rest of the checklist. Your process is fine. Delivering working, tested software every 4 weeks or less Delivering what the business needs most Process is continuously improving Clearly defined product owner (PO) PO is empowered to prioritize PO has knowledge to prioritize PO has direct contact with team PO has direct contact with stakeholders PO speaks with one voice (in case PO is a team) Team has a sprint backlog Highly visible Updated daily Owned exclusively by the team Daily Scrum happens Whole team participates Problems & impediments are surfaced Demo happens after every sprint Shows working, tested software Feedback received from stakeholders & PO Have Definition of Done (DoD) DoD achievable within within each sprint each Henrik iteration Kniberg Team members sit together experimenting with the process 5 Team respects DoD Core Scrum These are central to Scrum. Without these you probably shouldn t call it Scrum. Retrospective happens after every sprint Results in concrete improvement proposals Some proposals actually get implemented Whole team + PO participates PO has a product backlog (PBL) Top items are prioritized by business value Top items are estimated Estimates written by the team Top items in PBL small enough to fit in a sprint PO understands purpose of all backlog items Have sprint planning meetings PO participates PO brings up-to-date PBL Whole team participates Results in a sprint plan Whole team believes plan is achievable PO satisfied with priorities Timeboxed iterations Iteration length 4 weeks or less Always end on time Team not disrupted or controlled by outsiders Team usually delivers what they committed to Max 9 people per team the unofficial Scrum Checklist Recommended but not always necessary Most of these will usually be needed, but not always all of them. Experiment! Scaling Team has all skills needed to bring backlog items to Done Team members not locked into specific roles Iterations that are doomed to fail are terminated early PO has product vision that is in sync with PBL PBL and product vision is highly visible Everyone on the team participates in estimating PO available when team is estimating Estimate relative size (story points) rather than time Whole team knows top 1-3 impediments SM has strategy for how to fix top impediment SM focusing on removing impediments Escalated to management when team can t solve Team has a Scrum Master (SM) SM sits with the team These are pretty fundamental to any Scrum scaling effort. You have a Chief Product Owner (if many POs) Dependent teams do Scrum of Scrums Dependent teams integrate Henrik Kniberg PBL items are broken into tasks within a sprint Sprint tasks are estimated Estimates for ongoing tasks are updated daily Velocity is measured All items in sprint plan have an estimate PO uses velocity for release planning Velocity only includes items that are Done Team has a sprint burndown chart Highly visible Updated daily Daily Scrum is every day, same time & place PO participates at least a few times per week Max 15 minutes Each team member knows what the others are doing Positive indicators Leading indicators of a good Scrum implementation. Having fun! High energy level. Overtime work is rare and happens voluntarily Discussing, criticizing, and PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done Version 2.1 ( )

6 Typical waterfall => Scrum evolution 1. Waterfall 2. Scrum But 3. Scrum Requirements Requirements PO Feature team 1 Feature team 2 Design Design & code Code Test Test Henrik Kniberg 6

7 Kanban in a nutshell Visualize the workflow Limit WIP (work in progress) Measure & optimize flow To do Dev Test Release H K G D FLOW C Done! A B Useful starting point for more info: 7

8 Roots of Kanban 看 板 Kan Ban Visual Card Buyer Supplier Consume Detach Receive Ship Allocate 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 Father of the Toyota Production System Henrik Kniberg 8

9 Kanban in software development Henrik Kniberg 9

10 Typical Scrum => Kanban evolution Scrum step 1 Scrum step 2 Scrum + Kanban 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 10

11 Tool anything used as a means of accomplishing a task or purpose. -dictionary.com Physical tools Thinking tools a.k.a. mindsets or philosophies Lean Agile Systems Thinking Theory of Constraints Toolkits a.k.a. frameworks Scrum RUP XP Kanban Process tools a.k.a. organizational patterns Product Owner role Pair programming Visualize the workflow To do Dev Test Release H D C G K Done! A B Henrik Kniberg 11 FLOW

12 Can we compare Kanban and Scrum? Should we? Henrik Kniberg 12

13 Any tool can be misused The old tool was better! Never blame the tool! 13 Henrik Kniberg 13

14 Compare for understanding, not judgement More prescriptive More adaptive RUP (120+) XP (13) Scrum (9) Kanban (3) Do Whatever (0) Architecture Reviewer Business Designer Business-Model Reviewer Business-Process Analyst Capsule Designer Change Control Manager Code Reviewer Configuration Manager Course Developer Database Designer Deployment Manager Design Reviewer Designer Graphic Artist Implementer Integrator Process Engineer Project Manager Project Reviewer Requirements Reviewer Requirements Specifier Software Architect Stakeholder System Administrator System Analyst Technical Writer Test Analyst Test Designer Test Manager Tester Tool Specialist User-Interface Designer Architectural analysis Assess Viability of architectural proof-of-concept Capsule design Class design Construct architectural proof-ofconcept Database design Describe distribution Describe the run-time architecture Design test packages and classes Develop design guidelines Develop 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 Analysis model Architectural proof-of-concept Bill of materials Business architecture document Business case Business glossary Business modeling guidelines Business object model Henrik Business rules Kniberg Work order 14 Business use case Business use case realization Business use-case model Business vision Change request Configuration audit findings Configuration management plan Data model Deployment model Deployment plan Design guidelines Design model Development case Development-organization assessment End-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 Workload analysis model Whole team Coding standard TDD Collective ownership Customer tests Pair programming Refactoring Planning game Continuous integration Simple design Sustainable pace Metaphor Small releases Scrum Master Product Owner Team Sprint planning meeting Daily Scrum Sprint review Product backlogt Sprint backlog BUrndown chart Miyamoto Musashi 17 th century samurai Visualize the workflow Limit WIP Measure and optimize lead time Do not develop an attachment to any one weapon or any one school of fighting

15 Distinguish the tool itself from specific usage techniques Specific patterns, techniques, best practices, etc Scrum core Kanban core Henrik Kniberg 15

16 Scrum prescribes 3 roles Product owner Team Scrum Master PO SM Henrik Kniberg 16

17 Scrum prescribes timeboxed iterations 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 17

18 Both limit WIP, but in different ways Scrum board Kanban board To do Ongoing Done :o) A To do Ongoing Done :o) 2 A B B C C D D FLOW FLOW WIP limited per unit of time (iteration) WIP limited per workflow state Henrik Kniberg 18

19 Both are empirical Capacity (aka velocity) Lead time (aka cycle time) Quality (defect rate, etc) Predictability (SLA fulfillment, etc) Kanban is more 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

20 Scrum discourages change in mid-iteration Scrum Wait until next sprint! Kanban PO I d like to have E! Wait until a ToDo slot becomes available! Or swap out C or D! To do C D Ongoing Done :o) A B To do 2 C D Ongoing Done :o) 2 A B FLOW FLOW Policies Henrik Kniberg 20

21 Scrum board is reset between each iteration Scrum First day of sprint Mid-sprint Last day of sprint Kanban Any day Henrik Kniberg 21

22 Scrum prescribes cross-functional teams Scrum team Kanban team 1 Kanban team 2 Cross-functional team Specialist Cross-functional team Specialist team Henrik Kniberg 22

23 Scrum backlog items must fit in a sprint Scrum Sprint 1 Sprint 2 Sprint 3 Sprint 4 Kanban WIP limit = 3 Long running task Long running task Henrik Kniberg 23

24 Scrum prescribes estimation and velocity V= 8 V= 7 V= Likely velocity: 8 per sprint (sustainable pace?) Sprint 1 Sprint 2 Sprint 3 Henrik Kniberg 24

25 Both allow working on multiple products simultaneously Scrum example 1 Green Product Yellow Product Green team Yellow team Kanban example 1 Color-coded tasks Scrum example 2 Scrum example 3 All products Cross-product team All products Cross-product team Kanban example 2 Color-coded swimlanes Henrik Kniberg 25

26 Both are Lean and Agile Agile Manifesto 1. Individuals and Interactions over Processes and Tools 2. Working Software over Comprehensive Documentation 3. Customer Collaboration over Contract Negotiation 4. Responding to Change over Following a Plan Henrik Kniberg The Toyota Way 1. Base your management decisions on a Long-Term Philosophy, Even at the Expense of Short-Term Financial Goals 2. Create Continuous Process Flow to Bring Problems to the Surface 3. Use Pull Systems to Avoid Overproduction 4. Level Out the Workload (Heijunka) 5. Build a Culture of Stopping to Fix Problems, to Get Quality Right the First Time 6. Standardized Tasks are the Foundation for Continuous Improvement and Employee Empowerment 7. Use Visual Controls 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. Develop Exceptional People and Teams Who Follow Your Company s Philosophy 11. Respect Your Extended Network of Partners and Suppliers by Challenging Them and Helping Them Improve 12. Go and See for Yourself to Thoroughly Understand the Situation (Genchi Genbutsu) 13. Make Decisions Slowly by Concensus, Thoroughly Considering All Options; Implement Decisions Rapidly 14. Become a Learning Organization Through Relentless Reflection (Hansei) and Continuous Improvement (Kaizen) 26

27 Minor difference: Scrum prescribes a prioritized product backlog Scrum: Product backlog must exist Changes to product backlog take effect next sprint (not current sprint) Product backlog must be sorted by business value Kanban: Product backlog is optional Changes to product backlog take effect as soon as capacity becomes available Any prioritization scheme can be used. For example: Take any item Always take the top item Always take the oldest item 20% on maintainance items, 80% on new features Split capacity evenly between product A and product B Always take red items first Policies Henrik Kniberg 27

28 Minor difference: Scrum prescribes daily meetings... but many Kanban teams do that anyway. Henrik Kniberg 28

29 Minor difference: In Scrum, burndown charts are prescribed No specific types of diagrams prescribed in Kanban. Teams use whatever they need. Cumulative Flow Henrik Kniberg 29

30 Evolve your own unique board! Some of these photos courtesy of David Anderson, Mattias Skarin, and various other people Henrik Kniberg 30

31 Henrik Kniberg Next Analysis Development Acceptance Prod Ongoing Kanban kick-start example Done orem ipsum dolor sit orem ipsum dolor amet, co sit nse amet, ctetur co nse ctetur adi pis cing elit nisl Ongoing orem ipsum dolor sit amet, co adi pis cing elit nisl orem ipsum dolor sit amet, co nse ctetur Done Ongoing orem ipsum dolor sit amet, adi pis cing elit nisl Done version orem olor sit amet, co nse ctetur adi pis cing elit nisl orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur xxxx kjd orem ipsum dj dolor d xxx sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse Definition of Done: Goal is clear First tasks defined Story split (if necessary) orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl orem ipsum dolor orem ipsum dolor sit amet, co nse sit amet, co nse ctetur ctetur Definition of Done: Code clean & checked in on trunk Integrated & regression tested Running on UAT environment Definition of Done: Customer accepted Ready for production orem ipsum dolor sit ctetur adi pis cing elit nisl Feature / story Date when added to board (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 1. Panicfeatures (should be swarmed and kept moving. Interrupt other work and break WIP limits as necessary) 2. Priority features 3. Hard deadline features (only if deadline is at risk) 4. Oldest features

32 Comparison: Typical Scrum board & Kanban board Scrum Product backlog E E F F G H G J M HL I K Sprint backlog Committed Ongoing B C D Done :o) A? Kanban Dev Backlog Next 3 2 Ongoing Done In production :o) H J M F L G I K D E B C A X Q R Henrik Kniberg 32

33 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 33

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

35 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 35

36 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 36

37 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 37

38 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 38

39 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 39

40 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 40

41 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 41

42 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 42

43 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 43

44 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 44

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

46 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 46

47 One day in Kanban land Henrik Kniberg 47

48 Kanban & Scrum Comparison summary Similarities Both are Lean and Agile 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 self-organizing teams Both require breaking the work into pieces In both cases the release plan is continuously optimized based on empirical data (velocity / lead time) Differences Scrum 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 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 Henrik Kniberg Prescribes a prioritized product Prioritization is optional. 48 backlog

49 Don t be dogmatic Go away! Don t talk to us! We re in a Sprint. Come back in 3 weeks. Though Shalt Limit WIP Henrik Kniberg 49

50 Essential skills needed for both Kanban and Scrum Retrospectives Splitting the system into deliverable increments Software craftsmanship Teams not businessoriented Teams grouped by component Root-cause analysis Teams not focused Team not getting feedback from customer Lack of team spirit Teams don t have own PO Ineffective requirements communication Too much focus on written specs POdoesn t have own team Unclear roles & responsibilities Lack of discipline in teams Feature split across multiple teams Hard to plan Delayed releases Lack of transparancy No burndowns Fear of committing Bad throughput in development Problems estimating Not measuring velocity Cutting quality instead of scope Difficult to release Teams disrupted during sprint Many defects Lack of test automation Hard to change the code Many operational problems Customers dissatisfied Henrik Kniberg 50

51 Take-away points 1. Know your goal Hint: Agile/Lean/Kanban/Scrum isn t it. 2. Never blame the tool Tools don t fail or succeed. People do. There is no such thing as a good or bad tool. Only good or bad decisions about when, where, how, and why to use which tool. 3. Don t limit yourself to one tool Learn as many as possible. Compare for understanding, not judgement. 4. Experiment & enjoy the ride Don t worry about getting it right from start. The only real failure is the failure to learn from failure. Henrik Kniberg 51

52 Henrik Kniberg 52