Why the need of TDSD?
If you have problems or impediments within your organization developing products (incl. software systems), like; too many meetings, wrong culture or values, transformations that take too long time, too many transformation coaches, people not/or late included in the transformation, efficiency problems, decreasing long-term planning, lost Big Picture, etc.? Or you just have a nagging unease, accumulated over time, from all the permanent and increasing number of problems; "is this new way of working really going to work for us? For anyone?"
Then TDSD, with its test-driven systems design concept, is a must for your organization!
TDSD is a method for making a flourishing product developing organization in any domain. Since TDSD is based on science, any organization can directly transform to TDSD, from any other way of working, method including agile scaling frameworks. The SPPA method, is still recommended to start with, in order to bring up all the problems and find their root causes, and by this unite the organization. It is then easy to see that TDSD will do the work of eliminating the organizational problems, and achieve a flourishing organization.
As with any method within System Collaboration, they are not more prescriptive than necessary, just in order to fulfil the needed science. And TDSD is no exception, which in turn indirectly means to give the control over the domain and the domain knowledge, back to the organization. Because, who else knows the domain better than the organization itself? No one external; no method, framework, or coach.
Here below is a clickable picture of TDSD for software, which links to deeper information about what is needed, HOW it works, and deeper and deeper knowledge about WHY it works, backed up by the needed and available science.
For a deep-dive into TDSD, please see this introduction.
The team of teams level