Today we continue with our elaboration on the article The New New Product Development Game [1] and its fulfilment of our set of principles. Here is the next principle.
Principle: We need to have timely* Integration Events** end to end – (to get just-in-time* feedback).
Through the whole development of a new product the Integration Events need to be timely, so we get the feedback in the right time. The more uncertain we are, the faster feedback we need to gain knowledge, which means very short time boxes, this is what the authors mentions about amplifying variety (differentiation). The “built-in instability” and “self-transcendence”, mentioned in the article, is exactly what is needed when we deal with complexity, since the work cannot be broken down when the goal is not exact, and with hardware we do not know if the realisation is feasible as well. We need to iterate frequently with very small time-boxes to get fast feedback, so we can gain knowledge both about customer needs and possible technology realisations, and then iterate again. Experimentation means that we try new ways, push the boundaries, challenge the status quo, so we can fulfil the broad goal set from the start of the project. The article states that the companies did this iterative experimentation even in the latest phases. “Subtle control” and “autonomy” are most important when we have complexity, because what comes out from all the experimentation is impossible to know in advance, no time plans can be made, etc, so the teams need to self-organize to find the way forward.
And remember that to leave the complexity behind, we need to learn by experimentation. Experimentation must not be mixed up with making mistakes, which is very common. With a we-do-not-make-mistakes culture, experimentation to gain new knowledge, will be very difficult, and is instead heavily constraining innovation.
And the other way around is that, the more knowledge we have, the longer time boxes we can and should use, this is what the authors mentions about reducing the variety (integration). And during the projects, when coming to the ordered domains, this integrated approach is continued with frequent Integration Events, to continually test prototypes before the full solution can be ready.
A perfect match again.
Principle: We need to have end to end control of our activities and their interdependencies, especially them on the critical line, when we are developing our system product and its deliverables, both short-term and long-term as well as on the different levels of our organisation.
Planning has always been a strong part of hardware product development, since the start of the introduction of projects in the 1950s. And the more a company worked with its projects, the better they become on estimation the time needed for the different activities in the projects. So, even if projects are not exactly repetitive, the phases of the projects are repetitive, and many activities within the phases are similar, but with different content and length. This mean that the companies over time become more and more experienced about how to make good estimates of the activities. Especially good for learning to not have too short fixed length time boxes (sprint) for a team that do not need to synchronise with other teams. The reason is that the fixed length time boxes will accumulate the margins, instead of understanding that a problem will not occur in every sprint, rather more seldom. This is further elaborated on in this blog post.
And the total delivery must always be planned, so we not unnecessarily block our teams working in parallel. Because, there will always be interdependencies between the teams and to common experts, that can never go away.
The core multi-disciplinary teams in the article had the responsibility for the total planning of the projects through the whole projects, end to end. Together with that hardware projects traditionally are very strong in planning; our planning principle is also secured. A perfect match again.
Principle: We need to have control and responsibility over the system product’s architecture and its parts.
Nothing is stated in the article about the products’ architectures, but we can take for granted, that this was thoroughly thought through, since hardware companies with project way of working over the decades have gained great knowledge about the necessity of a strong architecture, especially when you work in waterfall phases. And without a good architecture from beginning, the product will not be long-lasting.
This was all for the activities part of our set of principles, and in next blog post, we will go through the people part, to see how the companies in the article maps to them. C u then.
*according to context and the needed flexibility, which means that we need to understand, nourish and be able to do work in every domain of the Cynefin™ framework, and also recognize and promptly respond to context switches, deliberate or accidental.
**in manufacturing we have Aggregation Points, which is a special case of Integration Events taking zero time.
References:
[1] Takeuchi, Hirotaka and Nonaka, Ikujiro, ”The New New Product Development Game”. Harvard Business Review, Jan 1986 issue.
Link copied 2018-09-05:
https://hbr.org/1986/01/the-new-new-product-development-game
[2] Snowden, Dave. The Cynefin™ framework. Link copied 2018-10-04:
https://www.youtube.com/watch?v=N7oz366X0-8