Today it is time go through parallel work done with different I-shaped teams working for the sam goal, that we have shown the necessity for, when the market requires speed. When you have high complexity it is different, because then every discipline needs to be in the same boat from start, we need transdisciplinary work to reduce the complexity first of all, i.e. systems design.
When we work in parallel, every I-shaped team know what to do except from the details and some expert help needed, which is the same as for waterfall way of working. The main difference is that we cannot in exact detail plan our work, rather we have short-term window planning for the details. Here is a picture of waterfall way of working, where we have a handover to the next phase, well specified in our Project management processes.
And here is the picture when we put the phases in parallel.
And as the picture shows, the phases, or the I-shaped teams, are overlapping, but shifted, since we stated in the first blog post of this blog post series, it cannot be in total parallel when the ordered domains in the Cynefin™ framework have been entered. The interdependencies we need to solve to have a good flow. And since especially product development is not repeatable when we go more into details, this can never be specified in the Project Management processes from the beginning. No project is simply not comparable on a detailed level to another project.
And in order to solve the interdependencies smoothly, proactiveness is key. To achieve proactiveness, broad competence, T-shape, is important as shown in earlier blog posts, so we both can understand what other teams need, and state to them what we need ourselves, both short- and long-term. What does the next phase need so we are not blocking them? What can we expect that the other phases can deliver to us so over work can proceed smoothly?
And as you already have understood, in order for the coming phases to start as early as possible, we need short time boxes within a phase. And here our Interdependency Board has a very important role.
And the importance of the Interdependency Board is valid for all parallel work, not only for I-shaped teams. The Interdependency Board is key for all product development teams that is working in parallel, because we are integrating the parts to a bigger deliverable, and there are many interdependencies to handle, both to other teams and to experts. In production you do not need an Interdependency Board, because in production the work is aggregated, but of course they use status boards. The difference between aggregation and integration is deeply analysed in this blog post, Aggregation vs Integration.
So, we are actually dividing our phases into small time boxes as mentioned above, of different length depending mostly on lead times when we talk about hardware product development.
So, we need shorter time boxes also here as well. And when we have shorter time boxes, we get faster feedback, which is the same thinking as in Agile software development. The above is a good example regarding the similarities with Lean Product Development, which has been using this technique for many decades and together with platforms with modules, multiple concepts and Set-based design are big reasons of Toyotas success with their product development. Lean Product Development is handled further in this blog post.
In tomorrow’s blog post we will wrap up this series about sequential and parallel work.
C u then.