This is my second Q&A post for my #Agile2014 session: How to improve Flow Efficiency, Remove the Red bricks! In this, my previous and upcoming posts I will answer some of the questions I have received as session feedback after the session.
Q2: The presentation gave a full demonstration of the issue and how to address the problem. However the only issue I had with it is that it is essentially teaching to have your highly skilled, highly paid people sit and wait for work when it is ready. I would like to see the real metrics when you consider the overhead of these highly skilled people. But in general, I think you did a really good job of pointing out the issue and ways to address it. Entertaining presentation as well.
Yes, I am proposing that for some organizations, based on their context, it is a valid business/operational strategy to focus more on having the flow units (e.g. user stories, features, MVP, project) being worked on all the time over having our highly skilled, highly paid people utilized all the time.
Every system has a bottleneck. A system cannot go faster than the system bottleneck.
The cost of running our system, in most cases, is independent if people are working or waiting. We will pay their salaries independent of what they do. It is therefore a question of how do we maximize the return based on our investment.
As Taiichi Ohno points out, in his book Toyota Production System: Beyond Large-Scale Production, overproduction generates a lot of additional waste. The more inventory and Work-In-Process (WIP) we have, the more time we have to manage the WIP. With more WIP, feedback most of the time slow down. Slower feedback often leads to rework or work not needed by the customers.
Having a business/operational that focus more on having the flow units busy over having our people busy is a Flow Efficiency first strategy. This strategy is the business/operational strategy of Lean and Agile as described by Niklas Modig and Pär Åhström in the excellent book This is Lean: Resolving the Efficiency Paradox
A Lean or Agile business/operational strategy makes sense when we are providing services or products that will not retain all, or parts of, the value that has been added during the process. If we are working in the product development domain, and especially in the software development domain, the value of a partly developed product is close to zero or even negative (we need to maintain non-finished code). In most cases, even a finished product will not retain its value for very long.