# Tuesday, October 14, 2014

Imagine a motorway between Starttown and Finishcity. When it all flows it takes exactly 3 hours to get from start to finish for a car, a little longer for a lorry, and a little shorter for a motorcycle, so 3 hours ± 15 minutes. It has 3 lanes in each direction for its entire length. 


Things go well for a time, but demand eventually creeps up due to Finishcity being named the City of Culture, and so we start getting regular tailbacks due to “Sheer weight of traffic.”  All of the traffic now tends to have an extra hour to get there in rush hour. The number of cars per hour arriving at Finishcity at peak rush hour times doesn’t go up, it just seems that rush hour is now two hours long instead of one hour. Pollution and fuel consumption is also up as every vehicle is burning fuel for 4 hours instead of 3. 

Learning 1)

a system of fixed capacity has an optimum flow rate. Pushing more stuff through will not result in an increase in that flow rate, it will just make everything going through that system take longer to get through. 

Learning 2) 

the longer something is in progress, the more cost there is (petrol in cars, effort in knowledge work) to service that same need. 

So how do we solve the problem?

Increase Capacity?

Well we can try to increase capacity, but that will take at least 2 years, mean more demand - all of the work traffic in addition to what we already have, and actually reduce capacity for the 2 years we are working on the roads. 

Shape the Demand?

We can put a toll booth on the front of the road, charging road users to use the road in peak hours (a bit like train tickets being more expensive in commuter times), thus reducing all but essential demand during the peak hours. Or we could use traffic lights on the slip roads to join our motorway, thus causing queues back to the roundabouts at the junctions, and causing drivers to baulk at joining the queue and use a different route instead. 

So we’ve shaped our demand, and that has helped, and journey times are back to 3 hours most of the time. The neighbouring A roads are taking a bit of a hit on traffic increase, but at least the motorway is flowing again. Phew. 


Oh no!

A lorry has jack-knifed, and blocked all 3 lanes northbound! The whole road is stopped! What do we do? 

Well we now have increased demand, we need to get fire engines, ambulances and police to the scene as soon as we can, but how can we do that when there is no way through the traffic? 

Luke, use the hard shoulder!

The what? you mean that our motorway that had all of those traffic problems that could have been solved by having an extra lane, had an extra lane all the time but people weren’t allowed to use it? We are saving 25% of our entire capacity to allow us to have an emergency capability? This is what we really do on our roads. We value the emergency capability so much we throw 25% of our capacity at it. 

Expedite me

In a Kanban system we will sometimes have an Expedite lane. This is like the hard shoulder. No-one can use use it unless they meet some pre defined conditions and rules. They are very expensive, but the cost doesn’t show on the work items that go down the expedite lane, the cost is hidden and paid by every other piece of work that is put on hold while the expedite item is worked on. The same is true on the motorway, the cost of having the 4th lane protected for emergencies is in the traffic that has to queue in the other 3 when the 4th sits idle. 

Hang on a minute...

Don’t some motorways have peak running for hard shoulders now? Yes they do, and this is more like how we do expedite in real life. We don’t keep 1/4 of our team members sitting idle in case something expedite class comes in, they all work on standard work items until they are needed to work on expedite. The cost is then only bourn when an exceptional event happens and the traffic is moved out of that lane to make an on demand emergency capability.

In real life one way to do this is to have a rule where some of (usually your best) people cannot ever pick up a work item of their own, but can pair or swarm on a work item someone else ‘owns’. That way if expedite work comes in, you can move your best people onto that without having to block some other work up, unless they need help of course. It also means that your best people are working with and helping your other people more often, which is a motivator for both sides as one gets to show mastery, and the other gets to increase their mastery (see Dan Pink’s book Drive for more on that). 



Tags: Agile | Kanban | Lead Time | WIP

Tuesday, October 14, 2014 4:10:33 PM (GMT Daylight Time, UTC+01:00)  #   

# Monday, September 22, 2014


Numbers Game

Whenever I’m in a meeting talking about metrics, someone always brings up Velocity. If you’re familiar with Scrum you’ll know that in this context, velocity means the number of story points completed per sprint. If a team completes 4 stories each of which scores 5 story points in one sprint, the velocity of that team is said to be 20.  If that doesn’t make sense, you should probably do some googling about now and come back when it does… don’t worry, I’m happy to wait for you. Look up planning poker while you’re on. ;-)

