Scrum vs. Kanban: Yes, This Again

If you find yourself in an awkward social situation at a conference, ask aloud, "Hey, is Scrum better than Kanban?" and duck out of the room in the ensuing chaos.

Strong opinions exist on both sides of this fence, and as the data comes in, we've come to see that agile teams all over the world have been successful with either.

However, the fact that successful teams on both sides exist doesn't help you decide which is right for -your- team, and the patterns are not interchangeable. As SAFe and other scaling paradigms become more popular, even individual teams within the same organization may operate best using different structures.

In this session, we'll look at Scrum and Kanban, not to prove that one is better, but to point out how they tackle problems in different ways using different assumptions about the workflow. By seeing which more accurately fits your work, it may help you decide which to try.

You'll learn:
- Misconceptions about both sides that only prove marketing is evil
- How Scrum and Kanban make work visible
- How Scrum and Kanban deal with planning and projecting timelines
- How Scrum and Kanban deal with limiting work in progress
- How Scrum and Kanban deal with changing priorities
- Stuff Scrum deals with that Kanban does not
- Common crossover practices
- Workflow characteristics that may fit one scheme better than another

Transcript

1. PHIL LEDGERWOOD Yes, this again. SCRUM VS. KANBAN
3. - New to the whole Scrum or Kanban thing? - Already doing one or the other and thinking about switching? - Looking for a fi ght? - Trying to fi nd the least mentally taxing presentation at the end of the day? WHO ARE YOU?
4. - Owner of Integrity Inspired Solutions - Software Developer - Product / Project / Operational Manager - Agile Coachish Thing Whatever - Certi fi ed ProKanban Trainer - Certi fi ed Scrum Master WHO AM I?
5. A BRIEF WORD ABOUT MY BIASES…
6. - Scrum Guide 
 (https://scrumguides.org/ scrum-guide.html) - Kanban Guide 
 (https://kanbanguides.org/ html-kanban-guide/) PRIMARY SOURCES
7. “I don’t believe in astrology. I’m a Sagittarius, and we’re skeptical.” 
 
 - Arthur C. Clarke MYTHCONCEPTIONS
8. MYTHCONCEPTION #1: 
 KANBAN IS BETTER FOR SUPPORT 
 SCRUM IS BETTER FOR FEATURE DEVELOPMENT
9. MYTHCONCEPTION #2: SCRUM IS BETTER FOR TEAMS NEW TO AGILE 
 KANBAN IS BETTER FOR EXPERIENCED AGILE TEAMS
10. “People say nothing is impossible, but I do nothing every day.” 
 
 - A.A. Milne WHAT’S REQUIRED?
11. - Five values - Commitment, Focus, Openness, Respect, Courage - Three roles - Developers, Product Owner, Scrum Master - Five “events” (including time limits, structure, rules, and goals for each) - The Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective - Three “artifacts” - Product Backlog, Sprint Backlog, Increment SCRUM MANDATES
12. - De fi nition of Work fl ow (DoW) - Work Items, Start and Stop, WIP Stages, WIP Control, Explicit Policies, SLE - A Visualization of the DoW (Kanban Board) - Continuous Improvement - Flow Metrics - WIP, Throughput, Work Item Age, Cycle Time KANBAN MANDATES
13. - Have some kind of short, daily interaction around identifying and resolving work fl ow issues - Have some regular demonstration of the incremental development of the product - Use a retrospective-like mechanism for continuous improvement - Just because Scrum or Kanban may not -mandate- a practice doesn’t mean teams can’t do it; Kanban teams often incorporate some Scrum practices and vice-versa KANBAN TEAMS STILL USUALLY…
14. PRIME EXAMPLE THE KANBAN BOARD
15. MANDATE COMPARISON Scrum Kanban Mandates quite a bit of the process (roles, meetings, time limits, etc.) Restricts itself to work fl ow management (stages, WIP limits, metrics, etc.) Tends to tell you what to do with these categories Tends to say, “Make sure you do something with these categories.” Ready to go out of the box Teams/orgs have to come up with their own practices and standards Teams tend to look and run the same Team outputs look the same but internal practices can vary
16. “I like work; it fascinates me. I can sit and look at it for hours.” 
 
 - Jerome K. Jerome LIMITING WIP
17. - De fi ne a span of time known as the “Sprint” (less than 1 month) - Create an overarching goal for the Sprint to which the team commits - Forecast how much work can be completed in the Sprint - Come up with a Sprint Plan HOW SCRUM DOES IT
18. - A numerical limit is set on how much work can be in progress at once - Can be per column, per group of columns, and/or for the whole board HOW KANBAN DOES IT
19. WIP LIMITING COMPARISON Scrum Kanban Timeframe driven: 
 What can we get done by the end of the Sprint? Throughput driven: 
 How much can we have going on and still be e ff i cient? Requires estimating size/ duration Does not require estimating size/duration Can change priorities between sprints Can change priorities between items Has de fi nitive starts and stops between planned chunks of work Continuous fl ow
20. “Prediction is very difficult, especially about the future.” 
 
 - Niels Bohr PREDICTING THE FUTURE
21. - Scrum recommends no particular forecasting mechanism, only that forecasting must happen to construct the Sprint Plan - Story Points, Planning Poker, Velocity etc. are NOT part of Scrum, but they are common - Velocity Method: - Each user story is assigned a Story Point value. - Story Points are just labels for sizing buckets. They are not units of measurement and have no correspondence to a length of time or proportionality to each other. 
 
 Ex. Stories assigned a 1 are your smallest stories, 8s are your largest, and 2s 3s and 5s are gradations in the middle. - Velocity is the trend of the total number of Story Points of delivered user stories each Sprint. - This trend is used to forecast the total number of Story Points for the next Sprint. HOW SCRUM DOES IT
22. - An SLE for the completion of individual items is generated from historical cycle time data 
 
 Example: Items will be completed in 12 days or less 85% of the time. 
 - Throughput data is used to project completion rates of groups of items (features, projects, etc) 
 
 Example: This team usually completes 3 cards per week. There are 18 cards remaining in this MVP, so they will probably be done in 6 weeks. 
 - Using throughput data, Monte Carlo simulations can be run to predict likely project completion times 
 
 Example: 85% of our simulations had us fi nishing by March 12 or earlier. HOW KANBAN DOES IT
23. PREDICTION COMPARISON Scrum 
 (Velocity Method) Kanban Uses historical rate of completion to project future rate of completion. 
 Also uses historical rate of completion to project future rate of completion. Story Points per Sprint Items per Day Requires correctly sizing stories up front Does not require any sizing, guessing, or estimating Requires fair amount of discussion to be able to size the stories Requires no discussion Assumes work can be quanti fi ed before starting Assumes work can only be quanti fi ed after completion
24. BLABBEDY BLAH BLAH - WHICH ONE IS BEST, PHIL? SOME GUY IN THE FOURTH ROW, RIGHT NOW, 2021
25. - What are you trying to accomplish with this decision? - Is the team already familiar with one or the other? - Is this a good time to make big changes to work fl ow? - Are you successful at guessing how long work will take? - How much do you want to rock the boat mindset-wise? PERTINENT QUESTIONS
26. - Easing a team/org out of Waterfall - Already familiar with Scrum - Team is uncomfortable with self-management - The need to be responsive to change is lower - Initial easier sell to large orgs due to popularity WHERE SCRUM TENDS TO FIT
27. - Work does not always fi t into sprints or is di ff i cult to plan - Responsiveness to change must be high - Team is comfortable building their own standards and practices - Throughput predictability is very important WHERE KANBAN TENDS TO FIT
28. - Make sure you understand the “why” behind each practice and what the goal of it is. Don’t just learn the practices. - Watch out for command & control culture using Scrum to perpetuate itself. Fight for the autonomy of self-managed teams. - Don’t let Scrum become Waterfall in Two-Week Installments. - There are a lot of things people have added to Scrum that are not helpful (e.g. Story Points, Sprint Backlog commitments, the Three Questions, Capacity Planning). Stick to the Scrum Guide for your basic framework and experiment freely with what works for you. - Keep an eye out for when it’s time to stop doing Scrum. IF YOU GO SCRUM…
29. - Your teams need to write explicit policies. - Kanban usually removes the arti fi cial ways that orgs create a sense of urgency. Find new and legitimate ones. - There are a lot of things your team and org will need that Kanban will not provide. Don’t be afraid to add things that are valuable. Learn and steal from other systems. - Do all the Kanban stu ff . Don’t pick and choose. Ease into it if you have to, but incorporate all of it. - Try not to be snobs around your Scrum friends. IF YOU GO KANBAN…
30. - Phil Ledgerwood - Integrity Inspired Solutions - integrityinspired.com - phil@integrityinspired.com - LinkedIn: 
 www.linkedin.com/in/phil- ledgerwood/ OK, THAT’S PRETTY MUCH IT FOR NOW