Today we are digging into production and product development with waterfall way of working regarding Value Stream Mapping, VSM.
As stated in the last blog post, VSM looks at waste as the non-value adding activities in a value stream between clearly stated start and end points. And it is important to state activities, not the actual processes, where the activities are done. This is extremely important to understand, since it is vital for product development, that is never repeating an activity twice but rather the process for working with the activity is repeated. This is diametrically opposed to production, where there is a repetitive pattern. In production for every process, the activity (WHAT) in the process generates the work to be done on the activity (HOW). In product development the WHAT never generates exactly the same HOW to work with the WHAT, meaning we can only specify a high level process. For product development it then becomes clear that we need the actual activity not only a process taking care of an activity, to also get its real length in the value stream.
So, what also need to be taken into account and which requires some elaboration here, is when we are not breaking down our WHAT according to our made architecture*. This happens for example when we are dividing our WHAT into end to end features in software, which means that we need to understand HOW we can break down the solution in smaller parts. This means that we actually have two different HOW, one on the solution that is needed in order to find the smaller WHAT and another HOW that is our HOW to do the actual work. The understanding of the two different HOW, is vital in order to understand that when doing features, the dividing of the feature into smaller pieces will affect the HOW to do the actual work, especially also when we not have the customer need in full control. Here below follows a thorough elaboration supported by pictures on the difference between not only production and product development, but also between hardware and software development regarding the WHAT, the HOW to divide the WHAT into smaller activities and the HOW to do the actual work.
In product development, regardless if it is hardware or software, we make an architecture, that consists of subsystems, sub-subsystems, etc., depending on the size of our product. The reason why we are making an architecture, is the same reason for us having a line structure of the organisation, a working structure of the organisation and a planning structure of the work we are doing. We simply structure our reality of work to be done into smaller parts, in order to reduce the complexity.
With clear well-specified I/F, a module can easily be reused, as Brad Cox is pointing at, which significantly will reduce cost for further development, not to mention time to market.
Features is more or less going the other way compared to SW modules, but features/user stories and modules can clearly be intertwined, with basic SW modules that are easily called from features and user stories.
Back now to the activities in the value stream mapping. These activities are also normally on the Critical Path, 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.
When activities are on the Critical Path, it means that if they are delayed, the product or service is delayed. The Critical Path can be viewed on different levels; from the project as one activity, down to a detailed level where the activities for the teams or even individuals can be seen. The Critical Path is the key for doing Flow Efficiency improvements of the total product or service.
If the Critical Path cannot be presented, the focus is definitely not on Flow Efficiency.
VSM made on knowledge work, need to focus on the activities on the Critical Path in the same way as for production as stated above. This means that we can do VSM on the time plan, one of the outputs from the Project Processes**, since there we have all the activities for the project, with the needed time box per activity.
VSM was as stated before from the beginning used for production which is aggregating (no interdependencies) to achieve the product, but after that it was broadened to be used also for knowledge work with projects.
But, for project work this can be very tricky, because project work is integrating at Integration Events, with also a lot of interdependencies between the teams and to experts, between the Integration Events. And remember that the activities are very different from each other and seldom exactly the same, not even between two similar projects This of course means that the focus is mainly on the waiting times, which is the same as in production/service/office. Since project work also is a creative process, it is also very difficult from the beginning to say what will be non-value adding work in our activities.
And as stated before, when we find a problem, a pain point, we must always start to ask why until we find the real root cause. And remember that multiple symptoms may end up in only one root cause, so all pain points found will most probably end up only in a few root causes.
If we have not asked multiple questions of why we are doing something, we are most probably sub-optimising our organisation.
This maps well with the ambiguity among thought leaders, where some of them recommends to make a VSM on the Project Processes where others state the impossibility to make a VSM in a complex system. So, it is ambiguity if VSM should be made on projects or not.
From the above we know that when we do a VSM with its Flow Efficiency calculations in knowledge work, we must do as follows:
- do it from the outcome of the Project Processes, the activities in the time plan, and not on the Project Processes themselves. And do it in the beginning of the project, and keep track of the Critical Path and especially its waiting times.
- and to avoid sub-optimising, we cannot go down on a too detailed level, but to only see the value flow has many times value for the organisation
- do an analysis on the pain points found in the value flow, with the help of the Prefilled Problem Picture Analysis Map, but also other known pain points in the organisation, and always ask multiple why, to find the real root causes.
In this way we get a good view of the value flow in the total organisation, and we can improve the system by taking care of the root causes, with no risk of sub-optimising.
In the next blog post we will continue with Agile teams and later also their flow calculations, Process Cycle Efficiency, that is widely used. And it means that it is time for some valuable insights since we so far have learnt a lot about what system collaboration really is. And these calculations as well put a treacherous constraint on the teams, since the constraint is not explicit. Thrilling, right? C u then.
*if there is no legacy architecture, a new architecture prepared for the coming features, may give a smoother way when breaking down the features into user stories, or with the help of micro services. Remind also that Conway’s law will add communication structure into the software code, depending on the team’s closeness to each other.
**a platform with modules, where the modules are updated incrementally, is the closest hardware product development can come features, even if it is not exactly the same.
***VSM made directly on for example the Project management processes themselves, valid for planning, follow-up, etc. of the project, will probably only have very small effect, i.e. it is the wrong focus area. We have also the Product-oriented processes that specify on a more high-level how to take care of some of the activities in the time plan.
But, since knowledge work is not repetitive and all the interdependencies cannot be seen in the processes, it is treacherous to try to make VSM on the processes directly and the risk for sub-optimising is very high when there is no Big Picture that can be seen either.
 Cox, Brad J, “Planning the Software Industrial Revolution”, November 1990, IEEE Software Magazine. Link copied 2019-01-29.