(Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban
•Transferir como PPTX, PDF•
23 gostaram•2,977 visualizações
An introduction to Kanban given at Agile Sydney
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (16)
Semelhante a (Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban
Semelhante a (Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban (20)
Mais de Jason Yip
Mais de Jason Yip (20)
Último
Último (20)
(Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban
- 1. Stop Starting and Start Finishing:An introduction to Kanban j.c.yip@computer.org, jcyip@thoughtworks.com http://jchyip.blogspot.com @jchyip
- 8. Dramatic change is risky
- 9. Setup conditions for improvement Visualise our workflow Limit our work-in-progress Measure our performance Improve
- 14. Show what is happening, not what should be happening
- 27. Performance is not just about time Productivity: cycle time, ROI Quality: UAT defects, released defects, user satisfaction Cost: burn rate, cost per work item, overall project cost Morale: engagement, employee satisfaction
- 28. improve
- 29. Standard Agile improvement tricks Daily stand-ups Retrospectives
- 30. New improvement tricks Stop-the-line: free up the WIP limit Quality circle: form a team to figure something out Operations review: regular meeting to analyse past performance, outliers, etc.
- 33. Encourage self-forming improvement teams over scheduled improvement events
- 34. Learning more
- 36. Core Properties of Kanban Visualise Workflow Limit Work-In-Progress Measure and Manage Flow Make Process Policies Explicit Use Models to Recognize Improvement Opportunities
- 37. Emergent Properties of Kanban Prioritise Work by Cost of Delay Optimise Value with Classes of Service Spread Risk with Capacity Allocation Encourage Process Innovation Manage Quantitatively
- 38. Where to learn more http://finance.groups.yahoo.com/group/kanbandev/ Books: Kanban by David J. Anderson Scrumban by Corey Ladas http://www.limitedwipsociety.org/ http://www.meetup.com/The-Sydney-Limited-WIP-Society/
- 39. First steps? Share ideas and commitment for how to get started
Notas do Editor
- 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.
- 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.
- 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…
- 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.
- 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?
- So we’re going to go through a simple 4 step plan…
- 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.
- 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.
- 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)
- 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.
- 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.
- Simple process, A is ready to deploy. We have work-in-progress (aka WIP) limits.
- 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.
- 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.
- And this cascades back right to the beginning. No additional work is scheduled because all the limits are hit.
- 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.
- 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?
- 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?
- We can do this for different work item sizes (aka T-shirt sizes).
- 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.
- 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!
- When it comes to improvement, we have the standard Agile tricks
- And a few others that come more from the Lean community
- Why? Building commitment! Developing people! Think for yourself! Don’t rely on me!