When making the team of teams’ constellations, the organization itself has a huge input to make this successful. Once again, the reason is that we with TDSD, are completing our way of working by adding the domain and domain knowledge of the people in the organization. But, remember that we always need to follow the organizational principles, and here the ones for us humans are the ones that is the main interest; team size, short chains of interactions, few activities at the same time, etc.
Here below is what to think about and a proposal for team of team constellations will be made.
The teams in the team of teams-level are mostly operational and will either work with backend components or the frontend (UX) component, from the systems design that the wholeness level is responsible for, see here for the deductions made, to understand why the division into backend and frontend is both necessary and possible. In very big systems, it is though suitable, that the team of teams-level together will with the wholeness level, also make systems design for a whole big component at the highest level of the architecture.
The teams working with the UX part, will be the ones that work closely with the end users, in order to iteratively make an awesome UX. The UX teams are the teams that works mostly with end to end-functionality, compared to the backend teams, that mostly works inside components. But, no matter backend or frontend teams, every team still delivers their functionality verified and validated, which means that they are T-shaped, with analyse, code, test and build. But, for big software systems, the teams will be slightly different, since it is not possible nor efficient to learn everything, as well as it is not possible to deliver end to end functionality, due to the extremely high risk for a crappy systems design. This means that for big software systems, there is actually not a very big difference from hardware teams that also deliver their component verified and validated, even though we normally look at the hardware teams as I-shaped teams.
Regarding maintenance, it is possible to add that responsibility to the teams as well, even though systems design issues, should be appointed to the wholeness level. Every team on the operative levels has their own %-level for maintenance, i.e., incidents and Technical Debt, which depends on current status of the code, recent releases, etc. For items with lower severity in this internal maintenance backlog, decentralized prioritization can be made of the respective teams themselves, as well if there is a maintenance backlog on the team of teams-level.
Remember that all competence needed for developing big systems cannot be hold within the team, T-shaped or I-shaped does not matter, even if that would be nice to have. The reasons are many, but some of them are; the wholeness is not within the parts, every individual does not think everything is fun to do, some competencies require a very long education, it is not possible to learn everything (brain overflow), and finally the need to plan and prioritize the wholeness within the organization. This means that we need support functions, or centralized functions, with resources that is not full-time resources, with special education or individuals spanning over many initiatives, i.e., the wholeness within initiatives or within the whole organization. These are resources like, CM, release, systems testing, test coordinating, law, legal, risk & compliance, security, safety, enterprise architecture/design, etc. But as long as we understand that, it is only about planning, so we avoid that the teams use the resources at exactly the same time.
In the dialogue between the teams and the portfolio, it is beneficial to use severity levels for incidents, to make the portfolio able to take a long-term strategical and visionary decisions regarding the balance of development that is new or enhanced vs maintenance.
Here is a picture showing how the teams in a team of teams structure including the wholeness level team, are reducing the transdisciplinary complicatedness, by iteratively working towards Integration Events; the transdisciplinary complicatedness is also reduced iteratively.
To get a clearer understanding of the complexity of product development, both pictures of team responsibilities and the picture “The complexity of product development” are put in the same picture; the complexity of product development vs team structures.
Putting people structures, systems design and portfolio together
If we put all above together we end up with this picture, where we now also adding the people structures and the portfolio to the prior picture of the complexity in product development, people structures and the complexity of product development:
If the team level shows that the complexity reduction is successful to the left in the picture, planning starts to be achievable, moving to the right in the picture. When a concept is validated as a possible solution, it will over time be more; predictable, the teams can be more and more autonomous (which does not mean recommendable), longer and longer sprints are possible, we can have detailed & standardized & stable processes, more clearly specify our DoRs and DoDs, etc. But, as always, it depends on context, so we always need to understand the problems and how to solve them, meaning that we can never get used to a predefined recipe.
Note that we have complexity on different levels in the company, which means that each level and its virtual structures, needs to be able to experiment and exploit in order to gain new knowledge. That is why the line hierarchy can be seen in the background in the picture, to show its tree hierarchy in comparison with the interactions all over the organisation, that is needed to make the right product right, in time, to the right cost and quality. As you can see there is a great mismatch in the communication channels in the line organisation compared to the needed ones to solve the complexity and to be innovative in a product development initiative. But, do not forget that the line hierarchy is needed due to all its responsibility and to achieve stability in the organization, but in product development it cannot be responsible for the deliveries, since we need full flexibility when doing novel things, meaning no limits on the interactions needed to find the solution.
Without starting with the wholeness and understand what need to be achieved to be long-term efficient and effective, the risk is that each part is sub-optimising, so we only get partly short-term wins, not gaining the organisation in whole.
We can also see in the picture that it is still valid for all product development; hardware, software or their combination (hybrid), since it still is domain independent within the Complex context of product development. This is a very important aspect, since we understand that we do not need to make too specialized methods for hardware resp. software, and also that it is not difficult to combine them.
If we continue on the economic aspects on initiatives, for example to understand the total cost of an initiative, or to be able to make economical follow-up on an initiative, the following thinking is suitable in order to have a proper solution, and easy as well. When estimating the cost of the initiative, the work needed by the wholeness level and the number of implementing teams, or team of teams on the team of teams’ level, is calculated. In that way we know the resources needed from both the wholeness level (by percentage of the total cost for the wholeness level over time) and the team of teams’ level (we simply count the cost for a team over time), and we understand from the current prioritization on the portfolio level, when we can start the initiative. Since the resources already are in the virtual structure of the wholeness level, the managers do not need to follow-up their resources exactly, the prioritization on the portfolio decides where the resources need to work if there are delays. We will also decrease the pressure on the resources on the wholeness level to fulfil percentage on different initiatives, which is a trap from waterfall with projects, that we need to avoid to not have sub-optimization. Of course, it is still possible to follow-up on individual level, but due to the risk of also other sub-optimization, that is not to recommend, since it will hamper whole teams, broad competences (due competence is outside manager’s area of responsibility) and full-time resources. This hampering will then only lead to many part-time resources in too many initiative, leading to Project Administration waste, which is common in waterfall with projects implementations, i.e., due to KPIs on the managers to have 100% utilization of the employees, see this blog post for a deep-dive.
Another important matter, for example for governments, is to be able to differ new or further development from maintenance, many times called grow and run. For making a difference, the run has percentage numbers agreed with the portfolio. The percentage numbers will of course be a small part for the wholeness level supporting the teams, since the systems design is already set, but of course will increase when we are having a crappy systemization. For the teams the percentage number is higher since they will fix bugs and refactor the whole code, which includes of course also decided changes in the systems design, agreed with the wholeness level. The prioritization done in the portfolio level also gives the direction when deciding which is most important, so that maintenance for a higher prioritized product/initiative is done before new functionality in a lower prioritized product/initiative.
This was the end of the final article in the series about TDSD.