Ok ready to continue? 

Velocity isn’t a metric

No, Velocity can never be a real metric, and to use it as such is to play a dangerous game. But let me explain why this is so, and if I’m taking it away, what you can replace it with (or use alongside) as a real metric. 

Numbers are Magic

It is my belief - although as yet I do not have any scientific data to back myself up - that numbers hold a special place in our minds. Numbers and Mathematics are after all an abstract construct developed by humans as a language to explain science. It is my premise and belief that we see things that are expressed as numbers as things that we can control. If my mass is 125 Kilograms, I can target loosing 5 kilograms then go on a diet and exercise regime, and measure my progress with my measured mass on any day. 

When is a number not a number?

What madness is this? Well I’m trying to show the difference between a real mathematical number like say 3.142 and a string of digits like 055555 555 555. You probably recognise both of those, one is a shortened for of Pi, which we use in trigonometry to work out areas and circumferences of circles, and the other is a fake uk phone number. However doing maths makes sense with Pi, it doesn’t with a phone number. Imagine adding 44 to them.

x= 44+ 3.142, so x= 47.142

y= 44 + 05555555555  ….

While you can work out that y = 5555555599, it really makes no sense, what we really want to do is manipulate the string of digits to be  +445555 555 555 - the international form of the phone number. 

So some numbers are real mathematical numbers and others like phone numbers are just strings of digits, so we need to very careful whenever we use something that looks like a number but is really a string of digits as people will most likely not understand the difference without explanation and try to use the number as a real mathematical number and a control point. 

Velocity is a tricky one as it looks like it should be a real number, after all we can “Measure" it for a team. But appearances can be deceptive. My old Physics teacher at secondary school once told me that “if the maths is ever confusing, look at the units and they will help you understand what is going on.” Wise words for maths, physics and velocity. Velocity is measured in “story points completed per sprint” which might as well be “tulips completeted per sprint”  The problem with that is that it is a malleable number. 

Malleable Numbers?

Malleable Number

What do I mean by a malleable number? Malleable means “easily influenced; pliable”. So let’s pretend I’m a Command and Control manager who is up against it for a project. I see Team A with a velocity of 22, and Team B with a velocity of 35. If I think these are real numbers and in my mind they are therefore control points, so I would be likely to ask the question, "how come Team B is so much better than Team A, and why can’t Team A do 35 points per sprint too?”

We, as the kind of people who read blogs like this, probably know innately that that question is a danger sign, but lets follow it through.

Team A get pushed into working towards a target velocity of 35 points. So what are they likely to do in the next story grooming (refinement) meeting when they come to estimate their stories? I suggest that a story that would have been a 5 last time round will now be an 8 - or even a 13 point story. Why am I so confident? I’ve seen it happen in my own teams. But that is the least of the problems.

As a free gift with the instruction from manager to team there is a side order of “understanding that Management don’t seem to have a clue” which undermines the organisation, and pushes the team towards being more insular and deceitful.

It has a negative effect for everyone. Even if the team doesn’t “cheat” on estimation, they may well start “sand bagging” the sprint by working longer or extra hours. And of course that will artificially uplift velocity at first, but as people get tired, the velocity will actually drop (again I’ve seen that in action) as people stop working in a sustainable manner. 

As soon as the thing we are trying to control is malleable, as human animals we can’t resist playing with it. A bit like a blob of blu-tac on your desk, it’s malleable and you can’t help but play with it. How do we solve that problem? We put the blu-tac away in a packet, drawer or cupboard. We need to keep the malleable stuff away from the people who want to play with it - so it is with velocity. Just like blu-tac, velocity is a useful tool when used correctly (like for deciding when to stop grooming stories at the story grooming meeting), but should be put out of reach the rest of the time. Use something which isn’t malleable as your metric - like how many days stories take to deliver. In the Kanban world we call that the Lead Time, and it is measured in days (or sometimes hours), a fixed unit of time. Unless we solve the problem of light speed travel, fixed units of time are Immutable Numbers.

