The concept of Team Topologies, as depicted in the book written by Matthew Skelton and Manuel Pais, is getting worldwide attention. The focus on team structure and purpose is opening interesting discussions and many organizations are adopting the model as a reference for their development teams organization. The pros and cons of the different approaches.
One team per BC
The perfect choice seems to be one team per bounded context. One team, one bounded contexts. Seems the way to go on paper.
- Some details are left out of the picture, like organization size, which will be growing as the BCs continue to evolve.
Three interaction modes
Collaboration: two teams working closely toward a common goal
- X as a service: contact in terms of usage, but little specific collaboration
- Facilitation: one team helping another team get rid of impediments
- These patterns are attractors: failing to define the type of engagement will leave space for frictions and delays
What’s left out
Organization size
- Team topologies are more interesting when you have more than 20 people on a team
- Business pressure and portfolio management
- If teams are not working well together, collaboration will not happen
- Too many organizations are unable to plan for multiple dependent teams
Fracture planes
Ideal places for cutting the system into loosely coupled bounded contexts and to effectively split responsibilities between teams
- When it comes to breaking the monolith, it’s never about cutting slate – it’s more like chopping wood where there are branches and nodes
- There are ways to deal with this problem, but they require a given degree of mastery
Context Mapping Patterns
Strategic Domain-Driven Design offers an interesting point of view on the same problem space, but with different constructs
- Focused on Bounded Contexts under the assumption that in a mid-sized software organization there will be a close mapping between the two concepts
- Little explicit reference to teams
One team, multiple Bounded Contexts
The only way to achieve good separation is to explicitly enforce it: from big visible maps, to segregation of the codebase.
- While one team many models can happen, you’ve got to be very good in making the boundaries explicit.
The problem space is largely uncharted territory
Teams growing in size will have to be split and competences will become more narrowed and specialized
- However, the criteria for the splitting have been debated endlessly
- The outcome is never perfect
- Every organization places the responsibility of sizing and structuring teams in different hands
- Is this a team leader responsibility, or head of development?
- Do we need a specific role for that?
A journey, not a destination
The most important outcome of the discussion around Team Topologies nowadays is about what a good desirable state looks like
- Please don’t fall into the trap of considering such desirable state as stable or to solve the problem of team structure once and forever
Team Topologies categorizations
Stream Aligned: Team focused on a specific business capability, ideally cross-functional
- Platform Team providing common services to other teams
- Complicated Subsystem: Team with high specialization, and specific knowledge about one portion of the system
- Enabling: Team a team of experts, mentoring and helping other team to evolve and improve
Collaboration Patterns
Partnership: two teams are mutually dependent and collaborating towards a common goal
- Customer-Supplier: the goal is still common but the dependency is less symmetrical, and priorities may differ
- Conformist: no negotiations here. One model is adopted with minimal changes on the other side
- Anti-Corruption Layer: still on the downstream side, but they are not adopting the external model
- Open-Host: on the upstream side, our model can be made available to external users, at our conditions
- Published Language: a common language on the communication channel could make a larger conversation possible
- Shared Kernel: a small portion of the software could be in common between different model, but this implies superior attention and quality in touching this code
Satellite concepts
Since the early days, I enjoyed the ability of Context Mapping Patterns to capture the cost of the different approaches on different currencies.
- A Partnership requires less code but a lot of conversational bandwidth to be possible, while an Anti-Corruption Layer goes exactly the opposite direction, writing more code since no conversation is possible.
More teams, one BC
Can we have two teams working on the same model?
- No.
- Teams have usually different backlogs and priority, and ambiguity will quickly rot in the codebase accelerating the transition towards a Big Ball of Mud
- In general you won’t have BCs so big to justify multiple teams worked on them
Are Bounded Contexts Teams?
No, bounded contexts are defined like the limit of applicability of a given model.
Present or Future State
Team Topologies provides a reference towards a desirable to-be state while DDD context mapping provides more fine-grained patterns for assessing the current state.
- DDD use context mapping for future state but mostly as a software design tool, not so much as an organization design tool.
Choices have consequences
Collaborations are costly and these costs need to be properly accounted for
- The Team Topologies lightweight dogmatism of there are only 3 types of interaction is a good way to force management to make choices and own consequences.
- Just telling people to collaborate and communicate is not a strategy
Have you been spotified?
Most nontrivial software development organizations experience some kind of friction in this space.
- Collaboration between software teams is one of the key fundamental traits of successful companies, but frictionless collaboration seems to be a chimera so it’s not a surprise if IT professionals are seeking for guidance.
