The SOSD method – Summary

Here is a summarizing diagram which starts with the purpose of the organization, achieving an awesome way of working with SOSD, 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 under construction. But, as we have understood from this blog post, 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; systems design/test, line hierarchy, 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 blog post; 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 (under construction) (for big software systems and for software/hardware hybrids; for organizations which purpose (gives the context and domain) pointing at TDSD (under construction) as the solution, the strong recommendation is to do the SPPA in order to understand the root causes. The dissolution of these root causes, which of course also includes SOSD, with the examples mentioned earlier in this blog post, will anyway be the best approximation that can be achieved before TDSD is ready. This is due to the fact that no other method or framework for bigger software systems follow the organizational principles to any high degree, i.e., too many built-in root causes.

Conclusion
Already now I think you understand that a good product development method will be a true mix of the different methods presented, which becomes obvious when looking at the pain point pictures above, where there are no over-lapping pain points! 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, or by having input from organisational problem-solving by SPPA. Both ways are possible when redesigning human complex adaptive systems, since they both follow the organizational principles. This means that they both are terrific ways to make an awesome organisation with the SOSD method.

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 Dissolution of (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.

The next blog post in this series is a deep dive into the theory behind Dissolution of problems, the SPPA and SOSD methods, and will also start to dissecting the difference between normal and built-in problems, that we so far briefly have reasoned about. The theory behind SPPA and SOSD 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.

C u soon 🙂

Leave a Reply