Efficient Vs. Effective

I’ve been thinking about “The Goal” of Kanban in our organisation for some time.

I believe that there are numerous (side/non) goals – however, the one true goal is to deliver high quality, business value to the customer.  However, to enable this to happen a Kaizen (continous improvement) environment is likely to aid & probably help you on this “path” to the goal (you might never get to the goal – it is after all a goal).  You also have to accept that life/business/software dev/nothing is never static so you have to be able to adapt your process to ensure that you keep delivering value to your customer.  This Kaizen environment helps people to eliminate waste, but also empower people to make changes to a process or system which isn’t helping to deliver value to the customer.  Anything that doesn’t add value is essentially waste.

I think there is a lot of “Non-Value Added” time during software development.  In fact maybe the only “Value Added” time is the point in which you push/pull it to live.  Everything else might just be “Non-Value Added” time!
So what exactly is efficiency within Software Development – well to me now it’s clear – thanks to wikipedia & the above mind burb!  Efficiency in software development is anything that is not “Value Adding” in your current value stream.

Now you might think – well if you’ve got Kaizen time (i.e. slack time to improve your process) how is this adding value to your current value stream.  Well it might be something to help improve the flow within the value stream.  This is as important because you are trying to optimise the current value stream – so essentially you are aiming to add value or remove waste from your value stream (agh confusing!).  It’s important to accept that these might fail sometimes – but hey people make mistakes and learn from them.

I think Effectiveness & Efficiency get confused.  I’m certainly confused this late at night!  Let me give some arbitrary examples of measuring these two things…

Measuring Effectiveness might be measuring the number of LOC (Lines Of Code) a developer writes.  However, this is irrelevant in line with the “Goal”.

Measuring Efficiency might be measuring the amount of Business Value a developer delivers to the business.  This is more relevant to the “Goal”, and to some degree is measurable against the goal.

However, this will promote local optima – promoting selfishness, and definitely promoting a non-kaizen environment.  This would lead to a process which is not optimised – you essentially get silos of optimised process, with other areas unoptimised.  That’s why it is important to look at your full value stream when measuring Efficiency.

Before measuring Effectiveness think about the impact this might have on your overall “Goal”.

Thanks to the following for making me think about this stuff way too much:

Increased WIP = Increase in Lead Time

I’ve been viewing our Cumulative Flow Diagram and some interesting stats surrounding the work we are developing, our current flow rate and WIP.  Today I was able to see how increasing our WIP directly affects our Lead Time.

Our big spike is due to all the items being placed on the backlog (TODO) – although some of these may never be implemented more on this in the future! 

To summarize some of the information I can see (and you can’t!):

Average Lead Time for any sized item from inception to live:

  • 35 days – 7 and 11 items in progress
  • 21 days – 2 and 5 items in progress

There are a number of things to note:

  • Variability in size has an impact on lead time – large items increase lead time.
  • Increase in Work in Progress decreases lead time.

 The above ties nicely in to Little’s Law.