Team Collaboration in Corporations: Team Topologies in real life
In one of my previous articles, I wrote about our journey as an app team for streamlined success, strongly referencing Team Topologies.
While the article was mainly reflective on our app team, the application of the recommendations of Team Topologies are not limited to intra-team organization, but also to the inter-team communication and collaboration.
Internally, we set up some guidelines (NOT rules!) to ease the collaboration, by following best practices — with the option to adjust the guidelines to the current context and requirements.
Please read in the following our guidelines — you can find the essence in the Outro chapter.
Summary
Organizing the collaboration of teams is a permanent challenge in terms of process, efficiency, social interaction, social communication, priorities, targets, and artifacts.
On this page you’ll find some recommendations and best practices.
Team Topologies
Team Topologies is the leading approach to organizing business and technology teams for fast flow, providing a practical, step-by‑step, adaptive model for organizational design and team interaction.
The process described here is heavily influenced by the findings and suggestions of this approach.
Key Concepts — Team Topologies: https://podcasts.apple.com/de/podcast/making-tech-better-made-tech/id1558845124?i=1000536828087
Roles & Responsibilities
First of all, it’s important to understand each team’s responsibility in the overall business value creation process.
There are teams directly responsible to create business value (stream-aligned teams), and there are teams supporting the creation of business value by making specific domains, like infrastructure or payment, accessible — to allow business-focussed teams to focus on their product/service.
Temporary collaboration between teams requires a lot of effort: to define common targets, a common process, and priorities. The longer the temporary collaboration continues, the more energy is lost on the collaboration itself, rather than using that same energy to generate business value. Therefore, the contact times between teams should be only as long as absolutely required — and must therefore be highly efficient.
The following diagram gives a hint about different teams responsibilities.
- Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain
- Enabling team: helps a stream-aligned team to overcome obstacles. Also detects missing capabilities.
- Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed.
- Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by stream-aligned teams
Types of Interactions
Depending on the type (topology) of teams and their service/product, different types of interactions are recommended:
- Collaboration: working together for a defined period of time to discover new things (APIs, practices, technologies, etc.)
- X-as-a-Service: one team provides and one team consumes something “as a service”
- Facilitation: one team helps and mentors another team
Domain expert teams
- rule their domain
- make the complexity of domain more abstract, for easy consumption of stream-aligned teams
- make complexity manageable for non-expert teams
Process
Precondition
The precondition to a successful team collaboration is the agreement on the highest priority of the subject for both teams, to avoid unnecessary delays, confusions, and frustrations.
Rather than starting a process with teams that have different priorities on the same subject, delay the whole process until priorities match.
Phase 1 — Requirements and Specification
Initially, the involved teams nominate the required responsible individual persons (e.g. product, developer, domain experts, etc.) being part of the collaboration. Ideally, the people selected from the different teams should be focussing on the collaboration only and therefore form a temporary new team throughout Phase 1 of the process. Keep this group as small as possible.
The targets of Phase 1 can be defined in following steps (see also RFC process):
Kickoff → Draft → Feedback → Publish → Technical Specification
Kickoff
- Stream-aligned members present their requirements and deadlines
- Domain expert team assist with their knowledge and inform about possibilities and limitations
Draft
- Based on the Kickoff, the domain expert teams come up with a specification draft, according to the RFC (“Request for Comments”) process (possible tools: Wiki, MermaidJS, etc.)
Feedback
- This RFC is reviewed and commented by the stream-aligned team members
Publish
- On agreement, the RFC is published and fixed for implementation by the domain expert team
Technical Specification
- Based on the RFC published, the domain expert team provides technical specifications (e.g. Swagger), to agree on the technical details with the stream-aligned team
Phase 2 — Transition
After Phase 1, the most intense form of collaboration has been settled, and the temporary team can dissolve back into their original teams.
Phase 2 serves as transition, to enable the teams to do their individual work on the process as independently as possible.
The pronounced responsible individual persons from Phase 1 remain the main contact points throughout the process.
- Domain expert teams provide Mock Implementations, to enable stream-aligned teams to finish their implementation completely independent on the progress of the follow up real implementation
- Based on the technical specification, stream-aligned teams prepare their implementations as far as possible
Phase 3 — Individual Implementation
Continuing their independent work, the teams finish up their work.
Adjustments/bugs are being discussed with the individual persons, defined in Phase 1.
- Domain expert teams finish their implementation
- Stream-aligned teams finish their integration
The limiting factor for the release is the implementation/work of the domain experts, and should have absolute priority.
Outro
- Agree on common highest priority
- Define clear responsibilities for process and artifacts
- Define individual, fixed ambassadors of each team, to have fixed contact persons, and keep the overall number of contact persons as small as possible
- Form a temporary inter-team project party, with no other responsibilities, and free the members of their default daily work
- Keep process and direct team interactions as short as possible
Conclusion
Since we struggled in the past, especially with the initial storming phase for required team collaboration, the described guideline helped a lot making this process more fluid.
In general, most of the team leads like the approach described. We will see how this guideline evolves in future, because…
Only change is constant!
Happy Hacking!