Tags: Agile | Estimation | Kanban | Lead Time | noestimates

Monday, September 22, 2014 1:53:25 PM (GMT Daylight Time, UTC+01:00)  #   

# Tuesday, January 14, 2014

Scrum and Kanban, What’s the difference?

My intention was a short blog, but it quickly grew into a long one to explain what I meant. With that in mind, the conclusion is at the top, please read that first, then decide if you want to go on to read the “working out” in the Body. 


Short version

  • Both Scrum and Kanban are good things but are very different beasts.
  • Kanban is a way of getting better at doing what you do.
  • Scrum is a way of being agile in software delivery. 

Longer version

  • Scrum is more than just a framework, its essence is really its Values and Ethos: Inspect and Adapt. 
    • The Scrum Framework is really just a “starter for 10” to get you started in agile development.
    • Many people think the Scrum Framework = Scrum, but this is incorrect. 
  • Kanban is not a methodology or framework. It is a way of evolving and continuously improving your framework. 
  • Kanban doesn’t have a suggested framework, it challenges you to start with what you do now and improve.
  • Comparing the Scrum Framework and Kanban is like comparing apples with fruit. 
    • It’s still a useful comparison if only so that we can explain the difference, and why you can use Kanban to improve on pretty much any way of working.
  • When you’re trying to evolve and improve, everything is up for grabs.  
  • Evolving from a pure Scrum Framework to a Kanban implementation is easy, and you can still call it Scrum


Still with me - thanks. Lets get into it. 

As an Agile Coach / Trainer and Kanban Coach / Trainer I’m often asked what the difference is between Scrum and Kanban as if we are comparing two different Methodologies. This is a much more difficult question as we have to address some misconceptions before we can answer in a meaningful way. 

What is Scrum anyway?

Scrum is NOT a framework for software delivery. (If you think this is contentious, bear with me a little). 

The Scrum Framework IS a software delivery framework, but while that sounds like splitting hairs, it really isn’t and if you are stuck in the “Scrum is the framework and that is all Scrum is” way of thinking you are imposing a false limitation on the way you are working.

Scrum > Scrum Framework 

So I ask again, what is Scrum? 

Scrum is an agile way of working which includes Values, an Ethos and a Framework for software delivery. The framework is the easy bit to learn, teach, test, and write about, so it is the part of Scrum that tends to get the focus. It is also the lightest weight part of Scrum once you get into the other areas. 

Agile at it’s roots is really a set of 12 principles listed here http://agilemanifesto.org/principles.html The Scrum Values: Focus; Commitment; Openness; Respect; and Courage, are really focused on addressing the 12 principles of agile. They tell us what Scrum is really about, it’s about working together effectively and transparently as a team, being brave in our approach to our work and way of working. 

The ethos of Scrum as I see it is really: 'Inspect and Adapt’; and be Agile.

So what about the Scrum Framework? 

The Framework is the easy bit. Here’s a set of rules: roles; practices; and meetings. If you follow this set of rules, things should improve and you will find you are starting to become more agile*.

One Sprint into Scrum, you should have your first retrospective and start getting down to the Inspection and Adapting.  Here comes the problem. If you are committed to the Scrum Framework as being sacrosanct, then you are limited in what you can adapt. We have surely all heard of ScrumBut as a concept (we do Scrum, but we don’t do xxx) which is presented as an anti-pattern. To most of us this really means we do the "Scrum Framework, but we don’t do xxx”. But how can we truly be agile and commit to inspect and adapt if you choose to constrain ourselves to never changing large parts of how we do our work? I think Scrumbut as a concept does more harm than good.

In that situation you either have to live with Cognitive Dissonance or you have to accept that the framework is just a "starter for 10” to get you started while you get to understand the values and ethos, and start becoming more agile. 

That’s how I treat the Scrum Framework. It’s a good place to start, but since your particular context was never considered in the creation of the Scrum Framework, it may have worked perfectly “there and then” it cannot be perfect “here and now” in this different context. If you are developing software, then there is a good chance it will be good enough to be a lot better than a non-agile way of working, which is why it makes a good starting point for new dev teams just being formed for the first time, or for people who choose to make the revolutionary change from waterfall to agile**.  

