Welcome to this first article in the series about TDSD – Test-Driven Systems Design, which is a method for all kinds of product (system) development in the software domain, especially suitable for big software systems.
TDSD is, except from our organizational principles, also built on the deductions made in System Collaboration. It is already in the understanding of the deductions, where the test-driven systems design concept actually is concluded to be a necessity for any product development domain. The deductions in System Collaboration explains also the prescriptive HOW steps that need to be followed and WHY they need to be followed, all in order to be able to fulfil our organizational principles in this complex context (all principles activated), which in turn strongly decreases the solution space for our way of working. In TDSD we are taking the last step, by finally going into the domain and domain knowledge, skills and experience of the organization, the possibilities of how to do the further enhancements of the HOW, to be able to complete the TDSD for software method. Of course, TDSD also fulfils all the organizational principles, to achieve the highest quality assurance possible for TDSD, with no built-in root causes from start, which gives us the best possible chance to achieve quality assurance in our products. TDSD is by that, taking care of and solving the current, and unfortunately, too many common problems of today, when developing big software systems with current commercialized methods and frameworks. As the observant readers we are, we can understand that even though TDSD for software, is focusing on software, it can with small adaptations, also be used for hardware or as a hybrid. This due to the fact that the organizational principles activated in a specific context, as is concluded in System Collaboration, always are domain independent. In fact, this directly means that the test-driven systems design approach, is valid for all product development.
That most commercialized methods are antisystemic, was brought up by Dr. Russell Ackoff already in the 1990s, where he listed twenty of them from his mind, and not a complete list. Some of them have been dissected, to understand why they are failing, and can be found in this series of blog posts, with reference to Ackoff, and here is also a general part on how and why it is important to dissect methods in this blog post. Even though science about organizations have been available for decades, and even already in the 1990s, this list of antisystemic methods available on the market today is unfortunately considerably longer. This also yields recently new methods and frameworks for product development of big software systems, where some of them have induced even more, as well as added new problems, that we did not have earlier. It is always important to understand the past in order to build new methods on old valid and proven experience. For example, why waterfall way of working with project succeeded to fly to the moon, but why it failed to make big software systems already in the 1980s. The failure depends not only on that the limitations in the waterfall method were not understood, but also due to not following the waterfall method properly, mostly lacking the virtual delivery structure and that making completely new systems, means that there is transdisciplinary complexity to reduce. The difference between hardware and software product development, between Technology Push and Consumer Pull and the reason to why there sometimes is failure, is deep-dived in this blog post series.
Here is a brief explanation of the coming chapters in this article. To be extra clear about the need of TDSD, it is dissected in the first chapter “Why TDSD? Do we not have too many software methods already?”. In the next chapter “TDSD has the deductions made in System Collaboration as its foundation”, we will further go through why it is a necessity that TDSD for software and hybrids, and any product development method as well, originate from these deductions. It is also important to understand that when working in a complex context, there are certain steps that need to be taken, also clearly shown in the deductions made by System Collaboration. The consequences of that are that any way of working in product development need to be a method, and that it per se cannot be a framework, which will be presented in the chapter “TDSD is a method – cherry-picking from a framework is wrong per se”.
Warm welcome to TDSD!
Why TDSD? Do we not have too many software methods already?
The aim of TDSD, is to focus on fulfilling the science of the organizational principles, since there are too many methods and frameworks with too low level of fulfilment of them, generating an immense number of problems in the organization. And as described in the previous chapter, cherry-picking methods from a framework, trying to aggregate to a total way of working for product development, is wrong per se. By only focusing on the fulfilment of the organizational principles, TDSD is giving the people in the organization the right prerequisites for achieving a flourishing way of working. In this way, TDSD is also never more prescriptive than necessary, leaving slack to the organization depending on its domain, skills, competences, capabilities, experiences, people, tools, etc. The lack of appropriate methods or frameworks for software development of big software systems for the complete software life cycle, generating a tremendous number of built-in problems for today’s organizations, is therefore simply the reason for why TDSD has been developed. TDSD is derived from fundamental science, the organizational principles of people and activities, which in turn gives the deductions in System Collaboration. This is the same way as we need to follow Archimedes’ principle during the product development of our new boat, if we want it to survive the launching, and plenty more science if it is going to survive the first storm. But TDSD is also suitably backed-up of the available evidence-based problems from methods and frameworks that are antisystemic. When built on science, showing this anti-systemicness of other methods and frameworks, which is done in this article in SOSD about common root causes, is of course not needed. But it gives us the understanding of what is not an appropriate solution, a kind of anti-hypothesis, i.e., what solutions we should not bother, and not try again. This gives hopefully more confidence for you as a reader, in your struggle to change your though patterns. By finding the root causes to these built-in problems, due to the anti-systemicness of a method or framework, gives invaluable experience on not only how to not do the solution. By deducing, including also all these experience from the past, TDSD will have solutions from different old methods, and can therefore definitely be said to be a hybrid. In short it can be said that from waterfall way of working with projects, the very important top-down systems design and the need of long-term planning (top-down as well) of the product (and organization) is taken, from Lean Product Development, the iterative thinking with fast feedback loops by exploration of the product’s systems design is taken, and finally from Agile, the iterative thinking with fast feedback loops to understand what the customer really need, to reduce uncertainty, is taken.
TDSD has the deductions made in System Collaboration as its foundation
As mentioned in the series of articles about the deductions in System Collaboration, the line hierarchy is a solution that we will have in any bigger organization. This due to the fact that the line hierarchy is reducing the complexity when having many people, to get a structure and overview that we humans can handle. This means that to make any way of working easier to understand in any context and domain, we always use structures in order to reduce the complexity. Here it is also important to repeat that every structure that involves people, need to follow our organizational principles for humans of 5, 15, 150 etc., see this blog post. The numbers of 5, 15 and 150, give us some hint about some maximum size about just over 2000 persons in a rather flat virtual delivery hierarchy (flat is needed in order to decrease too many and too long chains of interactions making us lose information and trust, and probably also due to the fact that going over 200 persons doing things together, meant dividing into two parts, which also can be part of our DNA, so we can trust that our 150 persons leader, trust other 150 persons leaders), when doing really big delivery initiatives (not recommended). This is the biggest implementation that can be made, since the science is the (positive) constraint, see this blog post for more information and a picture. Regarding line hierarchies, which are like resource pools, the size has really no limits. For repetitive work that is truly aggregating parts, it is also possible that every manager will also act as a team leader and specialist on the process, which actually means that this virtual delivery structures (many different teams), each one of them, is delivering aggregated predetermined parts repetitively. Here we will also have other limitations, for example infrastructural aspects in hardware manufacturing, pointing more on other science, then our organizational principle for humans for a maximum team size of 15. Due to the presence of the line hierarchy as the primary foundation of any bigger organization, the line hierarchy will not be handled separately with more information here in TDSD, so all the details about why and how will be found in System Collaboration Deductions – The line hierarchy.
In product development, to avoid sub-optimization, we need to add the virtual delivery structure, which is responsible for the deliveries, a necessary setup in order to avoid classic sub-optimization. The reason for the need of virtual delivery structures in product development, is mainly due to the fact that a silo in the line hierarchy is not seeing the whole, making them unwillingly to have their own agenda, which sub-optimizes the delivery from the whole. From the theory behind the deductions in System Collaboration, we can draw the conclusion that in order to properly implement even the line hierarchy with its silos, we first need to understand the overviewing solution to the way of working in the context we are operating in. This means in this case the basic understanding of product development, that it is about reducing disciplinary complexity (only for hardware), as well as transdisciplinary complexity/complicatedness for hardware, software and hybrids (systems design and systems test), before we can understand how to implement the virtual delivery structures and a portfolio, as well.
And without fully understanding the systemic organizational systems design solution of the line hierarchy, the virtual structures, the systems design/test and the portfolio, it is impossible to fully implement a flourishing method. But, with common sense and the experience of past problems, mistakes and failures in antisystemic methods and frameworks, and with the help of the organizational principles and all deductions that can be done, we know the prescription we need to follow. Adding the last part, the domain, as is done in TDSD, is where the experts of the organization can guide us, and also dissolve some minor problems that we definitively will found on our journey to a flourishing organization. This means that the implementation of TDSD in order to get cohesiveness between the parts of the organization, is straightforward, where the prescriptive HOW from the deductions will help us a lot. TDSD is to some degree prescriptive, but only to the level that the organizational principles are followed, which mostly will be the principles for us humans when adding the last part in order to achieve TDSD. This gives the organization and its people the best prerequisites and understanding on how to guide themselves in the implementation/ change/ transformation, since they are the best to know their domain and domain skills, knowledge and experiences of their people.
By going through the diagram in the summary article of System Collaboration Deductions, a diagram that starts at the top with the domain and purpose, we will come all the way to the appropriate method for the actual product development, i.e., go into the domain, and use TDSD in our case. As we can understand, the experience and science already found out by mankind, that in many cases has turned into (true) common senses, makes it much easier for us to also make a good implementation of TDSD, as well as HOW and WHY it works. This means already from start with our first try, as already stated, where the one-way track in the diagram, gives us a sunny start on our first Walk in the Park. And where, as also concluded earlier, the problems of antisystemic methods and frameworks gives tremendous valuable information, so we are sure how we shall not do that (not even try), which for some of us means a complete change of thought pattern. The reason is that the failures of anti-systemic methods and frameworks, are showing anti-Best Practice, failing due to their inability to fulfil the organizational principles. For example, problems when scaling agile, which also is exemplified in this article about common root causes in SOSD, as mentioned above. From this we can understand that our chosen method TDSD, with an organizational systems design as described in the article System Collaboration Deductions – Top-down synthesis, will fulfil our organizational principles, and is really the only way forward. With all information about the prescriptions we need to follow from the deductions made by System Collaboration, as well as the above information, we here have an overview of how TDSD looks like, where we are never more prescriptive than needed; TDSD overview.
TDSD is a method – cherry-picking from a framework is also wrong per se
It also needs to be stated that TDSD is a method and not (and as will be shown, no method can ever be) a framework, and here below the reasons are presented; claiming one-size fits all is not possible where exhaustive information is not the solution, context is king, we need to understand our organizational principles and the need of organizational top-down synthesis.
The first reason for this is that TDSD is not claiming one-size-fits all, the focus is on big software systems, even if it with small changes for example can be used for hardware or hybrids for systems including both hardware and software. For different hardware development and for small software systems, there are already methods, even though TDSD also successfully can be used for all software systems, also small ones, especially when security, safety is needed or/and when the product life-cycle is long. Some frameworks on the other hand claims that exhaustive information about different Best Practice is the best. But, the more information the better, is never a good concept for any way of working, since excessive information is hard to navigate when looking for the solutions, we need ourselves, especially if the right solution is not to be found within the framework yet, which we can never know. Also, the constant updates on the home pages with more and more information added, makes us want to raise the question if we ever, and not only yet, can find the (Best Practice) information we need for our specific situation and solution.
The second reason for TDSD being a method, is the fact that we have different context, which referring to the Cynefin Framework, means Clear, Complicated and Complex. This means that it is impossible, especially for product development (complicated/complex), to just cherry-pick processes, sub-methods, tools and artifacts, even if we state that we have them all in our framework. So, apart from the excessive information and the updates mentioned above, the really important consideration is that it is never stated what parts in the framework that will become a unified and well-functioning way of working when aggregating the parts for our context and domain. This in turn induces that neither the product will. We can conclude that more, is here definitively (worth)less.
The third reason, is that we always need to follow the science, not only our organizational principles, but also the deductions made in System Collaboration. This means that it exists very few different solutions, meaning that when cherry-picking processes, sub-methods, tools and artifacts to become a satisfactory solution, we still need to understand and follow all our organizational principles, i.e., we most probably need to change our thought patterns. Without understanding the existence of our organizational principles, will of course lead to an extremely high risk of the solutions to be mostly mal-functioning solutions.
But most of all, is the fourth and final reason, that TDSD is not a framework depending on the need of an organizational systems design when making any way of working in order to reduce the inherit transdisciplinary complicatedness. This organizational systems design always has to be done top-down, in a top-down synthesis approach, which was stated in the series of articles about System Collaboration Deductions. These deductions are the foundation not only for TDSD, but any product developing method, also for hardware product development methods like waterfall (silos with projects) and Lean Product Development, that already have similar foundation with line hierarchy, virtual delivery structures, systems design and a portfolio.
The conclusion of all this, means that we can never make our own framework for product development (and will be very difficult in non-complex contexts too), where more details can be found in the series System Collaboration Deductions. Just having a particular set of rules, ideas and beliefs, home-made or collected, and to that add all famous small methods available and try to aggregate everything to a united and unified whole for a way of working, no matter combination, is therefore wrong per se. The reason is that we need to state validity (the need of fulfilling the organizational principles) for any combination (organizational systems design of our way of working) of the aggregation of all these small methods, and we could see in the deductions of System Collaboration, that there was really only one overviewing solution that follows the organizational principles for product development. But unfortunately, this is obvious not the reality (since we already have frameworks), and the frameworks instead let their users cherry-pick small methods and other needs from a smorgasbord, what the users with the help from framework coaches, think is valid for their way of working, to try to achieve scale. And if the organization fails, the answer from framework coaches will always be that they picked the wrong methods, or implemented them wrong, or not everything in the framework, with the latest mantra “it will take 5-10 years to get it right”, leaving the organization with the failure. This cherry-picking approach is invalid also for any systems design of a product (cherry-picking (new) components), and not only for a way of working (cherry-picking sub-methods/people/parts/value streams/dimensions/or any other division of the organization). Instead, we need well-informed hypotheses, that during some iterations are integrated, verified and validated, to understand the validity of the way of working, i.e., that we have fulfilled the organizational principles. And since we have both our organizational principles to validate against, as well as tremendous knowledge of success and failure of existing methods, it is not as tricky as we think to achieve a flourishing way of working. It is instead straightforward.
Next article in the TDSD series is about the need of always planning an initiative.