Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Scrum vs. Kanban: Yes, This Again

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

Phil Ledgerwood

September 23, 2021
Tweet

Other Decks in Technology

Transcript

  1. - 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?
  2. - 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?
  3. - Scrum Guide 
 (https://scrumguides.org/ scrum-guide.html) - Kanban Guide 


    (https://kanbanguides.org/ html-kanban-guide/) PRIMARY SOURCES
  4. “I don’t believe in astrology. I’m a Sagittarius, and we’re

    skeptical.” 
 
 - Arthur C. Clarke MYTHCONCEPTIONS
  5. MYTHCONCEPTION #2: SCRUM IS BETTER FOR TEAMS NEW TO AGILE

    
 KANBAN IS BETTER FOR EXPERIENCED AGILE TEAMS
  6. “People say nothing is impossible, but I do nothing every

    day.” 
 
 - A.A. Milne WHAT’S REQUIRED?
  7. - 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
  8. - 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
  9. - 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…
  10. 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
  11. “I like work; it fascinates me. I can sit and

    look at it for hours.” 
 
 - Jerome K. Jerome LIMITING WIP
  12. - 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
  13. - 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
  14. 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
  15. - 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
  16. - 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
  17. 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
  18. BLABBEDY BLAH BLAH - WHICH ONE IS BEST, PHIL? SOME

    GUY IN THE FOURTH ROW, RIGHT NOW, 2021
  19. - 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
  20. - 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
  21. - 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
  22. - 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…
  23. - 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…
  24. - Phil Ledgerwood - Integrity Inspired Solutions - integrityinspired.com -

    [email protected] - LinkedIn: 
 www.linkedin.com/in/phil- ledgerwood/ OK, THAT’S PRETTY MUCH IT FOR NOW