This is the wrap-up of this series of blog post deeply analysing sequential and parallel work. Many conclusions can be drawn and here are the most important ones.
- The first important conclusion we can make is that sequential and parallel go hand in hand, it is only a matter on how deep we look; projects, epics, sub-projects, features, activities, stories, sub-activities, tasks, sub-tasks, etc. In the end, no one can do more than one thing at a time, no human, no computer. As individuals, we can only schedule one task at a time, so it will always end up with sequential work no matter context, because we always need an order as well.
- When looking into that the market need speed, our answer is that our teams need to work in parallel, and we can see that the time boxes need to be smaller, which is handled by both Lean Product Development with I-shaped teams and by Agile development with cross-functional and T-shaped teams.
- When we know exactly what to do and there is no time pressure, and by looking at our history to get a good time estimation, Overlapping Concurrent Sequences (cadence) is a very good solution. Especially for I-shaped teams and is used in Lean production and in product development in the cases where there also are lead times. This goes well also when it is more efficient to have one individual doing all routine steps in the sequence, and many individuals together make Overlapping Concurrent Sequences. This gives a constant output, where the constant output can be seen as small batches, which can be preferred by the next “process” in line.
- And when our teams work in parallel, we need to be very careful and have control both short- and long-term, and not forget the interdependencies to other teams, common experts (SMEs), common tools, common stakeholders, common locations (for example for Big Room planning) etc., or even within the teams if the team is not T-Shaped enough. And regarding everything that is common, remember that a forced cadence where there are no dependencies is an inflexible solution and will lead to unnecessary waste. When teams are working in parallel, the interdependencies are also very different depending on if the teams are I-shaped or T-shaped, which will be elaborated on in a later blog post.
- There are always I-competences needed in integrative work, especially at start-up with systemisation and architecture experts, since someone needs to take care about the whole system. Same goes at the end when we need to release and integration & verification of the total system, etc. These I-competences, all of them, are also bottle necks and have Mean queues from all teams that need their help, meaning interdependencies. So, even with cross-functional teams, I-competences are needed outside the teams. And remember also that most of the cross-functional teams have some uniqueness as well regarding their special T-shape, making one team more suitable for certain activities. There is absolutely no reason that all cross-funtctional teams have exactly the same T-shape.
- 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 our knowledge work teams that is working in parallel, because they are integrating the parts to a bigger deliverable. In production we do not need an Interdependency Board, because in production our work is aggregated. This is deeply analysed in this blog post.
As stated before, we always need to look at the context, what domain in the Cynefin™ framework we are in, and now we can also see that we can choose different way of working depending on our information about the context, which can be very different within our own organisation.
From these earlier blog posts, we already know that the flexibility of today’s market requires a non-static morphological working organisation, but where the Line organisation can be static, used by Spotify with their chapters. To this we now also can add that the different contexts within our organisation shows that we definitively not should work exactly the same everywhere.
All together it shows that a transformation to a one-size-fits all does not exist. Instead we need to continue to believe that we best know our business, with all its different contexts and context shifts, so we implement a flexible solution, where the solution must be founded on our set of principles, to be sure that we are avoiding sub-optimisation. Frankly, it is not harder than that, and with the coming Prefilled Root Cause Analysis Map, it will be even easier to see an organisation’s pain points.
The next “chapter” according to the Reading proposal tree is TDSD – the first trembling steps to our methods blog post series, or the Flow Efficiency blog post series for another deep dive.
C u then.