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)

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