I am sure that the creators of Scrum never intended any part of it to hold you back from improved agility or higher performance. If you find that something inside the Scrum Framework is holding you back, you have the right and the responsibility to inspect and adapt. I would argue that evolving your framework from the ‘vanilla’ Scrum Framework is more Scrum than sticking to the Scrum Framework rules dogmatically.

What is Kanban 

If you already know the answer to that question, keep reading, more than 90% people I’ve met who 'know this already' tend to get it wrong.

Kanban is a descriptive method for evolutionary change based on the use of simulated kanban systems. 

Yes Dan, but what does that actually mean? 

The first thing it means is that Kanban is not a methodology or a framework. That is important.

Comparing Kanban to the Scrum Framework is unlike comparing apples with apples or even apples to oranges, instead it is more like comparing apples to fruit. That is why it is such a hard question to answer.

“What's the difference between a Ford Fiesta and Volkswagen Golf" is easy. "What’s the difference between a Ford Fiesta and a vehicle” is harder to answer because you have to interpret the question and change it before you are able to answer. 

Kanban doesn’t tell you how to do software delivery (or any other knowledge work). It tells you how to get better at software delivery (knowledge work). Every implementation of Kanban can (and should) be different. Some can even look a lot like Scrum on the surface. Others look nothing like Scrum. The key point is that Kanban allows teams to continue making small improvements and changing to what is needed as the context they work in changes. 

The foundational principles of Kanban are: start with what you do now; agree to pursue evolutionary change; initially, respect current roles, responsibilities & job titles. That means Kanban is applied over your current way of working, and you then start making improvements. There is no target perfect framework, only the concept of getting better at what you need to do. If you do Scrum today, when you start your Kanban journey, you do scrum tomorrow, but then you change your process to what you need it to be, no matter what a book says. At some point soon you will realise you no longer conform to the Scrum Framework. That is fine for both Kanban and Scrum. 

Evolving from the ‘Starter for 10’ Scrum Framework

It doesn’t take a lot of mental work to allow that a Scrum Framework is close enough to call an implementation of Kanban. Good Scrum conforms to the core practices of Kanban. Once a good Scrum team has got going (at some time after an agile transformation) it conforms to the foundation principles of Kanban. The only thing you have to do is release yourself from the shackles of ‘sacred rules', allow yourself to improve by collaborative experimentation, and implement a reasonable measure of productivity*** so that you can validate your learning and demonstrate your improvements. Everything is up for grabs

Look at your rules, work out if any of them are holding you back, actively decide to break (change) the first rule that is slowing you down, and measure if it made things better or not. Move onto the second rule change. Keep on doing that. Feedback -> change -> measure -> feedback…. This is Inspect and Adapt, or Probe, sense, respond, or plan, do, check, act, or even scientific method.   

The dirty little secret

You don’t even have to call it Kanban, if you prefer you can still call it Scrum, if you mean Scrum in the wider sense than just the Scrum Framework.  

Want to learn more?

book yourself up for our Kickstart Kanban class here


* I’m a firm believer that agile is something you are (or become) rather than something you do. 

** which is a risky business in itself and usually takes longer to show benefit than organisations predict. Hitting the road running with benefit is hard and rare. 

*** try Lead Time: the real elapsed time between Committing to finish a Work Item and finishing that work item; and Delivery Rate: How many Work Items you finish per day. 

Tags: Agile | Kanban | Lead Time | Lean | LKU | Quality | WIP

Tuesday, January 14, 2014 12:26:40 PM (GMT Standard Time, UTC+00:00)  #   

# Thursday, December 5, 2013

How a humble bottle of tomato ketchup can teach us about flow, pull and push. 

Knowledge work tends to be Complex Adaptive work. That means as you try to solve a problem, the solution leads to a change in the problem you are trying to solve. It’s a bit quantum to be honest. You can either know what problem you’re trying to solve, or where you are in solving the problem, but you can’t know both until you’ve finished. 

