This series of blog posts will thoroughly elaborate on flow efficiency.
As we have seen before, Flow Efficiency is connected to Resource Efficiency, see the wrap-up and graph in this blog post, and in short this mean that if we have a lot of Flow Efficiency waste, we also have a lot of Resource Efficiency waste.
Of course, we can always choose to have over capacity at Mean queues at time critical activities (on the Critical Path*) to increase the Flow Efficiency. This will instead generate Resource Efficiency waste, but this under-utilization of resources is necessary if we want to guarantee high Flow Efficiency. If our goal is high Flow Efficiency, but our planning is bad, an activity is queued with no employee that takes care of it, which results in lower Flow Efficiency.
One tool for increasing Flow Efficiency is Value Stream Mapping, VSM. As Lean, VSM is a term named from studies of Toyota, but the terms are not used by Toyota themselves. By the way, Toyota’s name for waste reduction in their production is; material and information flow mapping. VSM looks at waste as the non-value adding activities in a value stream on the Critical Path* between clearly stated start and end points. From the beginning VSM was used for sequential and repetitive processes (High Volume Low Variation), and is since its start in the mid-1990s (Toyota’s material and information flow mapping started many decades earlier) concentrating on the activities, which in production, due to its repetitiveness is the same as the process itself. This perfect coherence between the activities and the process itself in a production context, means that Continuous Improvement, CI, can be done for each process individually, without the risk of suboptimising on the total. But, in product development, we can only solve root causes to our problems to be sure that we are not suboptimising on the whole.
And this different context is really a problem when we talk about value streams, since value streams for production and service are really straightforward with dependencies that clearly is repetitive and therfore can be visualised between different values streams. And in production and service we most often talk about dependencies and not interdependencies. But, when we have the context of product development, we do not know when we will have the interdependencies and between which whom we will have the interdependencies. And you can see that the context switch also meant a switch from dependencies to interdependencies, requiring a lot of interactions and not only a hand-over. So, if a value stream is egoistic in production or service it can be handled, but in a product development context it instead means a catastrophy, exactly the same as egoistic silos. Remind yourself that projects were introduced because the silos were egoistic, so when starting to measure also the value streams (yes, it will happen), we have both egoistic silos and egoistic value streams, which most probably is even more problematic.
Here is a picture of a value stream with a commonly used notation.
The actual work adds upp to 240 minutes and the waiting time to 8 days.
Just a reminder about the earlier series of blog posts about Product value flow in the Cynefin™ framework [1] for knowledge work, i.e. many times product development. In that series we got the understanding of the journey that our product will have, through the different contexts and context switches. VSM goes into the details of our Product value flow where we choose start and stop points ourselves, to specify which part to analyse. Remember also that depending on the development of our product or service, we can start in any of the domains; Complex, Complicated or Obvious [1].
Note! Since product development is not repetitive, it does not have any activity in the time plan that is coherent with a process. This means that each activity between our start and end points need to be specified so we can examine our value stream properly, to be able to see also its sub-activities. To see all the activities clearly, is the only way to reduce lead time in a value stream, by either reducing the delay between the activities or regarding the lead time for the activities themselves. This is very important since if we find a process with a pre-specified length, but not pre-specified activities in our value stream, it is a “fake” value stream, since we cannot examine the activities within it. One of the big purposes with value streams is that we can do value stream mapping, and not only to see the value stream. This makes the value stream approach strongly questionable for all development, especially in new product development, but even maintenance because of this. In new product development the risk for sub-optimisation is the same with value streams as for silos. From a sub-optimsising point of view, there is no difference if the whole is divided into value streams or silos, it is still parts of the whole.
Since a “fake” value stream cannot be examined, it means that we can neither judge if we will have queues of activities for certain teams or individuals, nor can we reduce the length of a critical activity by for example putting in more individuals in the teams or more teams. And by calling Agile development for a value stream instead, the concept of Agile is missing. Because, Agile is about understanding the customer at the same time as understanding how the solution will be. This means that we have a context of complex/complicated. In this context we need to start with some activities (user stories) and execute them, so we can acquire new knowledge, meaning that we will change our coming user stories in the backlog continuously in order to reach the right product and the right solution. Agile development has never been about making a production line, i.e. has never been about flow optimisation. Agile is instead about to be sure that we are making the right product, the product that the customer want, in combination with the appropriate solution, where we continuously refactor small solutions. Value streams may pass all silos on its way to bring value to the customer avoiding egoistic silos, but the tricky part is to invite the customer in the Customer Journey, which maybe actually is a better abbreviation then Value Stream.
That product development is more of an amoeboid shape over time, and not like a production pipe line, is also a reason for that the value streams become “fake” in the context of product development, since amoeboid shapes simply do not fit straight pipelines very well. Trying to fit our amoeba inside the pipeline without adventuring the optimised flow that is the pipeline’s motto, means that we need to have a different resource need over time. But, with static agile teams, that is common in value streams, this indirectly means that we are ignoring queues of planned and critical activities to our teams or team of teams. And ignoring queues of activities means a bad Flow Efficiency and instead means that we are resource optimising our organisation per se. This is not the aim for value streams, right**?
And remember also that the earlier we start our product development in the Product value flow, especially in the Complex domain, where we need to gain knowledge, it will be impossible to judge what is waste. The reason is that every experiment we do, failed or not, will give us new knowledge for moving on with the next activity. This activity can be another activity in sorting out the complexity.
In the ordered domains, there are a lot of interdependencies between the teams, so waste removal in the teams is treacherous*** there, since the risk of sub-optimising is very high, i.e. the teams, experts, tools, locations, management, etc. are interwoven. This goes for all product develoment and many other work too, regardless what way of working we are using; traditional projects with waterfall of working, Lean Product Development, Agile development, etc.
Tomorrow we continue with VSM in more details, when it is done in production and traditional projects. Welcome.
*which has been generated transdisciplinary and iteratively with the project team and its sub-teams, common experts, stakeholders, centralised resources etc., i.e. taking also resource constraints for the total organisation into account
**Of course any actor claiming the need of always doing value streams as the “One size fits all” solution will not agree. But, try yourself to make a value stream mapping on an agile iteration before you have done the iteration. If you cannot do a value stream mapping on the activities within the value stream before it is executed partly or in total, common sense tells us that it cannot be a value stream in its original meaning, since value stream mapping done in hindsight is (kind of) meaningless.
***all anti-systemic waste removement is dangerous, and can easily be a Walk in the Dark since we can never foresee the new symptoms coming. The focus on reducing anti-systemic waste, like most of the waste in repetitive work like in production or service, is also one of the big drawbacks with VSM when it is done on product development. The reason is that, if the work has a high degree of sub-optimisation already, as we have seen happens easily by specialisation, the risk is high that there will be even more sub-optimisation in the organisation. To start to improve parts of a bad system will only make it worse, since the real root causes are not taken care of.
And if we think about it, it is not only Value Stream Mapping that is anti-systemic. Continuous Improvement**** goes under the same flag if we make it on any parts of the system, like Agile teams. So we need to be careful.
****remember that on the whole only continually improvements can be done, i.e. changes are synchronously implemented at the same time. This is due to the synchronisation needed between the parts when the respective part’s improvements are executed at the same time, for example takt time change. The parts can (and must) themselves be continuously improved for long-term success, as long as they do not affect another part.
References:
[1] Snowden, Dave. The Cynefin™ framework. Link copied 2018-10-04:
https://www.youtube.com/watch?v=N7oz366X0-8
[2] Monden, Yasuhiro. 2012. Toyota Production System: an integrated approach to just-in-time Fourth Edition, CRC Press, Boca Raton, Florida, USA.