Welcome back. Today we will continue with more of the common senses that are independent of scaling and that normally is not affected by external forces.
Common sense: We need to avoid Chinese whispers
“Chinese whispers” is a game for children, where there is a chain of children, transferring a story from the first to the last child. Aside from that the story takes long time to reach the last child, the story will also be strongly corrupted compared to the original story. Even though the intermediaries do not purposely change the story, the story is changed, pointing strongly on our human limitations and the need of as few intermediaries as possible. Few intermediaries to spread information within the organisation (efficiency), is the only reason, but also few intermediaries to be close to the customer for the working teams (effectiveness, with connection to complexity of not knowing the customer need). This is handled by Toyota with their famous expression Genchi Genbutsu, meaning Go and See (yourself), to reduce intermediaries changing the story, since the line organisation at their production, as well as their product development, can consist of very many levels. All managers above the working team, have one by one themselves, examined the problem and its solution for a possible coming decision taking, which has made them well aware of the current situation. This way of working in a high line hierarchy means that no time will be lost due to an early start of the execution of the solution, as well as that the information is correct, meaning also that the correct product is made.
Having few intermediaries is not only good for efficiency and effectiveness, but a variant on that theme is solutions to complex problems that requires a transdisciplinary setup working together, which goes back to the former discussion about Technology Push and Customer Pull. A team with a transdisciplinary setup, means to have all intermediaries, including the initiator, the customer, producer, sales, marketing etc. in the same room in order to reduce transdisciplinary complexity, to solve a certain complex problem on the wholeness. For example, platforms need the involvement of all disciplines at the same time. Neither a disciplinary setup with traditional waterfall handovers, nor a setup of isolated team of teams with no systems design of the wholeness and no responsible portfolio above that take care of the wholeness, are sufficient solutions.
As we can see, having many intermediates will give us tremendous problems when we are trying to cope with today’s market need, of speed, flexibility and more and more complex products. But, as always, we first need to understand which of these new market needs that we need to follow for our different contexts within our domain, which means that we first need to ask why on our organisational problems within our different contexts, to find the root cause(s), as stated Before.
Common sense: Redundancy is important
Of course, redundancy is important, meaning that we, when possible, should aim for having several people or teams, or team of teams, with the same competence. If some part of a product is of utterly importance, we may also need several redundant teams that can work on that part to avoid delays. All together to increase the number of redundant people, i.e., increase the truck factor (the higher the better).
Common sense: Incremental deliveries are important
In order to be fast to the market, we need to be able to make small incremental deliveries, like features in software development. This is also important to get fast feedback during our development of the product, to see that we are on the right track. In hardware (and software) development, a system with modules within a platform is the closest we can come to incremental deliveries. This means having well defined interfaces between the modules and common requirements on sub-parts and the total, giving the opportunity to release modules independently to each other, making them; cheaper, less electricity consuming, lower EMC dissipation, etc., see this blog post for a further elaboration on the concept of Set-Based Design when making modular platforms. But, in order to achieve incremental deliveries, do not forget that the planning and transdisciplinary complexity/ complicatedness reduction by a systems design in top-down order, need to be done first of all. Also, the systems test needs to be implemented, so we can get feedback on our systems design, as early as possible.
Common sense: Too small non-repetitive activities affects both flow and resource efficiency negatively
Small repetitive activities in production are not a problem, depending on its context. But, as soon the context instead is non-repetitive activities, especially like in product development with many interactions, small activities generates many hand-overs, more coordination, participation in many different projects or parts of products that generates awareness loss, etc., with negative impact on the efficiency, see this series of blog posts for a further elaboration on resource and flow efficiency and their tight connection. Another disadvantage with small activities is that the wholeness is lost for the individuals and teams, and even team of teams in the case where there is no portfolio above that takes care of the wholeness of the organisation. Many small activities also easily lead to specialisation with too rigid roles and responsibilities. Adding on interdependencies and dependencies between the teams and specialists also means that the organisation will be fragile to disturbances that can generate bottle necks anywhere in the organisation. These negative effects regard both silo- and agile- and any other organisation when the activities are too small in product development.
Common sense: Queues of planned activities always effect flow efficiency negatively
For traditional silo organisations with projects, queues of planned activities at centralised resources like configuration management, release handling and system integration and system test (system validation and system verification) resources, have always been present, with negative effect on the flow efficiency. So, even with the best planning made, there will always be delayed initiatives, with risk that the initiatives need these centralised resources at the same time. To mitigate or reduce the effect of these queues, the solutions have traditionally been margins in the time plans, as well as overcapacity at the centralised resources. So, the solution is easy and evident, but with a too big focus on resource efficiency (sub-optimisation), the margins and overcapacity are not implemented.
The same goes for agile teams, where the progress of a team’s activities can be seen for example on a Kanban board. Having queues on the Kanban board is the same as focusing on resource efficiency instead of flow efficiency, which also is evident. It is simply not enough to talk about that we are flow efficient, we need to understand to achieve it as well. In this case it means solving the root causes to our problem that we are having queues of planned activities on the Kanban board.
Common sense: Without a common language it is difficult to communicate
This happens often when the IT department talks to the rest of the business people or the rest of the organisation. Therefore, it is always important as stated earlier to work cross-functional, or transdisciplinary, where the latter really means to work together and give and take of the team members different competences in order to solve a complex problem. The vocabulary for the deep knowledge within respective discipline is not the important part, but at a high level between the disciplines, there must be a common vocabulary to achieve fast progress, to be proactive and avoid reactiveness due to miscommunication. Therefore, it is always a very bad idea that a discipline invents new high-level words instead of using the existing words used by other disciplines, since it isolates the discipline and hampering the transdisciplinary work, instead of making the communication transparent. See this series of blog posts for the importance of using the same vocabulary regarding transformations and complexity, both critical for being successful with today’s transformations to Agile.
This was the last blog post about common senses from our free will that also are independent of scaling. Tomorrows blog post will cover the scary part when our free will is strongly affected by external forces wanting us to ignore our own common sense.
C u then.