Today we will continue with our comparison between sequential and parallel work. This time we will look more closely into the connection between waterfall product development and Lean production and how they solve the problem with working in parallel without using too many of one kind of I-competence at the same time. The reason is simply and along with common sense, that no one can have universal competence. This is also completely context independent, since every organisation consist of people solving activities, leading to that any bigger organisation has many different guilds in the line hierarchy*.
And in yesterday’s blog post, we did not touch it, but the picture (repeated below), gives a need of four times as much employees, right, since no employee can have this universal competence.
And of course, no organisation does it like this. And as you already found out, the solution is very simple, and will automatically occur, be sure, since phase x can only be done for one project, or initiative, at a time.
For product development this is called cadence**, which is important to have, to spread out the different competences needed when doing the projects, which also regards the centralised resources within our organisations. We just shift the phases one step, so that two concurrent projects are overlapping each other, except only the first and the last phases. Then we get rid of all the Mean queues and the need of x times (four times in the first picture) more employees at one time. And of course, we get rid of a tremendous amount of waste. A suitable name for this way of working pattern is Overlapping Concurrent Sequences, sequences that are concurrent and have some overlap, and that is repeated over and over again.
This is also showing how easy it many times is, to take care of Mean queues, since it only requires some planning. Of course, we always have variability that will intervene with our plans and require over capacity at the Mean queues and margins in our time plans, but to omit planning, is nothing but a big negligence, a big no-no. Variability will be further elaborated in this blog post about the root causes to queues.
And now when we understand waterfall, it is time to look into the connection to Lean production. A normal picture for any factory making cars look like this.
But, this is not very illustrative regarding how Lean production actually is working, so if we instead look into the factory and all processes needed to actually build one car, it look like this.
Since there is only one Process A, that we also can call expert, or phase or I-competence etc., it means that it will look like below when a Lean production plant produces all its cars.
We can see each color as a silo or smaller part, it does not really matter, but what is important is that every part can improve by itself, as long as the takt time is fulfilled and the architecture with its interfaces is consistent, and of course also delivering the right output. And it is also here that Continuous Improvement really come to its right, both regarding the part of the product and the process making the part. Lean production, with its Just-In-Time system, really is like a perfectly planned project, meaning it takes care of the wholeness as well, in this case all the parts needed for the respective processes. From this we can also understand that when no one care about the wholeness, we will get egoistic parts, like silos, that focus on improvement of only their part without caring about the wholeness. That is when you get resource efficiency in product development and mass production in production, a clear sub-optimization in both cases.
From the picture above we can see that at every takt time, there is one and only one car started and one and only one car ready. We can see that Overlapping Concurrent Sequences is the way of working pattern also in Lean production, even though the pace is dramatically different with a new car every four minute or so! And as we can see, waterfall way of working really looks the same as Lean production. The work is divided into disciplines with different I-competence, just not only to avoid to use the same I-competence in different sequences at the same time, but also because we always need to do the activities in a sequence. And the architecture’s division into subsystems and so on, is the reason for the similarity between product development and Lean production. And that is what Overlapping Concurrent Sequences is really about.
If we instead focus on the disciplines so we see that we can only use phases and processes one by one, we get Overlapping Concurrent Disciplines, which will look like this for projects, here as the pdf, overlapping concurrent disciplines – projects:
And like this for Lean Production, here as a pdf, overlapping concurrent disciplines – production:
Of course, it is a very big difference in contexts between product development that is complex knowledge work with non-repetitive, long cycles of months, and production that is a clear repetitive context with a takt time of minutes. But, we still have the same repetitive pattern, with phases/disciplines or processes with different I-competence and a handover between them, even though they inside the phases respective the processes are very different, both to work done and the time box size.
If we instead focus on the secuences, where one secuence will develop or produce a new car, we will instead get overlapping concurrent secuences, with horizontal deliveries. This will be further deep-dived in the next blog post in this series.
What also is important to point out, is that it is the same Critical Path*** thinking and also Just-In-Time (JIT) thinking for projects with waterfall and Lean Production.
Critical Path: If the Critical Path is fulfilled, we have achieved the optimum Flow Efficiency that we are capable to right now. BUT, for product development, we need to further break down the phases to smaller phases/ activities/ stories/ team sprints so we can judge that we do not have time gaps on the Critical Path or for the highest business value items. If there are time gaps, we can still have optimum Resource Efficiency, but never have optimum Flow Efficiency. Especially in Agile development, regarding queues on the Kanban board’s different columns (which is caused by push), we need to consider the activities/tasks for the highest business value items so we not get Flow Efficiency waste. This also regards when a story is finished, but is waiting for the sprint to end, which is really a big Flow Efficiency waste.
Just-In-Time (JIT): Both waterfall projects and Lean Production are sequential. When planning is done for a project, it means that when an activity is started, the former activities that the new activity were dependent on, need to just have been finalized for activities on the Critical Path, or at least recently for the activities that are not on the Critical Path. That is exactly the same as in Lean Production, with the difference that all processes/activities are on the Critical Path***. This also means that when we activities in queues on the Kanban board or someone in the team is idle, we do not have a Just-In-Time system, due to lack of planning, which is one of the root causes to organisational problems, see the elaboration in this blog post.
Note! But, it is important to understand that in a Just-In-Time system, the takt time is not what makes the system a Just-In-Time system, rather the planning of activities in time, both activities on the Critical Path**** and the other activities that the Critical Path is dependent on. Takt time for Lean Production, means that the planning looks exactly the same all the time and makes the planning easier, but it is still the planning that makes Lean Production a Just-In-Time system, not the takt time. And since we always will have variability, buffers and under-utilization need to be considered before Aggregations Points (at every takt time) and Integration Events (timely), both for projects with waterfall and Lean Production. As you understand, on the Critical Path we can do a Value Stream Mapping, see this blog post for a deep-dive.
But, we have one aspect that is very different and that is that we in production only have an clear context which can be seen in the dotted arrow to the left in the picure. In product development we instead reduce complexity to an obvious context, which normally starts in a complex or complicated context.
Tomorrow it is time to continue with Agile Product development and T-shaped teams. Maybe they also work in Overlapping Concurrent Sequences/Disciplines? What is your gut feeling?
C u then.
*the need of a line hierachy that keeps the structure of an organisation is also context independent, but to get rid off the sub-optimisation by the silos in complicated and complex contexts, we need to add a virtual structure that takes care of the deliveries, the operative work.
**the cadence word is written about by Jim Womack regarding product development already 2008 [1], to differ it from takt time in Lean production. Cadence means that we are spreading out the development of our products, to be able to use our different competences smoothly, or as Jim puts it “another way to think of cadence is heijunka (production leveling) for product development” [1]. But lately, the cadence word has been kidnapped, especially by method and frameworks doing agile at scale, to instead mean the opposite to do activities in sequence. False cadence correctly means that all activities of the same kind are done at the same time. False cadence is a common root cause to many problems, which is easily shown with Value Stream Mapping. But, this is difficult to show when an agile way of working*** is used, making it hard to reveal. Of course it also making it confusing and harder to discuss in order to reveal this problem, when we not have a common vocabulary, and change the meaning of the words.
***Note that Value Stream Mapping cannot be done on activities in agile in advance, or at start, or it is at least extremely hard, since the activities are not decided until as late as possible. Without the possibility to do a Value Stream Mapping, it is not possible to make the flow more efficient, which was the original purpose why making the value stream at all in a production context. Remember also that in a production line, or a part of it, it is exactly the same value in the flow as well as the same activities (of course). Value stream is then not the proper expression when we are changing context from production to product development for the value stream concept, since the activities are never the same in product development (and actually not the value either when new functionality is added). This means that the focus has become too much on “value”, since we cannot do value stream mapping on the activities in agile, which in turn especially means that we cannot see our own bottle necks. In fact we therefore have big difficulties in seeing our problems within our own way of working, which means that we have lost our ability to problem-solving (Jidoka at Toyota). Instead agile organisations are only focusing on continuous improvements (Kaizen) within the agile teams, which never (ever) can replace problem-solving on the whole.
****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
References:
[1] Article by Jim Womack from the Lean Institute homepage.
https://www.lean.org/womack/DisplayObject.cfm?o=756