Downloaded 200 times
Uploaded byJason Yip
(Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban
Kanban is a method for managing workflow that focuses on limiting work-in-progress to avoid overburdening and improve flow. It involves visualizing the workflow, limiting work-in-progress, and measuring performance in areas like lead time, quality, and morale. Performance is analyzed through metrics and operations reviews to identify improvement opportunities. Changes should emerge from self-forming teams rather than scheduled events, encouraging ongoing process innovation within the system's constraints.
More Related Content
Similar to (Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban
![[NYC Scrum] 4 bad ideas about productivity... and what Agilists should do ins...](https://cdn.slidesharecdn.com/ss_thumbnails/nycscrum4badideasaboutproductivity-250320014757-d85c2fbe-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Agile India 2025] 4 bad ideas about productivity... and what Agilists should...](https://cdn.slidesharecdn.com/ss_thumbnails/agileindia20254badideasaboutproductivity-250325065515-720affaa-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Agile Lean Ireland June 2022] Tactics for influencing leaders at different l...](https://cdn.slidesharecdn.com/ss_thumbnails/agileleanirelandjune2022tacticsforinfluencingleadersatdifferentlevels-220601183317-bafc66f5-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Stretch 2023] We're in it together and other perspectives on effective produ...](https://cdn.slidesharecdn.com/ss_thumbnails/stretch2023wereinittogetherandotherperspectivesoneffectiveproductdevelopmentculture2023-231007094819-ee251a7b-thumbnail.jpg?width=640&height=640&fit=bounds)
![[CoPA 2022] Experiences applying BAPO at Spotify.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/copa2022experiencesapplyingbapoatspotify-220519133108-4c52083e-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Yow! 2019] 3 insights from 4 years at Spotify](https://cdn.slidesharecdn.com/ss_thumbnails/rvbpfzasgyvrfcjf64iw-signature-f2cf7ab4a3bbb3845718f1f906a24f1800046faa92db9223c912b64a2b1d8538-poli-191212214409-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Stretch 2023] What does productivity really mean at different levels_ Indivi...](https://cdn.slidesharecdn.com/ss_thumbnails/stretch2023whatdoesproductivityreallymeanatdifferentlevelsindividualteamorganisation-231006072348-e91293c7-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Craft Conf 2024] Occupy the Space: A grassroots guide to engineering (and pr...](https://cdn.slidesharecdn.com/ss_thumbnails/sqgbryhmtkqvy1ybaxqr-craft-conf-2024-occupy-the-space-a-grassroots-guide-to-engineering-and-product--240618125015-c525c0c2-thumbnail.jpg?width=640&height=640&fit=bounds)
![[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...](https://cdn.slidesharecdn.com/ss_thumbnails/3euxfltqtomwzjwnrhlw-oreilly-superstream-occupy-the-space-a-grassroots-guide-to-engineering-and-prod-240618124513-761010bc-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Craft Conf 2023] We're in it together and other perspectives on effective pr...](https://cdn.slidesharecdn.com/ss_thumbnails/craftconf2023wereinittogetherandotherperspectivesoneffectiveproductdevelopmentculture2023-230519134350-144f95b1-thumbnail.jpg?width=640&height=640&fit=bounds)
![[AgileDevOps West 2023] We're in it together and other perspectives on effect...](https://cdn.slidesharecdn.com/ss_thumbnails/agiledevopswest2023wereinittogetherandotherperspectivesoneffectiveproductdevelopmentculture2023-230608140842-c5298870-thumbnail.jpg?width=640&height=640&fit=bounds)
![[CoPA 2022] Effective Product Development Culture circa 2022.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/copa2022effectiveproductdevelopmentculturecirca2022-220519132616-2de04c84-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Business Agility Conference 2022] The top 3 points you should have paid atte...](https://cdn.slidesharecdn.com/ss_thumbnails/businessagilityconference2022thetop3pointsyoushouldhavepaidattentiontointhespotifyengineeringculture-220324183422-thumbnail.jpg?width=640&height=640&fit=bounds)
![[NYC Scrum] The top 3 points you should have paid attention to in the Spotify...](https://cdn.slidesharecdn.com/ss_thumbnails/nycscrumthetop3pointsyoushouldhavepaidattentiontointhespotifyengineeringculturevideosthatarentsquads-230921230404-255c0b6c-thumbnail.jpg?width=640&height=640&fit=bounds)
(Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban
- 1. Stop Starting andStart Finishing:An introduction to Kanbanj.c.yip@computer.org, jcyip@thoughtworks.comhttp://jchyip.blogspot.com@jchyip
- 2.
- 7.
- 8. Dramatic change isrisky
- 9. Setup conditions forimprovementVisualise our workflowLimit our work-in-progressMeasure our performanceImprove
- 10.
- 14. Show what ishappening, not what should be happening
- 15.
- 22.
- 27. Performance is notjust about timeProductivity: cycle time, ROIQuality: UAT defects, released defects, user satisfactionCost: burn rate, cost per work item, overall project costMorale: engagement, employee satisfaction
- 28.
- 29. Standard Agile improvementtricksDaily stand-upsRetrospectives
- 30. New improvement tricksStop-the-line:free up the WIP limitQuality circle: form a team to figure something outOperations review: regular meeting to analyse past performance, outliers, etc.
- 31.
- 33. Encourage self-forming improvementteams over scheduled improvement events
- 34.
- 36. Core Properties ofKanbanVisualise WorkflowLimit Work-In-ProgressMeasure and Manage FlowMake Process Policies ExplicitUse Models to Recognize Improvement Opportunities
- 37. Emergent Properties ofKanbanPrioritise Work by Cost of DelayOptimise Value with Classes of ServiceSpread Risk with Capacity AllocationEncourage Process InnovationManage Quantitatively
- 38. Where to learnmorehttp://finance.groups.yahoo.com/group/kanbandev/Books:Kanban by David J. AndersonScrumban by Corey Ladashttp://www.limitedwipsociety.org/http://www.meetup.com/The-Sydney-Limited-WIP-Society/
- 39. First steps?Share ideasand commitment for how to get started
Editor's Notes
- #4 I want you to think about your overall organisation and answer this question: Is there more work to do than there is capacity to do it?Oh… and is it a little bit more to do? Or a lot?This is the problem we’re going to address.
- #5 This is the typical response.We have too many requests but we’ll just try to respond to everything. Everyone’s “happy” because everything is progressing. Really?This is what I call The Illusion of Progress.
- #6 What would happen if we finished something before moving on to the next? Basically, we’d finish everything a *lot* faster.The spaces in between represent context switching overhead, but even if we removed that, A and B still finish faster and C finishes at the same time.We shouldn’t ignore context switching overhead though because it’s worse for people than it is for machines…
- #7 The more simultaneous projects that are happening at the same time, the more time is lost to context switching and less actual working time is available per project.
- #9 This is a bit of a sidebar. A major constraint is that a dramatic change, while a very exciting solution, is less likely to be successful or to stick. Instead a lighter touch is preferable. I’ll suggest that in many cases, the lighter touch approach can be much faster because we don’t have to keep cycling back to deal with lack of commitment.So for this particular problem of more requests than capacity to do it, what are the conditions for continuous improvement?
- #10 So we’re going to go through a simple 4 step plan…
- #12 When we are dealing with physical work, it’s relatively easy to point out problems with workflow because you can actually point out things that can be seen.
- #13 The problem with IT, and in general knowledge work, is that much of what we do is normally invisible. Whereas throwing another item on an already shaky stack looked dangerous, overloading someone with another idea to implement seems perfectly safe.
- #14 So let’s make the invisible, visible.Process steps, hand-offs with queues. Now we can see when bottlenecks are appearing. We can see if something has been stuck for a while.How many people have something like this setup already? Key thing here is explicit acknowledgement of queues and preferably all the steps (start-to-finish)
- #15 Key point: At this point, we’re not trying to change anything per se but rather to expose what is actually going on. We don’t want the idealised process, just the one that is in play.So this is a very small change. Just expose what’s happening.
- #17 The next small change. Introduce limits to the process steps. So we have a rule now where we can only have 3 items in Explore, 2 items in Build It, and 4 items in User Acceptance.It’s easier to understand what this means with an example.
- #18 Simple process, A is ready to deploy. We have work-in-progress (aka WIP) limits.
- #19 Oops! Something went wrong with deployment. B is also ready for deployment but obviously we need to wait for A to work. So in order to get B to move, the developers see if they can help.
- #20 The rest of the development team is still working on C. If they finish, they’re not allowed to take on more work because of the WIP limit, so if they can’t help, they can work on other improvements or really just doing something else.
- #21 And this cascades back right to the beginning. No additional work is scheduled because all the limits are hit.
- #22 Key point: We’re introducing an expectation of behaviour here that moves us away from “Whose job is this?” “Not my problem” to “What is the right thing to do?” “How can I help?” That’s because the WIP limit policy makes it *our* problem, not just your problem.
- #24 Let’s talk about measuring performance. Has anyone seen this kind of sign before? It’s pretty common in amusement parks or any place where you need to wait in long queues. This is essentially what we want to provide. Given that I’ve made a request, how long should I expect to wait before I get resolution?
- #25 So let’s measure it.This is called a control chart. Here we’ve simply measured the start-to-end times for work items in a time series in order to understand what kind of variation we should expect. So now we have a normal range of lead times we can expect from this particular type of work item.We will also see outliers but these are an indicator of something abnormal happening. Did the entire testing team get taken out by bird flu? Did we just happen to get really lucky?
- #26 We can do this for different work item sizes (aka T-shirt sizes).
- #27 But what if we need something faster? What if we need something by a particular date? What if it’s an emergency? Well then we should explicitly identify it as such. So you can imagine special cards that might go on the board. This can be more or less complicated as needed.
- #28 It’s important to remember that performance is not just about time. I tend to use these categories to think about what is worth measuring. From what I can gather, this was originally from Ford.Remember don’t use the average. Capture the time series!
- #30 When it comes to improvement, we have the standard Agile tricks
- #31 And a few others that come more from the Lean community
- #34 Why? Building commitment! Developing people! Think for yourself! Don’t rely on me!