Posts Tagged ‘Lean thinking’
Take-away #2 from David Anderson’s Kanban Coaching workshop.
This post will be short and sweet. It’s not a revelation but it is a simple pattern that can support us in making the right decisions as we evolve and improve development processes.
Value trumps Flow
Flow trumps Waste reduction
Eliminate waste to improve efficiency
This mantra might be deceptively simple. We need to consider each aspect in turn.
In a Lean sense value is in the eyes of the consumer. Activities can be classified as value adding and non-value adding. Classifying activities isn’t always as simple as it sounds; development = value adding, fixing defects = non-value adding but what about testing? If you’re not sure then answer this, would you do more of it if you could? Remember, not every non-value adding activity can be eradicated in the short term.
In this context flow refers to the uninterrupted adding of value from concept through to realisation. When presented with a need we should seek to fulfil it in a continuous chain of activities with minimal time in queues and minimal delay.
There have been a number of attempts to define waste in software development through comparison with manufacturing industries. In the Kanban class David chose to classify wastes as transaction & co-ordination costs, failure load and depreciation of assets. I believe that this could form a useful framework assuming that we accept a certain amount of waste as necessary.
For example daily stand-up meetings are certainly not value adding and fall under the category of coordination costs, however, they are a necessity in the contexts of many teams. Perhaps more on waste in another post.
So, to reiterate, value will trump flow where we choose to disrupt flow in order to meet an opportunity. An example of this would be a new requirement that must be expedited in order to minimise the cost of delay. An expedited request will cause delay in all of the other in-flight requests.
Next we choose to trump waste reduction with flow. This is most visible where we introduce buffers to ensure maximum utilisation of a bottleneck activity. Recall that the theory of constraints teaches us that the throughput of the bottleneck determines the throughput of the entire system. Where flow is somewhat ragged we will introduce a buffer to ensure that work is available. Buffers can be considered wasteful, however, the benefits of the increased throughput out-way the benefits of reducing inventory. Another example might be the introduction of non-value adding activities at non bottleneck stations that, while wasteful in them selves, might serve to improve flow through the bottleneck.
Finally we aggressively eliminate waste from the system in order to improve efficiency while remaining conscious of two temptations:
- to use economies of scale to hide transaction costs
- drift into ‘analysis paralysis’ for fear of failure load