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

Intro to Kanban for Teams that use Scrum

Audrey Troutt
November 15, 2017

Intro to Kanban for Teams that use Scrum

Sometimes engineering teams find that their selected process doesn't match up with the conditions they are working in. Specifically for Scrum, teams with a lot of operational or interruptive maintenance responsibilities may find that dealing with the constant flux of tickets into your sprint backlog is more trouble than it is worth. If you've got process friction, then maybe you should explore whether another process would work better. That is where this talk comes in. This is an overview of the Kanban, including:
* How Kanban differs from Scrum
* Why teams switch from Scrum to Kanban
* The core principles behind Kanban: visualize work, limit WIP, focus on the flow of work, and continuous improvement
* The mechanics of Kanban and the Kanban board (specific to Jira)

Audrey Troutt

November 15, 2017
Tweet

More Decks by Audrey Troutt

Other Decks in Technology

Transcript

  1. Intro to Kanban
    For teams that use Scrum

    View Slide

  2. Agenda
    ● How Kanban differs from Scrum
    ● Why teams switch from Scrum to Kanban
    ● The core principles behind Kanban: visualize work, limit WIP, focus on the
    flow of work, and continuous improvement
    ● The mechanics of Kanban and the Kanban board

    View Slide

  3. Scrum vs. Kanban

    View Slide

  4. Commit to complete individual
    tasks/features as fast as possible
    (with NO TIME COMMITMENT)
    Commit to completing SPECIFIC set
    of tasks/features by the end of the
    sprint
    We commit to...
    Scrum vs Kanban

    View Slide

  5. In PRIORITY ORDER
    In any order within the sprint
    We work on tickets...
    Scrum vs Kanban

    View Slide

  6. Triage and pop-up issues are...
    Scrum vs Kanban
    Very disruptive! Either slow velocity
    or require re-negotiating sprint scope
    Expected and get prioritized in the
    TODO column and started when
    possible

    View Slide

  7. Roles and rituals are...
    Scrum vs Kanban
    ● 3 roles
    ● 4 ceremonies
    ● 3 artifacts
    Do you remember what they are??
    Not technically part of the process,
    but many use similar roles and
    ceremonies as with scrum.

    View Slide

  8. Standups are...
    Scrum vs Kanban
    Daily, no more than 15 minutes Not technically part of the process,
    but many people do them.

    View Slide

  9. Retros are...
    Scrum vs Kanban
    At the end of each sprint Not technically part of the process,
    but many people do them.
    Striving for continuous improvement
    is one of the core principles of this
    practice, although it doesn’t prescribe
    a rhythm or format for those
    improvements.

    View Slide

  10. Not technically part of the process,
    but still very useful. Most teams
    have/keep this role.
    Someone has to put that TODO
    column in order and make sure the
    tickets are well defined!
    Product Owners are...
    Scrum vs Kanban
    Essential to the process, own the
    product backlog and keep it
    prioritized and well defined.

    View Slide

  11. Not technically part of the process,
    but can keep if useful.
    Scrum Masters are...
    Scrum vs Kanban
    Essential to the process, protect the
    team and their time. Do whatever it
    takes to keep the team unblocked
    and productive.
    Own the process and rituals and work
    with the PO on the backlog.

    View Slide

  12. Does the work of making the product
    Can change at any point
    Is responsible for keeping their cards
    up to date.
    The team...
    Scrum vs Kanban
    Does the work of making the product
    Is not supposed to change during a
    sprint
    Is responsible for making sure the
    sprint backlog (tasked out stories) is
    well defined and tickets are
    estimated.

    View Slide

  13. Scrumban? Kanscrum? Scrumbum?
    Lots of people use a hybrid approach.
    All the roles and rituals of scrum with the ticket/board management done in
    Kanban.
    So you can have a Kanban board and still do sprint reviews and retros and
    release schedules and standups and have a product owner.

    View Slide

  14. When Kanban is better
    ● Work is at least partially REACTIVE and INTERRUPT DRIVEN
    ○ Kanban handles this as part of the process, whereas you have to break all the Scrum rules to
    accommodate it
    ● Business is okay with not committing to deadlines, deliver as fast as possible
    ○ Your delivery days were inaccurate anyway if you are always interrupted by pop ups
    ○ Yes, we will still ask for estimates from time to time to help with prioritization (cost vs value)
    ○ Anything large and complex with a deadline should be a project… and have a project team
    and use Scrum.
    ● There are no downsides aside from the initial change pain. Do you agree?
    Kanban is great for maximizing productivity while handling
    surprises.

    View Slide

  15. When Scrum is better
    ● Team has NO INTERRUPTIONS to planned work
    ● Deadlines and delivery dates are essential
    ○ We can adjust scope to meet deadlines if needed, but we need estimates to know that
    Scrum is great for creating focus and delivering on deadlines.

    View Slide

  16. Kanban Core Principles

    View Slide

  17. Kanban Origin
    Kanban is a Japanese word that means signboard, billboard or “visual card”

    View Slide

  18. This is a Kanban

    View Slide

  19. This is a Kanban

    View Slide

  20. Kanban Process Origin
    The idea of Kanban as a process originated in manufacturing.
    Kanban was an order card. These order cards would be used to restock goods
    “just in time” to reduce inventory and to improve the flow of production.
    These were first introduced by Taiichi Ohno as part of the Toyota Production
    System in the 1940s.

    View Slide

  21. Pull instead of push
    ● Push System
    ○ Make product as fast as you can
    ○ Work piles up behind slow steps
    ○ Warehouse finished product that doesn’t sell fast enough
    ○ Long time between investing in product and getting “money back” when it sells
    ● Pull System
    ○ Make products as fast as you can ---if there’s pull from ahead!
    ○ TODO backs up until in-progress work is done
    ○ Shorten time between spending on time/resources and payoff when product “sells”

    View Slide

  22. Pull instead of push

    View Slide

  23. “The purpose of Kanban is to
    bring troubles to the surface.”
    -Taiichi Ohno

    View Slide

  24. Developing Software isn’t Manufacturing
    I know that, but there are similarities:
    ● Purchased supplies = time invested in analyzing and implementing
    ● Unsold inventory = code knowledge that you are slowly forgetting
    ○ It’s cheaper to fix bugs, write docs, or answer questions about code you worked in recently
    ● Selling product = delivering value for our customers
    ○ What we “deliver” to production helps Tune acquire and retain customers
    ● Increased throughput is good for morale :)

    View Slide

  25. Core Principle: Visualize Work
    ● Learn how to define and capture requests for work
    ● Visualize each request with a card on a kanban board
    ● Make every step of the workflow visible.
    ○ “Visualize the sequence of knowledge discovery activities performed from when the request is
    first received until it is completed and ready for delivery to the customer.” - David Anderson

    View Slide

  26. Core Principle: Limit WIP
    ● Use a “pull system” to minimize unsold product sitting incomplete or in a
    warehouse
    ● Work in progress (WIP) should be capped (without it it isn’t a pull system)
    ● If WIP limit is reached, team jumps on already open tasks to get them to
    completion

    View Slide

  27. Core Principle: Focus on the Flow of Work
    ● Flow is the movement of tasks from one queue to the next
    ● Ideally, we want FAST SMOOTH FLOW
    ● Fast flow means we are creating value quickly
    ○ Want to shorten the time between when a ticket appears on the board
    and when it is done.
    ○ This minimizes risk and avoids (opportunity) cost of delay
    ● Smooth flow means we are predictably and steadily
    delivering

    View Slide

  28. Core Principle: Continuous Improvement
    ● WIP limits and visual status should prompt discussion around process issues
    ● Ideally, we want gentle, evolutionary improvement

    View Slide

  29. Kanban Mechanics and JIRA Board

    View Slide

  30. Getting Started with Kanban
    ● Figure out what your columns/queues should be, based on your actual
    workflow
    ● Guess what your WIP limits should be
    ● Create a board
    ● Prioritize your backlog and put it on the board
    ● Measure your cycle time

    View Slide

  31. Measure Cycle
    Time
    Cycle time is the time between when
    work starts on a ticket and when it is
    done.

    View Slide

  32. Want FAST
    SMOOTH FLOW
    This is the Control Chart that we show
    at every sprint review.
    It shows CYCLE TIME or LEAD TIME
    depending on how it is configured
    (which columns you choose)
    Fast Flow -- dark blue line goes lower
    Smooth Flow -- light blue area gets
    narrower (less variability in the time to
    completion)

    View Slide

  33. Want Fast Flow
    These dots indicate how long a ticket
    has been sitting in a column/queue.
    More dots = long time = bad
    Some Redacted Jira Ticket
    2 days

    View Slide

  34. Limit WIP
    We want to watch out for any of the
    layers (aside from TODO) growing
    over time.

    View Slide

  35. Limit WIP
    The column turns red and blocks further additions when the WIP limit is reached

    View Slide

  36. Kanban Advice
    ● Break down each work item to about the same size
    ● Measure Cycle Time and Lead Time
    ○ Set WIP limits to minimize waiting and maximize throughput
    ● Evaluate if the WIP limits and columns are correct and re-adjust
    ○ Evaluate if the columns/queues are appropriate for our workflow
    ● Discuss stuck tickets and improve as needed to make flow FAST and
    SMOOTH

    View Slide

  37. Learn More
    Learn more about Kanban at https://leankit.com/learn/learning-kanban/
    My favorite book is Personal Kanban: Mapping Work | Navigating Life by Jim
    Benson et al.
    For managers/leads, there’s an Atlassian Jira Kanban Tutorial

    View Slide