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
   

   View Slide

2. View Slide

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?
   

   View Slide

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?
   

   View Slide

5. A BRIEF WORD ABOUT MY BIASES…
   

   View Slide

6. - Scrum Guide
   

   (https://scrumguides.org/
   scrum-guide.html)
   
   
   - Kanban Guide
   

   (https://kanbanguides.org/
   html-kanban-guide/)
   PRIMARY SOURCES
   

   View Slide

7. “I don’t believe in
   astrology. I’m a
   Sagittarius, and we’re
   skeptical.”
   

   

   - Arthur C. Clarke
   MYTHCONCEPTIONS
   

   View Slide

8. MYTHCONCEPTION #1:
   

   KANBAN IS BETTER FOR SUPPORT
   

   SCRUM IS BETTER FOR FEATURE DEVELOPMENT
   

   View Slide

9. MYTHCONCEPTION #2:
   
   
   SCRUM IS BETTER FOR TEAMS NEW TO AGILE
   

   KANBAN IS BETTER FOR EXPERIENCED AGILE TEAMS
   

   View Slide

10. “People say nothing is
    impossible, but I do
    nothing every day.”
    

    

    - A.A. Milne
    WHAT’S REQUIRED?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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…
    

    View Slide

14. PRIME EXAMPLE
    THE KANBAN BOARD
    

    View Slide

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
    

    View Slide

16. “I like work; it fascinates
    me. I can sit and look at
    it for hours.”
    

    

    - Jerome K. Jerome
    LIMITING WIP
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

20. “Prediction is very
    difficult, especially about
    the future.”
    

    

    - Niels Bohr
    PREDICTING THE FUTURE
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

24. BLABBEDY BLAH BLAH - WHICH ONE IS
    BEST, PHIL?
    SOME GUY IN THE FOURTH ROW, RIGHT NOW, 2021
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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…
    

    View Slide

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…
    

    View Slide

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
    

    View Slide