What that means is Emergence happens. Emergence means that new work magically appears as you try to solve your complex adaptive work, so there is always (or close enough to always) more work to do than you think there is going to be. So if you plan 8 hours of work, you actually need 9 or 10 (or more) hours to finish it. So if you plan 100% utilisation based on the 8 hours, you are always going to be over capacity and needing to do say 2 hours extra per day to keep up. I suddenly have the U2 song “Running to stand still” playing in my head.  Time to start the metaphor, here we go.  

Lets imagine I have a plate of chips in front of me. I fancy a bit of tomato ketchup with my chips, but oh no! It’s the dreaded traditional glass ketchup bottle. 

I think we have all trained ourselves to solve this problem. Once upon a time when we were younger, more headstrong and foolhardy we would tip the bottle right up to 180º and, oh dear the ketchup has used the whole bottleneck, no ketchup can flow! Disaster!


What should I have done? Well the older, wiser, more thoughtful @KanbanDan knows that you have to tip the bottle to the optimum flow angle, whereby the ketchup almost, but not quite fills up the bottleneck. In order for flow to happen, the bottleneck cannot be 100% utilised.  

But what if I tip it too far? Well the adage about Push, Pull and Flow might just have the answer. 

Flow if you can, pull if you must.

(you may have noticed the absence of the word “push” in there, this is a deliberate omission)

You now have 2 options if you want ketchup for your chips while they are still hot:

1) The Push approach. 

You can start smacking the bottle on its bottom repeatedly until ketchup splatters out of the bottle. This tends to have consequences, which are exaggerated if you happen to be wearing white clothes or have a white table cloth.1

2) The Pull approach

Find yourself a knife which is narrower than the bottleneck, stick it in the bottle and pull some ketchup out onto your plate. If you pull effectively while maintaining the correct flow angle for the amount of ketchup remaining in the bottle, this will encourage flow to start. Flow if you can, pull if you must. 

Kanban is not a pull based system by design. Kanban is a flow based system, which suggests the use of pull where flow isn’t naturally occurring, to encourage flow through the bottlenecks in your system. 

Just like the ketchup bottle, if you plan to use your bottlenecked or constrained people or resource at 100% capacity, emergence will bite you and cause flow to fail. If that happens, sort out the flow angle (replan at less than 100% utilisation) and use Pull to get you out of the hole you just got yourself into. Pushing will just make things get really messy really quickly. 

"But why not just use a squeezy bottle Dan” I hear you ask?  

Well next time you get over capacity in your system, ask your most constrained person to stand up, wrap your arms around them, squeeze them hard and see how fast you end up being called into HR for a meeting. Just deserts for people who stretch metaphors too far ;-) 

 Merry Christmas Kanbanistas! 

Tags: Agile | Kanban | Lead Time

Thursday, December 5, 2013 6:01:04 PM (GMT Standard Time, UTC+00:00)  #   

# Friday, August 16, 2013

I recently blogged here on Is Estimation Waste and I would like to come back to it. There is a movement in Lean and Agile towards #NoEstimates which has a lot of  value, but I still believe that we are risking missing something if we don't find an alternative method to get the value we get from Estimation (shared tacit knowledge just before we start work on the Work Item) when we throw away our Estimates.


So with that warning all done, how do we go about throwing away estimates? To start simply, we need to size our Work Items instead. This is something we all already impicitly do before we bring 'stories' or Work Items in to be estimated, but now we just need to be a bit more granular with it.  Let me use a metaphor.

A dry stone wall is an ancient British technique for building walls using stones with no adhesive cement, hence 'dry' stone wall. This skill has allowed what is essentially a cleverly constructed wall which is a pile of stones to stand solid for hundreds of years in some of Britain's most exposed and weather beaten areas. 

As you can see in the photo to the right, each stone in the wall is a different size and shape, every stone is unique. However while some stones are small and some are large, none of them are Boulders, and none of them are pebbles. Each stone is small enough to be lifted into place by a single person.  

Interestingly there is a rule in dry stone walling, you don't go looking for a stone to fit a place, you pick up the next stone and do not put it down again, you find a place to use it. 

BouldersThe point I am making is that you cannot use Boulders in the wall, they are too big and unwieldily, so boulders have to be broken down into stones, and once a stone is stone sized, it gets used as soon as it comes to the top of the pile.  It would be hard and also pointless to estimate how big each stone is, they are all irregular shapes with sloping sides and pointy bits. 

