(Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban

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.

31. Change != Improvement

32.

33. Encourage self-forming improvement teams over scheduled improvement events

34. Learning more

35.

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

Hinweis der Redaktion

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!

(Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (16)

Ähnlich wie (Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban

Ähnlich wie (Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban (20)

Mehr von Jason Yip

Mehr von Jason Yip (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

(Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban

Hinweis der Redaktion