Kanban vs Scrum Making the most of both QCon, San Francisco Nov 18, 2009 Henrik Kniberg Agile/Lean coach @ Crisp, Stockholm http://www.crisp.se/henrik.kniberg Background: developer, manager, entreprenuer Board of directors henrik.kniberg@crisp.se +46 70 4925284
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 2
Split your organization Scrum in a nutshell Split your product 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 Optimize business value $$$ Split time April January $ Henrik Kniberg 3 3
Typical Scrumboard Henrik Kniberg 4 4
the unofficial The bottom line Core Scrum Scr crum Checkli list st If you achieve these you can ignore the These are central to Scrum. Without these rest of the checklist. Your process is fine. you probably shouldn’t call it Scrum. Delivering working, tested Retrospective happens after software every 4 weeks or less every sprint Henrik Kniberg Results in concrete Delivering what the improvement proposals business needs most Recommended but not always necessary Some proposals actually Process is get implemented Most of these will usually be needed, but not always all of them. Experiment! continuously improving Whole team + PO Team has all skills needed to PBL items are broken into participates bring backlog items to Done tasks within a sprint PO has a product backlog Clearly defined product owner Team members not locked into Sprint tasks are estimated (PBL) (PO) specific roles Top items are prioritized PO is empowered to Iterations that are doomed to Estimates for ongoing tasks by business value prioritize fail are terminated early are updated daily PO has knowledge to Top items are estimated PO has product vision that is in prioritize Velocity is measured sync with PBL Estimates written by the PO has direct contact with PBL and product vision is highly All items in sprint plan have team team visible an estimate Top items in PBL small PO has direct contact with PO uses velocity for enough to fit in a sprint Everyone on the team stakeholders release planning participates in estimating PO understands purpose PO speaks with one voice Velocity only includes of all backlog items PO available when team is (in case PO is a team) items that are Done estimating Have sprint planning meetings Estimate relative size (story Team has a sprint backlog Team has a sprint burndown points) rather than time chart PO participates Highly visible Whole team knows top 1-3 Highly visible impediments PO brings up-to-date PBL Updated daily SM has strategy for how to Updated daily fix top impediment Owned exclusively by the Whole team participates SM focusing on removing team Daily Scrum is every day, same impediments time & place Results in a sprint plan Escalated to management PO participates at least a Daily Scrum happens when team can’t solve Whole team believes plan few times per week is achievable Whole team participates Team has a Scrum Master (SM) Max 15 minutes PO satisfied with priorities Problems & impediments Each team member knows SM sits with the team are surfaced what the others are doing Timeboxed iterations Demo happens after every Positive indicators Scaling Iteration length 4 weeks or sprint less Leading indicators of a These are pretty fundamental to any Shows working, tested good Scrum implementation. Scrum scaling effort. software Always end on time Feedback received from You have a Chief Product Team not disrupted or Having fun! High energy level. stakeholders & PO Owner (if many POs) controlled by outsiders Dependent teams do Scrum of Overtime work is rare and Team usually delivers Scrums happens voluntarily Have Definition of Done (DoD) what they committed to Dependent teams integrate Discussing, criticizing, and Henrik Kniberg 5 5 DoD achievable within within each sprint experimenting with the process Team members sit together each iteration PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done Team respects DoD Max 9 people per team http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17)
Typical waterfall => Scrum evolution 3. Scrum 1. Waterfall 2. ”Scrum But” PO Requirements Requirements Feature Feature team 1 team 2 Design & code Design Code Test Test Henrik Kniberg 6 6
Kanban in a nutshell To do Dev Test Release Done! 3 2 3 5 Visualize the workflow H D C A G Limit WIP (work in progress) B K Measure & optimize flow FLOW FLOW Useful starting point for more info: http://www.limitedwipsociety.org 7 7
看板 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 8
Kanban in software development Henrik Kniberg 9 9
Typical Scrum => Kanban evolution Scrum step 1 Scrum step 2 Scrum + Kanban Feature Feature Feature Feature Feature Feature Feature Feature Feature team 1 team 2 team 2 team 1 team 2 team 2 team 1 team 2 team 2 Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum Scrum Operations / support team Operations / support team Scrum Kanban Henrik Kniberg 10 10
Thinking tools a.k.a. ”mindsets” or ”philosophies” Tool Toolkits Agile Systems Thinking Lean ”anything used as a means of a.k.a. ”frameworks” Theory of Constraints accomplishing a task or purpose.” RUP - dictionary.com XP Scrum Physical tools Kanban Process tools a.k.a. ”organizational patterns” Product Owner role Pair programming Visualize the workflow To do Dev Test Release Done! 5 3 3 2 H D C A G B K FLOW Henrik Kniberg 11 11
Can we compare Kanban and Scrum? Should we? Henrik Kniberg 12 12
Any tool can be misused The old tool was better! Never blame the tool! 13 Henrik Kniberg 13
Recommend
More recommend
