This wrap-up and conclusions give us insights that are contrary to our beliefs and what we actually are doing, i.e. easy to understand, but hard to accept.
Conclusions:
- We must think of Value Stream Mapping in knowledge work in the same way as when hardware development is cutting cost on an existing sub-product. There are a lot of different interfaces between the sub-product to other products; limiting parameters like size, weight, heat dissipation, EMC, lightning, signals, communication protocols etc. that cannot be changed. This means that we can only make changes within a part of the organisation that is not affecting another part. And that is easier said than done.
And this is why it is so much easier to do Value Stream Mapping in a value stream in production. The processes do not have any interdependencies to other processes, only a dependency, a handover that is exactly specified and repeated over and over again.
- If we are going to do a VSM for knowledge work in a traditional setup, we do it from the outcome of the Project Processes, the activities in the time plan, and not on the Project Processes itself.
- Just because we can do VSM for knowledge work, does not mean we should do it, because it so easily leads to sub-optimisation of our work. We should instead to focus on our set of principles, so we get our organisation right from beginning.
- If we still decide to do VSM, it is very important that the organisation agrees on what found pain points to take care about, and in what order. Because, if several pain points are taken care about at the same time, they must not interfere with each other, since it then is impossible to see the effect. See this blog post about the Systemic Organizational Systems Design – SOSD method, on why and how to dissolve organizational problems.
- Another important thing if we decide to make VSM is that, no silo can continue to do any other small improvements within their own silo. since they are most probably sub-optimising. So, all other small improvements must stop, and only the agreed pain points can be taken care of.
- When we found our pain points, we still need to ask the question why, so we find the root cause, otherwise we are sub-optimising our organisation anyway. Here the Prefilled Problem Picture Analysis Map of course will be a great help.
- Agile development’s calculation of Process Cycle Efficiency, is trying to solve a symptom within our system. All methods and Sub-optimising principles, that have been brought up in earlier blog posts and now also this measurement, become obscure because they cannot do the job, they can only sub-optimise our organisation. Later blog posts about the Prefilled Problem Picture Analysis Map will fully explain and show this.
- Another reason for the Process Cycle Efficiency must not be used, is because it will affect the team’s way of working. And the only one that can affect the way of working is the team itself, because the team members themselves are the owner of the HOW. Instead of these obscure calculations, all effort must be put on the interdependencies between the teams and to the experts, meaning a proper planning. This will remove or shorten Mean queues, as stated in earlier blog posts, so that the team of teams speed up and makes the total delivery faster. And that is a really good measure.
My own experience from a bigger Value Stream Mapping that I was responsible for at Ericsson, concludes that Value Stream Mapping for a big program in a big organisation is not easy with multiple interconnected swim lanes in different jurisdiction areas to keep track of. My manager wanted me to think out-of-the-box, but when that ended up with a root cause that needed change outside my manager’s own jurisdiction area, then the box was too wide.
We can connect this to our set of principles and the Prefilled Problem Picture Analysis Map, because we know that these problems found within the system are symptoms originating from bad principles. And we cannot cure symptoms. Instead we need to find the root causes by asking why.
So, there is value in doing Value Stream Mapping so we can see the value flows in our organisation, but, we still need to do use our Prefilled Problem Picture Analysis Map in order to map the pain points to the real root causes.
To stop sub-optimising our organisations, silos or Agile teams or others, asking why is key. We must never stop to find our root causes!
The next “chapter” according to the Reading proposal tree is Our first trembling steps to our methods blog post series, or the Aggregation vs Integration vs False Integration blog post for another deep dive.
C u then.