Measure and Manage Flow in Practice

Measure and Manage Flow in Practice kaizen WIP kaikaku flow value stream mapping visualize work flow cycle time lead time throughput TPS build failed CFDcreated byZsolt Fabók (me@zsoltfabok.com) August 30, 2011 @ Prezi HQ, Budapest

Before saying anything:"I promise not to exclude from consideration any idea based on its source,but to consider ideas across schools and heritages in order to find theones that best suit the current situation." [1]This means the end of statements like “That’s no good – it’s notagile / object-oriented / pure / etc…”, but rather a discussionabout whether an idea (agile or plan-driven or impure orwhatever) works well in the conditions of the moment.

Since you are quiteexperienced with visualize the workflow measure andKanban, well skip the manage flow improve collaborativelybasics... limit (using models & the scientific method) the work in progress (WIP) make process policies explicit ...and get right to point. Only a small CFD this time, because it was discussed several times before :-)

Given thefollowingKanban board: Guess what the chart on the left represents?

Answer:This is the lead time of A

A couple of reasonsto wait so long:hamster effect wrongprioritisation weekend rush defectsslow builds manual buildsdependencies late integration nocadence contextswitching changingrequirements missing deliverystrategy favour only the leftside of the boardA couple of ideas to reduce it:delivery cadence Littles law batching cost of delay prioritisation MMF taskoriented daily stand-up dynamic prioritisation mark ageing service levelagreement avatars explicit definition of done criteria

Measuring is veryeasy or Additionally, the dates and the strikes on the cards are very good indicators as well!

Favour periods over the whole flow (please, dont hold it against me) ... period n-1* period n* Flow* avg lead time 5 19 10 avg waiting time 78% 92% 95% estimation precision 51% 78% 65% throughput 3/12 0/10 42/60 back 3 13 26 * not real dataTheir data tell more about the progress, than the data of thewhole Flow!

There are traps out there, so be careful Sufficient planning requires knowing ● the lead time, and ● the throughputFor example (based on real data):Team1 has the following lead times for items of size L: 6, 6, 6, 22, 6, 3,4, 4, 13, 2, 2, 4, 8, 6, 9, 14, 14, 15, 16, 2, 5, 33, 8On the other handTeam2 has the following lead times for all kind of items: 4, 4, 4, 4, 3, 2, 5,5, 4, 4, 3, 4, 4, 3, 4, 4, 4, 3, 6, 3I wont even try to plan using the lead times of Team1, it isunhelpful, but Team2 is quite stable

There are traps out there, so be carefulThe throughput is a tricky one. Teams usually reporthow many work items they delivered during a period.Lets say it is 12 (remember the table 2 slides ago).But it doesnt say how many work items they closedduring the period. Closing an item means starting andfinishing it in the very same periodSo instead of 12, report 3 / 12. It says so much more: ● the team was able to close and deliver 3 items, or ● there are too many left overs from the previous period ● etc.

The measure the flow principle has ahuge potentialFor example I had the feeling that those work itemswhich are started near the weekend are being deliveredslower (longer lead times) than the others.

So, using the started and done dates from the work anda small script I got the following chart (a lower barmeans a better result): Note that I dont count weekends into the lead time, except for support organisations

For further reference: the theory behind Spent time + or Age waiting effective work cycle time (repetition!) lead time

Thank you very much for your attention!For more Kanban-related topics, check out my website: http://zsoltfabok.com/ or follow me on twitter: @ZsoltFabok

Measure and Manage Flow in Practice

by Zsolt Fabok on Sep 03, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 200

Statistics

Measure and Manage Flow in Practice — Presentation Transcript

http://www.zsoltfabok.com	199
http://zsoltfabok.com	1