The team of teams

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.

The teams in the team of teams-level are mostly operational and will either work with backend components or the frontend (UX) component. This division is of utterly importance and possible for big systems. The reason is because it divides the work of HOW the solution for our system will be, from the WHAT the customer wants in more details regarding the UX and industrial design.

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 with subsystems within backend. 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, design, test and build.

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.

Please see this article for detailed information.