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
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
3. Scrum vs. Kanban
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
5. In PRIORITY ORDER In any order within the sprint We work on tickets... Scrum vs Kanban
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
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.
8. Standups are... Scrum vs Kanban Daily, no more than 15 minutes Not technically part of the process, but many people do them.
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.
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.
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.
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.
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.
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.
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.
16. Kanban Core Principles
17. Kanban Origin Kanban is a Japanese word that means signboard, billboard or “visual card”
18. This is a Kanban
19. This is a Kanban
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.
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”
22. Pull instead of push
23. “The purpose of Kanban is to bring troubles to the surface.” -Taiichi Ohno
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 :)
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
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
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
28. Core Principle: Continuous Improvement • WIP limits and visual status should prompt discussion around process issues • Ideally, we want gentle, evolutionary improvement
29. Kanban Mechanics and JIRA Board
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
31. Measure Cycle Time Cycle time is the time between when work starts on a ticket and when it is done.
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)
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
34. Limit WIP We want to watch out for any of the layers (aside from TODO) growing over time.
35. Limit WIP The column turns red and blocks further additions when the WIP limit is reached
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
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