The wholeness level, where we find the wholeness team, has both tactical and operational responsibility. It has as the name states, responsibility for the wholeness, and that yields the system’s high-level requirements, parts, equipment and environment, both for the existing systems and for on-going and coming initiatives. Responsibility for existing systems can be said to be the higher-level maintenance of the system, while the team of team-level takes care of the structure, tests, coding, etc., in their respective components.
The wholeness level is the actual start of the virtual delivery structure that is doing the operative work in the initiatives, and this structure continues down in the team of teams-level. This virtual structure can be dynamic or static, where the latter sometimes can depend on economic structures and economical follow-up needed in the organization, but it does not matter, as long as it is a true virtual structure, with no interference from the line hierarchy.
As stated above, this virtual structure also needs to be done top-down, to avoid sub-optimization, and it is also part of early analysis work. This analysis is necessary in order to understand the work amount (HOW to solve) and the work length (HOW long time) for the initiatives (WHAT to do), so the work order of the initiatives can be preliminary set, which later leads to the road map in the portfolio. This means the rough planning of; I-competence, T-competence, number of people, experience, tools, education, new or enhanced systems design through iterations, etc.
The wholeness level to a great extent deals with reducing the transdisciplinary complexity/ complicatedness of the system, which also means taking care of the non-functional requirements on the system. Altogether, the wholeness team has the expertise to do this work, with both expert (transdisciplinary) generalists and expert specialists, from the different silos/part of the organisation. Since all kinds of different complexity always means that we need knowledge we do not have, we clearly need iterative work in order to gain this needed knowledge of the systems design. This will in the end lead us to a proper architecture consisting of components, interfaces etc., which is explained in details in the article about systems design and systems test.
When we have arrived at an architecture that we have faith in, the team of teams-structure can then deliver a subsystem within the total system. since we now have a systems design with clear interfaces to the other subsystems, which can be made by other team of teams-structures.
Since the work is transdisciplinary, emanating from non-functional requirements, we need all available disciplines available to be able to sort this out; legal, security, safety, architecture, systems design, systems test, fault handling, developers, designers, UX, customers, end users, CM, release, risk & compliance, etc. Many times, these are scarce resources, centralized as well, that cannot participate full time in the transdisciplinary team for sorting out the systems design of an initiative. This team is a cross-functional team, that need to work not only interdisciplinary, but also transdisciplinary, in order to find the necessary solutions for the whole of the organisation. From time to time this can also result in a modular platform that all the silos can use and build their own modules on. It is important that this team on the portfolio level also has the mandate, or sitting next to people that have, to be able to take fast and important decisions that may impact the whole organisation. And this team can of course only take these decisions after getting the answers from the lower team of teams and team levels.
To gain knowledge, means actual coding of the architecture, to code a skeleton structure, which also, since the design is test-driven, is the start of the systems test development; test cases, test environment, test tools, etc., emanating especially from the non-functional requirements of the total system. The more novel the systems design is, there can in rare occasions be a need of having multiple system skeleton structures in parallel, but that of course comes with a cost, since also test systems may need to be built in parallel. Do not forget that also incremental functional updates of big systems, except from need of regression tests, also need the systems tests on the whole to be updated as well, and not only the tests for the new functional updates, in the updated components or updated end to end flows.
As stated before, the wholeness level can have the resources itself, or take help from the teams to iteratively achieve the architectural skeleton, i.e., find a suitable systems design. Here is a picture showing the wholeness level team responsibility, as well as how the transdisciplinary complexity is reduced, the wholeness level team reduces the transdisciplinary complexity.
When we develop a completely new product, the transdisciplinary complexity is extremely high, and literally means that we have thrown up all non-functional requirements in the air, since we do not have a systems design that match them. In order to gain all needed new knowledge, we need to do it iteratively until we understand that the systems design will fulfil the non-functional requirements. As stated above, this is the strength of Lean product development, which is needed also for software development, especially of big systems.
By reducing the transdisciplinary complexity to a level where experts are sure that we in only some more iterations can release our product, we are in the Complicated domain in the Cynefin™ Framework by Dave Snowden. This means that we now, to a full extent, can involve all component teams, which can work autonomously to a high degree with their component of the total product. To be able to leave the Complicated domain and enter the Clear domain, we need to iteratively reduce the transdisciplinary complicatedness, which normally is done with prototypes in hardware. The picture above is only showing generally how the complexity will be reduced, but most probably some components will be ready to start with, even when the transdisciplinary complexity still is too high for the wholeness to let all teams work. The UX component is a good example of an early start, which also is a necessity due to the needed collaboration with the customer in order to achieve an awesome user experience, as well as an important input to the building of the architectural skeleton. The UX team works more with uncertainty than (transdisciplinary) complexity, to make an awesome user experience.
The next article in the TDSD series is about the team of teams.