This is the same thing as sizing your Work Items. Like a stone, every Work Item is unique, with differing size, complexity and emergence (all work items are likely to have some differing level of emergence in a Complex Adaptive environment). It takes much less effort to look at a proposed work item and decide if it is a 'stone',  a 'boulder', or even a 'mountain'. If it's bigger than a 'stone' get out your hammer and cold chisel and start breaking it down into stones. Judging if a Work Item is 'stone' sized takes very little effort for a very small number of people, much less effort than estimation.


So by sizing them using maths with only 11 previously completed work items I can give 95% likelihood that any new work item will be smaller than our current largest. Contrast that with using Estimation instead. Once you have 11 work items finished each of them stone sized, you know the 12th work item is likely (this is the mathematical version of the work likely) to be smaller than your largest completed work item and larger than your smallest completed work item with a probability of 90% without even knowing anything about that new work item other than it has been sized to be a 'stone'. This is statistics working from us, and with more data points the accuracy of the prediction increases. It is also worth noting that of the 10% tolerance with 11 data points, 5% of that is the likelihood of the new work item being larger than your current largest work item, and 5% is the likelihood that it is smaller than the current smallest. Most of us aren't going to worry to much if it comes in smaller, so you have 95% likelihood that the new work item is smaller than your current largest. 

Remember we work in a Complex Adaptive scenario with continually changing context, and each Work Item requirement is also Complex and Adaptive, so we have multiple levels of emergence in the work we do. So no matter how good we think we are at estimating (and if you don't measure back on completion you don't know how good you are, and that is even more Failure Demand to work it out) we are at best going to come out with roughly 60% accurate estimates. That number comes from empirical study. 

So with simple (quick) sizing with low amounts of waste we get accuracy above 90% as soon as we have completed 11 work items (and most teams have already completed many more than 11). With Estimation which usually happens after sizing has already happened - we often call sizing grooming or story refinement in that scenario - we only get 60% accuracy. I'm not here to tell you that you're doing it wrong, but if you are spending more effort to get 30% less accuracy in your predictions, you might want to have a think about why you are doing the estimate in the first place. 

Remember,  if you are going to stop estimation, you need to find a way to replace the real value in estimation - the shared tacit knowledge. Even if that means you keep on estimating only to get that benefit, it seems like a useful thing to me. However, if you do keep on estimating, please do yourself a favour and throw away the estimate at the end, it's doing you no favours. Do the maths instead. It's faster and easier, and gives much more predictability that your stakeholders will love, and will make your job much less stressful. 






Tags: Agile | Kanban | Lead Time | Lean | noestimates | Estimation

Friday, August 16, 2013 11:40:06 AM (GMT Daylight Time, UTC+01:00)  #   

# Friday, June 7, 2013

When I go into organisations adopting Kanban or advanced Agle, they often know that they should be limiting WIP (Work in Progress) or even are limiting WIP without really understanding why. I'm hoping to make that a bit clearer in this post. The main point of limiting WIP is that it reduces the average time taken to finish each Work Item - the Average Lead Time as I define it. 

But why does Lead Time reduction matter. Well I think you might know that intuitively if not explicitly, but here it is - 

The shorter the Lead Time is for a Work Item, the less EFFORT is needed to finish that Work Item.

That is pretty profound, and indeed may even be controversial but it is absolutely true. If you do the same work in a way that has high WIP and longer Lead Time, versus low WIP and short Lead Time, then it will take more effort. 

Let me demonstrate at Kaizen Street


At KanbanDan's Garden Service. I have a contracts to maintain the lawns for the 12 almost identical houses in Kaizen Street, and for each my workers have to: 

  • Weed the lawn
  • Mow the lawn
  • Strim the lawn edge
I get paid £20 at the completion of each lawn by the homeowner. I have a team of 3 workers:
  • Bob is an ace mower, he can also strim to an average level, but is slow at weeding
  • Ian is an expert strummer, average weeder, but slower than average at mowing
  • Flo is the best weeder, average at mowing and slow strimmer.
