Today’s blog post will take up the differences between aggregating the product, that is used in production and integrating the product, that is used in product development. These differences are important to understand when we are adopting and adapting tools, methods and thinking from production to product development, since we do not want to end up with false integration.
First, we need to understand the difference of integration and aggregation, since it is key. This explanation is from Wikidiff [1], and more explanation within parentheses.
Aggregation – The act of collecting together (aggregating).
(there is no complexity left, all knowledge has been gained, so we can combine the parts, because we know they will fit and work together as a whole)Integration – The act or process of making whole or entire.
(the transdisciplinary complexity has, by iteratively making the systems design, been reduced to transdisciplinary complicatedness, which means that there is still some knowledge to gain at some integration events, for example via prototypes, before the parts will fit and work together as a unified whole. The last prototype will be the successful release where also the transdisciplinary complicatedness has been eliminated)And here is an explanation of False Integration:
False Integration – A treacherous (and extremely risky) combination, in product or system development, of aggregation and integration
(the complexity has not been properly reduced (non or no complete systems design), which means that the knowledge to gain still is in the complex or complicated domain, meaning that even if the parts fit together, they will not work together as a unified and well-functioning whole)
So, at product development we use integration to check if the parts we are developing, fit together as intended to make the well-functioning whole product as specified, and these occasions we call Integration Events. Event since it is really taking some time, with many participants and we do not know the exact result that we will build the coming work on. Another way to put it is that during the systems design, the complexity level of the entire whole, has been reduced to complicated (in the Cynefin™ Framework), but which still means that we have some more knowledge we need to gain when we are integrating the parts for every iteration (of a few). One way of gaining this knowledge step-wise is for example by the use of a few planned prototypes. To summarize this, it means that we know that we with a few iterations of prototypes, can gain the knowledge we need to fulfil the specifications, but when testing every prototype, we only know that we can fix the problems we will find, since the problems are unknown.
As you understand, false integration is definitely not the place where we want to be, but unfortunately it is easy to end up there, see also this blog post about artifacts that are negatively influencing our way of working. If we start with an agile team in a small company, it has definitely done a proper systems design (only an architecture is not enough) on the whole product, no matter if the team is working with modules or end-to-end functionality to the customers, or a combination. If we add some more teams, they will still have control over the whole product. But, if a big company starts its agile journey with one team, only working on a part of the total product, there is a very different scenario. The reason is that it many times means that the big company goes from the waterfall method with modules, to an incremental approach with features and user stories, end-to-end slices of customer value. This new agile team has no control over the whole, and if the agile journey with scaling frameworks continues like it often does by a bottom-up strategy, soon all teams are agile teams, but these agile teams together will neither have control of the whole. It will be like every agile team makes their own gig, and then we think we can just sum it up to an entire whole. To be clear this has nothing to do with agile itself, it is the scaling that is made wrong, missing the systems design on the whole. So, in order to avoid Big Bang integration testing, we have with this false integration ended up with, hmmm, let us just call it Gig Bang integration testing, to make it easy to remember. And with this gig strategy, dividing the functionality in small parts that is analysed, designed, tested and deployed by the teams, the risk is extremely high that we also end up lacking a proper system test. This in turn means that we not until our code are in production, can finally see if the code is working or not, since we do not have a proper system validation and verification. And without a proper systems design, most probably not.
But, at manufacturing, we aggregate all parts together to the whole product because we know they will fit, since that has already been secured in the product development. This means also that we have no interdependencies or Integration Events. And if the product development has done a great work, the parts are easy and fast assembled at the Aggregation Points, i.e., enabling the Flow efficiency at the production unit to be high. We instead use the word Point here, since we know that the parts will fit. When a product is aggregated at the Aggregation Points in Toyota/Lean Production, which we can call Continuous Aggregation, it is refined in one of the many hundreds of simultaneous processes at every takt time, every few couple of minutes. Between the processes there is only a dependency, a clear handover specification of what to leave to the next process. Each car is like a value stream, or a pipeline, where parts continuously are aggregated. Here is the picture of the aggregation in Toyota’s production of cars.
Before a car is delivered to a customer, a production test is for sure made, in the case some component in the car may be faulty
As we understand, false integration where no systems design has been made, in combination with Continuous Integration without a full system test of the product within the value flow/pipeline, is definitely not the place where we neither want to be. But unfortunately, it is easy to end up there since Continuous Integration in software development is copied from Continuous Aggregation in production, where only an inspection (which can be mistaken for validation) of the car is done in the end with a production test. Continuous Integration means that pieces of functionality and their respective tests are continuously added in the pipeline, which means validation of the product, but not verification of the product or system. To make a system test of the product or system, means that tests for the functional and the non-functional requirements need to be added, which are not part of the original production pipeline. And when combining so that many Continuous Integration pipelines make a full system, they must all together be system tested, and who will take care of this? As you can see it is treacherous to copy a way of working from production to product development.
And we also understand that the aggregating processes in production are highly autonomous if we compare with teams in product development. When we have interrelationships like in product development done in parallel, i.e., activities with interdependencies that need interactions to be solved, we need interdisciplinary work by persons from different disciplines at the same time to solve the interdependencies. Here below is an example from parallel work with I-shaped teams.
There is no difference if we have cross-functional, Agile teams, there will for sure be interdependencies that needs to be taken care of, even if they are of a different kind, see this blog post for the details. This means that no matter what shape of the teams in product development, they are far less autonomous, which totally depends on the number of interdependencies between the teams.
So, every time we need to develop a product or service, we need to make an architecture, structure and divide our work into parts by help of systems design, which will help our system to be coherent and cohesive. But, to be able to put the solved parts together, we need to take care of all the interdependencies between the parts and integrate them at the Integration Events, where we by testing, investigate if our solution fulfils the functional and non-functional requirements.
This means that, if we in product development think that we can aggregate all our parts, without first doing a systems design, like the parts were independent from each other, we will fail organisational principles directly. In this case, we are failing the understanding of complexity. Which in turn will give symptoms in our organisation. And, if we are trying to cure the symptoms, we will be sub-optimising.
The difference between aggregating and integrating, means of course also that we need to be very careful when we are adopting or adapting tools*, methods* and way of working* from production, to be used in product development or other complex contexts. We really need to understand why a certain domain uses the tools, methods and way of working, otherwise we must never ever transfer them to product development, since there is an extreme risk that we instead will sub-optimise our organisation**/***.
The next “chapter” according to the Reading proposal tree is Our first trembling steps to our methods blog post series, or the blog post WIP Limits in Agile development are sub-optimising our organisations for another deep dive.
C u soon again.
*Example: Theory Of Constraints, TOC, is another tool from production, that by asking the question “What to change to?” and “What to change to?” often means that a gap is to be filled, which is not proper for any problem-solving of organizational problems which are in the complex domain of the Cynefin™ Framework, since organizational problems are only symptoms, so we simply must ask why first.
**To be clear; first we need to understand our problem, and then we need to ask multiple why until we find the root cause(s), because we can only solve root causes. And when we have found the root causes, we for sure have changed our mind, because now we see that we have easy solution(s) in our own hand.
***But, even in Lean Production, there is always a risk for sub-optimisation, and Toyota realised that many years ago, when they reached the end of the road for removing anti-systemic**** waste in their production. This is the reason why they do not talk about Ohno’s 7 waste from 1978 anymore (this first edition of The Toyota Production System was translated to English 1988), and instead since many years instead talk about 4 waste [1], where one of them is the dominant waste maker. This is elaborated on in this blog post, since it is of utterly importance; it is the difference between anti-systemic**** and systemic waste, that we with our set of principles and the Prefilled Problem Picture Analysis Map, already have touched with the symptoms and the root causes.
Toyota’s change in waste thinking, means that if we continue to use four decades old information from Toyota and transfer it to product development as well, we are not only using out-dated information and not understanding the why, we have really not understood the essence of Lean.
****sub-optimising the system, see [2], a film with Dr. Russell Ackoff talking about systems.
References
[1] Monden, Yasuhiro. 2012. Toyota Production System: an integrated approach to just-in-time Fourth Edition, CRC Press, Boca Raton, Florida, USA.
[2] Ackoff, L Russell. Systems-Based Improvement, Pt 1.
Link copied 2018-10-27.
https://www.youtube.com/watch?v=_pcuzRq-rDU