This is the last blog post in the series about the first trembling steps towards Our Methods and in today’s blog post we have the summary of this series.
When putting everything together we can in the light of our set of principles and their implications understand why we from the beginning in the church and military started with silo organisations, as well as the understanding why we added projects in the 1950s. See this series of blog posts for the details about the history of organisations and the market and also this series of blog posts about human science.
In the same way we can understand why silo organisations with projects on a slow static market worked with Technology Push, but Customer Pull with non-solved complexity made it harder and which is the main reason why software projects had much higher failure rate than hardware projects, where the details can be found in this blog post.
Finally, we have the market of today that requires speed, flexibility and has more complexity when we are solving our products. What we can then see in the light of our set of principles, is that the biggest problem in big silo organisations of today, is the understanding of how to solve complexity and avoid hampering of the category of the principles that regards the integration of the product. The former means that we need to experiment with multiple and contrary concepts to fast get new knowledge and see if there is a solution or not for any of the concepts. It is very important to understand that it is impossible in advance to predict the feedback loops in the Complex domain, so the feedback loops need to be as fast as possible meaning no cadence is possible at all. The latter about integration, means that the actual solving of the activities and their interdependencies, and putting the product together, are difficult and time-consuming if the needed interactions are hampered and T-shape possibilities are low. This in turn will give us only aggregation possibilities, not the needed integration. At the Integration Events – IEs – the parts are integrated to something bigger and verification is done on the wholeness, where the time to the next IE is context dependent. The more obvious it is, the more sure we will be that we will be successful, which means that the time until the next IE can be longer, since small activities means unnecessary starts and stops. And when our work start to get obvious, then it is possible to use some sort of short ar/and long cadence. But, remember that it always depends on context with the need of always beeing flexible, so for product development regarding hardware, cadence in any form will slow down the flow. Here is a picture of the complexity of product development built that we need to be able to handle, regardless if it is HW, SW or any combination, no matter the way of working, method or framework we are going to use, here also as a pdf file, The complexity of product development version 0_996.
Note the plannable axis, where at the start at the portfolio level up to the left, nothing is plannable at all, and is still not plannable when reaching the team level at the bottom left, which is the reason for having multiple and contrary concepts. If the team level shows that the complexity reduction is successful, planning starts to be achieveable. When a concept is validated as a possible solution, it will over time be more; predictable, cadence is possible, longer and longer sprints are possible, we can have detailed & standardized & stable processes, take decentralized decisions, more clearly specify our DoRs and DoDs, etc. But, as always, it depends on context, so we always need to understand its problems and how to solve them, which is the reason for the “yes” and not a yes.
Note that we have complexity on different levels in the company, which means that each level need to be able to experiment in order to gain knowledge, even on portfolio level, or where they at least must be able to put together people from different disciplines to at least have the possibility to generate new transdisciplinary thinking. Without starting with the wholeness and see what need to be achieved to be long-term efficient and effective, the risk is that each part is sub-optimising, so we only get partly short-term wins, not gaining the organisation in whole.
The team at the portfolio level, consists of experts from the different silos/part of the organisation. This team is a cross-functional team, that need to work not only interdisciplinary, but also transdisciplinary, in order to find the necessary solutions for the whole of the organisation. From time to time this can also be a modular platform that all the silos can use and build their own modules on. It is important that this team on the portfolio level also has the mandate, or sitting next to people that have, to be able to take fast and important decisions that may impact the whole organisation. And this team can of course only take these decisions after getting the answers from the lower team of teams and team levels. As you understand, this is the closest we can come to decentralized decisions in a complex system as the organisation is, since only the top level have control over the wholeness. This is contrary to production, where the work can be reduced to parts and local decisions are possible.
We can also understand that KPIs, control and measurements on silos leads to egoistic parts and indirectly also is a disrespect of our people wtih many unsolved problems left untouched. This inevitable leads to sub-optimisation, making it impossible to handle complexity and also even more hampering the integration and the need of free interactions to solve the problems of product development.
To much measuring on the silos or their parts, easily leads to a culture where no one wants or dare to take risks and make faults. This will hamper innovations, since they have a high need of experimentation for gaining new knowledge, which is neither possible to control nor measure. Here is the same pictures as above, but with the line organisation in the background, to show its tree hierarchy in comparison with the interactions all over the organisation, that is needed to make the right product in time, to the right cost and quality. Here is the pdf file as well, The complexity of product development with the line version 0_996.
But, do not forget that among all other important things that the line organisation is responsible for, we also need flexibility, which is the reason why we need to have the working organisation and the line organisation separated.
For example, the Lean Product Development methodology takes care of the complexity in product development, even though its focus has been on hardware, where the difference to software actually is small. And if we are looking at the principles Toyota is leaning on, there is no difference at all. In Lean product development complexity is handled by Set-based design, multiple concepts and platforms to solve complexity with low risk and by nourishing full-time resources, T-shape (also end to end) and short chains of interactions* for the actual work. This shows a methodology that follows our set of principles to a very high degree, where the details can be found in this blog post. We can then also understand why Toyota has been so successful, since they cannot only make new easy-producible car models on their platform very fast, they can also produce them fast and with high quality with their Lean Production methodology, which follows our set of principles to an even higher degree, where the details can be found in this blog post.
The HBR article “The New New Product Development Game”  is also showing other Japanese organisations that follows our set of principles to a very high degree as well, also here with plenty of new innovations in the stated projects, where the details can be found in this series of blog posts.
Regarding the teams they can be any x-shape, but to take care of wholeness on the levels higher than the lowest, there must be not only a transdisciplinary setup to be able to cover all disciplines, but also to be able to have the best prerequisites for doing innovations and make platforms with modules taking care of the whole, when needed.
Note! Frameworks for scaled agile most of the times do not have the Big Picture. Apparently, they know about this since they first start to implement the parts (value streams), hiding as long as possible this fact. And the reason why it is possible for the framework to get away with no control of the Big Picture, is because the part of the old organisation that have control of the Big Picture normally is top management, which are not only the last ones to be transformed, they are also the ones with least understanding of the way of working, both the current one and the new one transformed to.
As we have seen through the history, we can understand the evolution of the organisations, the silo organisations and their projects are perfect for slow Technology Push, but not for Customer Pull when the complexity is within the projects. From this we can also understand the hundreds of different methods trying to take care of silo organisations that did not work especially in silo organisations that did not respect their people, but of course also due to KPIs making the silos egoistic. We can therefore also understand why the Agile movement for software development started, since the methods did not work out as expected, mostly failing.
With our set of principles, we can easily see why the methods were failing, since most of them are violating at least a few principles. This is also brought up in this series of blog posts examining many famous methods that Dr. Russell Ackoff believed were antisystemic (sub-optimising) , which also regards Continuous Improvement** done on organisations as he stated. Silo organisations with KPIs, suboptimise on the people side and the agile organisations ignore the planning effort needed on the activity side of our system start definition “People that interact to solve activities with interdependencies”, and frameworks that are scaling agile many times sadly on both sides. And when we on this sub-optimisation also add disrespect of people, an organisation is in deep trouble. Trying to do Continuous Improvement** on parts (any direction) of organisations that are already sub-optimising, will severly deepen the problems instead of do any use.
But, with our set of principles, their implications and from this series we now know how we can set up Our Method for product development (mostly) on a high level, where we also can see examples of different product development problems that can be actual depending on domain in this blog post. We can now make successful organisations from scratch, or change any organisation to the better, since we with the Prefilled Root Cause Analysis Map can find the root causes to any organisational problem, as well as fix the problems.
Here is Our Method for product development (mostly, but still general to some extent) on a high level as a picture and as pdf, Our Method for product development ver 0_95.
And here is our total organisation definition for product development again, covering the WHAT for all different contexts:
Respected people with a common vocabulary, working full-time in a flat hierarchy of teams founded on the numbers 5, 15 and 150, also in the light of Conway’s law, with the right specialist competence, and understanding the Cynefin™ framework and Conway’s law, that in parallel if needed, interact freely and end to end over the whole organisation in as short chains of interactions as possible, giving them the necessary broad competence to directly take care of organisational problems as well as do continual improvements, and therefore be able, to efficiently and effectively solve product problems, by first exploring to gain new knowledge, activities with interdependencies, fully planned and under control, to be able to build the system product or service, incrementally if possible, always with the appropriate architecture under control and responsibility and always with timely Integration Events and Aggregation Points depending on context, to get just-in-time feedback, where also the long-term critical line, activities, interdependencies, Integration Events and Aggregation Points are fully under control, and visualised as well.
We have not talked so much about a method for production, but here is one that of course also are following Our set of principles, which as we can see is much easier, since many of the principles never are “activated” in the Obvious domain of the Cynefin™ framework, where we have the production line. Here is the picture for production and as pdf, Our Method for production version 0_95:
What can be seen when comparing production with product development is three vital issues where production has limitations and that regards; limited to only aggregative scalability, limited to take care about solving activities*** in the Obvious domain only and limited to have low or no flexibility to take care about changes in the environment (more than changes regarding the production volumes). All these three issues, product development need to be able to handle. This means that Agile organisations need to be vigilant, since Agile development had its starting point in Lean Production, with the obvious and high risk of being non-flexible.
What also can be seen in the picture is that the organisational solution in production is a Functional organisation, which is also the normal recommendation and the most common solution for production companies.
If we make a organisation definition only taking the production context into consideration, it will look someting like this, a much easier and shorter than the total definition:
Respected people with the right specialist competence, working full-time in teams built on the numbers 5 and 15, that within the teams interact to efficiently solve activities with no interdependencies, fully long-term planned and under control within the team, and that together with the other teams repetitively build the system product linearly, always with timely Aggregation Points, to get fast feedback, always visualised.
When we look at the differences between the our total organisation definition and the organisation definition for production, we can clearly see the problems that software development using Agile has, since it started from the methods and tools within Lean production. Especially obvious it is regarding scaling that in product development is not aggregative, see this blog post for a deep dive about scaling problems within organisations.
From the product development method above, we can also easily make one for a service organisation, that will probably be something closer to production than product development. This can be done by removing parts that are not valid for a service context, but of course we can generate a method from any other domain and context. Try yourself, it is much easier then you think, since it to a great extent is common sense, see this series of blog posts about common sense for a further exploration.
This was all for this series, c u soon again.
Next “chapter” according to the reading proposal tree is the wrap-up blog post of the whole System Collaboration Blog Book, but first the branch about problem-solving, symptoms and root causes should have been read, where the series of blog posts about how to boost your problem-solving ability is first.
*bottom-up preparations built on trust are made for decisions, to make the long chains of interactions in the line hierarchy regarding decisions less calender time consuming, see also this blog post by Dave Snowden about trust being earned and cannot be pre-designed into a method.
**remember that on the whole only continually improvements can be done, due to the synchronisation needed between the parts when the respective part’s improvements are executed at the same time, for example takt time change. The parts can (and must) themselves be continuously improved, as long as they do not affect another part.
***at production problems, of course issues that is handled temporarily to not stop the production, will be solved outside the production line and can be problems in the Complicated domain, or even in the Complex domain, see this blog post for the details about Lean Production’s high flow efficiency.
 Takeuchi, Hirotaka and Nonaka, Ikujiro, ”The New New Product Development Game”. Harvard Business Review, Jan 1986 issue.
Link copied 2018-09-05:
 Ackoff, Dr. Russell Lincoln. Speech. “Systems-Based Improvement, Pt 1.”, Lecture given at the College of Business Administration at the University of Cincinnati on May 2, 1995.
The list at 03:30 min, the national surveys at 03:40, and the explanation at 04:48 min. Link copied 2018-10-27.