I have 3 mowers,  3 strimmers and 3 sets of weeding gloves and tools. Each lawn on the street is identical, so I know they take 60 minutes for one average person to weed, 30 minutes for one average person to strim, and 60 minutes for an average person to mow. 

It takes 15 minutes to move the equipment from 1 location to another and set it up / store it on the van. At the start of the day and after lunch the first thing to do is unpack the gear. Last thing before lunch and at the end of the day, the gear must be packed onto the van for safety. It also takes 15 minutes to move the workers gear from one house to the next. 

Lets assume that the most gardens I'm ever going to work on at once is less than or equal to the number of workers, so it's going to be 3 maximum. That may sound familiar as that is how many IT teams start limiting WIP, 1 work item per team member maximum.  

So I have 2 options open to me. I could set each worker to work on a garden each, - the Maximised WIP solution, or I could have them swarm on 1 garden together - the Minimum WIP solution. 

Lets consider the Max WIP "1 Garden per Worker" solution first:

On Monday morning at 9:15AM, Bob goes to number 1 Kaizen street, Ian takes number 2, and Flo takes number 3, they unload their gear and all start weeding, then when their weeding is done, they Strim, then they Mow the lawn. 

At Lunch on day 1, my team of crack gardeners have finished 1 Garden but are well under way on 2 more, and have earned me £20
At the end of day 1, they have finished 4 gardens, and earned me £80 
At lunch on day 2, they have finished 7 gardens and earned me £140, but have worked on 2 other gardens
At the end of day 2, they have finished 10 gardens and earned me £200, and wasted effort on 11 and 12 as they never got finished so never earned me any money. 

Now for the Minimal WIP solution for the same problem

I ask the workers to all swarm on the first garden and get it finished. Each worker naturally plays to their strengths and does the jobs they are specialists in whenever they can. When there is no more work they can reasonably do, they move on to the next garden, but we have a WIP limit of 2 gardens. Even with that in mind, we try to work on the same garden together if we can. It's good for finishing gardens, but also good for the morale of the workers to be working together.
At lunch on day 1, they have finished 3 gardens and earned me £60

At the end of day 1, they have finished 6 gardens and earned me £120

At lunch on day 2, they have finished 9 gardens and earned me £180

At the end of day 2, they have finished all 12 gardens and earned me all of the available £240. Kaizen street has happy homeowners, and I have happy employees. 
I'll attach my spreadsheet which shows who did what when, I always like to have the data to prove the science.  gardenTimes.pdf
So the net result is that the lower WIP lead to shorter Avg Lead Time per garden, and resulted in less effort being spent to achieve the same work completed, and therefore earlier delivery of value and more completed work in the same time period. You could add in that Bob, Ian and Flo are treated like people in the minimum WIP version rather than resources - they got to specialise in their area of mastery whenever possible, and got to work together in the same garden for a lot of the time. That is likely to lead to a happier workforce which tends to lead to lower turnover, and easier recruitment (Bob, Ian and Flo are telling their friends how much they enjoy working here and those friends want to come and work with me too). 
Now lets stretch the metaphor… lets imagine we live in a country where we have unpredictable weather (not a big stretch in the UK) and it rains on day 2 so we cannot go to work. In the high WIP method we only finished 4 houses and earned a paltry £80. Most of the value in that method gets delivered on day 2, which never happens. In the minimal WIP method we would have finished 6 houses and earned £120 - thats 75% more value released after day 1 in this scenario. Plus we have unhappy customers with half finished gardens.  
I'm sure you're asking yourself how the rain equates to something in the IT world, but I'm sure we've all had days of lost work where networks have failed, the SAN ran out of DISK, the Build Server went belly up or similar. Work in Flight is actually a liability rather than a benefit - it has cost but no value, it only becomes a benefit when it completes and releases its value. We need to shift the focus on the Output of our systems, not the utilisation of our resources within the system. In this case the focus is on finished gardens, not working on gardens.
It seems like a magic trick, but there is nothing up my sleeves here - this is just Kanban in action. 

Tags: Agile | Kanban | Lead Time | Lean | LKU | Quality | WIP

Friday, June 7, 2013 4:36:21 PM (GMT Daylight Time, UTC+01:00)  #