(Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 6,385 views

An introduction to Kanban given at Agile Sydney

An introduction to Kanban given at Agile Sydney

Statistics

Views

Total Views
6,385
Views on SlideShare
5,399
Embed Views
986

Actions

Likes
19
Downloads
166
Comments
1

9 Embeds 986

http://www.aleanjourney.com 821
http://jchyip.blogspot.com 125
http://leanjourneytruenorth.blogspot.com 32
http://jchyip.blogspot.com.au 3
http://webcache.googleusercontent.com 1
http://translate.googleusercontent.com 1
http://jchyip.blogspot.com.es 1
https://www.google.ca 1
https://twitter.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 (Agile Sydney version) Stop Starting and Start Finishing: An Introduction to Kanban Presentation Transcript

  • Stop Starting and Start Finishing:An introduction to Kanban
    j.c.yip@computer.org, jcyip@thoughtworks.com
    http://jchyip.blogspot.com
    @jchyip
  • Problem: overburdening
  • Problem: Effective Change
  • Dramatic change is risky
  • Setup conditions for improvement
    Visualise our workflow
    Limit our work-in-progress
    Measure our performance
    Improve
  • Visualise our workflow
  • Show what is happening, not what should be happening
  • Limit our work-in-Progress
  • Measure our performance
  • 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
  • improve
  • Standard Agile improvement tricks
    Daily stand-ups
    Retrospectives
  • 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.
  • Change != Improvement
  • Encourage self-forming improvement teams over scheduled improvement events
  • Learning more
  • Core Properties of Kanban
    Visualise Workflow
    Limit Work-In-Progress
    Measure and Manage Flow
    Make Process Policies Explicit
    Use Models to Recognize Improvement Opportunities
  • 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
  • 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/
  • First steps?
    Share ideas and commitment for how to get started