Here is a summarizing diagram, achieving an awesome way of working with System Collaboration, which starts with the purpose of the organization and that shows the needed order and the domain independent parts that must be implemented in product development for big products, no matter domain. It also recommends a way of working of already existing methods today that will be most appropriate for the domain (hardware or software) of the organization, depending on the need. As we can see, there is not yet a method or framework fulfilling the organizational principles good enough for the software domain, especially big software systems, i.e., agile at scale is still a nut to crack. That is why Test-Driven Systems Design – TDSD both for software and the hybrid for hardware and software, is a must. But, as we have understood from the articles in this series, and which also is shown in the picture, the foundation for all product development of big products for hardware and software domains is the same; line hierarchy, systems design/test, (flat) virtual delivery structures and a portfolio are all needed.
Any new organizational way of working, is really a prototype, resulting in a lot of feedback from every prototype of the way of working, until we get it right. But thanks to all experience already built-up during thousands of years, common sense and the organizational principles we are able, if we are willing to of course, to make a really good organization already from start. So, in the diagram above, all natural feedback loops have been removed in order to not make the picture too busy and some things have been taking for granted.
As we understand from the diagram and all these parameters to consider and the fact that product development needs to follow all the organizational principles, narrows down the available ways of working for product development, to the ones taken as examples in the beginning of the article; waterfall projects with prototypes (mainly for hardware), Lean Product Development for hardware, Agile for small systems and Test-Driven Systems Design – TDSD (under construction) for hybrids and big software systems. Why these are chosen, and not others, depends a great deal on that they all rely on common sense, which can be read about in this blog post series about transforming with common sense. But, as can be understood from that, sometimes common sense is not enough, and in worst case commercial forces start trying to make dubious things, to make something uncommon to become a new common sense, to fit their purpose, see this blog post about how sometimes common sense is supressed and why. That is why we need the Organizational Principles as fact, so we can keep our common senses clear. Another good series that shows the way towards a good way of working is the implications our organizational principles, which can be seen in this blog post series. Putting common sense, the organizational principles and the implications together can be read about in this this blog post series about trembling steps towards our method, which also includes the very important scaling aspects. To understand more deeply about why these respective methods are chosen and how they neatly handle all our organizational principles for their respective context and domain where they are appropriate, and also their weaknesses, the following blog posts are recommended:
Waterfall projects with prototypes (for hardware with incremental update of existing product); The Way of Working history series, Value Stream Mapping on projects, Effects on resource efficiency, Sometimes too many people in projects.
Lean Product Development (for novel products and platforms); The pillars of Lean Thinking series, The New New Product Development Game article in our set of principles series, Lean Product Development’s anti-clogging system, WIP Inventories are great Flow Efficiency enablers in Lean Production.
Agile (only for small software systems); Sequential or parallel work – which is best? – part 4/6 – Agile way of working, WIP Limits in Agile development are sub-optimising our organisation, Flow efficiency – part 3/5 – Value Stream Mapping done on an Agile team’s sprint, Flow efficiency – part 4/5 – Agile’s calculation of flow, Process Cycle Efficiency, is sub-optimising our organisation, Are you stuck in a rabbit hole invaded by “experienced” artifacts?, Are you stuck in a rabbit hole of blinding new methods?, Are you stuck in a rabbit hole of Gig Bang integration testing?, Aggregation vs Integration vs False integration.
Test-Driven Systems Design – TDSD (for big software systems and for software/hardware hybrids; for organizations which purpose (gives the context and domain) pointing at TDSD as the solution, the strong recommendation is still to start with SPPA in order to understand the root causes, and make them visual for the whole organization. If TDSD of political or other reasons cannot be implemented, dissolving the found root causes with the help of the method SOSD, will then be the best approximation that can be achieved. This is due to the fact that no other commercial method or framework for bigger software systems follow the organizational principles to any high degree, i.e., too many built-in root causes, which means low efficiency and in worst case a non-working product.
Conclusion
With the organizational principles as foundation, the deductions made in System Collaboration shows that we must start from the organizational purpose, no matter context, which then always means “top-down”, when we are making any way of working. The reason for this is that the deductions also shows that every way of working is a top-down systems design, analysis followed by synthesis, in the same way as for products. That is also the only way to eliminate organizational problems, i.e., dissolve the problems. And of course, the systems design always needs to fulfil our organizational principles in order to make the organization flourishing. If the way of working does not fulfil the organizational principles, we will get organizational problems that for sure generate bad results, as well as bad human behaviour in the long-term run. In product development this would mean that we, not only risking to get a bad inner efficiency (like a slow and expensive way of working), but also risking to get a non-working, wrong, expensive and non-qualitative product as the result from our mal-functioning way of working. In worst case we get all of these non-favourable results, jeopardizing the existence of our organization.
From the deductions we can also see that a good product development method will be a true mix of the different methods presented, which means that different methods has concentrated on different results that they actually are good at. This becomes even more obvious when looking at the pain point pictures with common root causes, in this article in the series about SOSD, where there are no over-lapping pain points between agile at scale and waterfall! Agile product development, Lean product development and the traditional organisations with projects and the waterfall method, the first good at the soft people side and the last good at the hard activity side and scaling, and the middle is quite good at both, but originates from a hardware context. And it does not matter if we build the organisation from scratch with TDSD, or by having input from organisational problem-solving by SPPA, and using SOSD. Both ways are possible when redesigning human complex adaptive systems, since they both methods (as well as SPPA) always are following the organizational principles. This means that they both are fantastic ways to make an awesome flourishing organisation.
And as you were promised from start, no rocket science in sight, only this:
Without changing our pattern of thought, we will not be able to solve the problems we created with our current patterns of thought.
– Albert Einstein
We simply need to change our pattern of thought about human complex adaptive systems, so we treat the way of working as ordered, but where the multiple interactions used for solving our initiatives with our way of working cannot be foreseen in advance. Together with the organizational principles that every way of working need to follow, this leads to that if our way of working is not following the organizational principles, we will have symptoms and consequences, that in turn of course have originated from root causes happened in the past. And since the organizational principles are science and the root causes frankly are non-fulfilled science, the problems can only be dissolved. This means that the way of working (also includes people structures) needs to be redesigned, which is what Dissolve the (organizational) problems is all about. It also means that if we try to solve symptoms and consequences which is impossible, it is not until then we have improperly intervened with our human complex adaptive system, leading to even more severe unintended consequences per se, or “a mess – a system of problems”, as Ackoff put it.
Putting everything together, we can understand that, if we are following the organizational principles for our total way of working (including for example TDSD for developing big software systems), it will have exactly the prescription needed, but not more than that. This means that we, no matter context, always will give our people the right prerequisites for both getting the proper activities to solve, as well as the prerequisites for solving them (or the problems that sooner or later will occur in the product or the way of working, for example due to a changing environment). But it also means that there are never any additional unnecessary prescriptions, since that will only will hamper our people’s interactions. More prescriptions, and our people will not get the freedom needed to solve the activities, or make innovations, i.e., it will lead to a sub-optimization. This freedom is very important since the remaining solution of the total way of working (including for example TDSD for developing big software systems), depends on the people’s skills, competence, experience, etc., as well the developed, manufactured or delivered products or services. This is unique for any organization, and can therefore never (ever) be prescriptive, and our own people are the best guides to get this right. This is especially valid for setting up the different delivery constellations (virtual delivery structures), consisting of many teams on different levels with different sub-deliverables, which strongly depends on the current skill, competence and experience in the parts (guilds) of the line hierarchy.
This was the last article in this series and the next article, and the compromised list of all the deductions in this series can be found here.
Well connected to this series, in order to get a further deep-dive into the theory behind Dissolve the problems, used in the SPPA, SOSD and TDSD methods, is this one. It will also go further into dissecting the difference between normal and built-in problems, that we so far briefly have reasoned about. The theory behind these methods is extremely important to understand, since it further brings light on WHY they work. It also brings the light on the necessity of using them in the first place, for all organizational problem-solving, to be able to make a proper redesign, to achieve a flourishing way of working. This in turn leads to WHY methods and frameworks not following the organizational principles therefore will not work, which is further examined in this article.