Visualizing team relations
One of the key aspects when organizing your teams for software development is the need to have clearly defined team responsibilities and communication channels between your teams. Team Topologies does a good job in providing a visual encoding of team stereotypes and interaction modes between teams.
The stereotypes describe teams with typical characteristics related to their tasks. Examples of these stereotypes - which we will refer to - are
- stream aligned teams
- platform teams
- enabling teams
Stream aligned teams are optimized for a fast flowing development of a product closely related to a (business) value stream. Platform teams usually provide services to the former allowing the stream aligned teams to focus on their value stream. Enabling teams temporarily join other teams - mostly providing some sorts of expertise - to provide assistance, encourage the other team to adopt their expertise and enable them to own their responsibilities. The interaction modes describe typical communication patterns that arise depending on the team interactions. We will use
- collaboration
- service consumer / provider (X as a service)
- facilitation
Using the visual encoding of these stereotypes and interaction modes allows you and your teams to paint a picture of the current state as well as your desired outcome.
Painting these pictures first and foremost serves as means of communication and building a shared understanding.
Like many tools we employ - whether for product development, software architecture or any organizational effort really - this is not meant as a specification but to externalize knowledge, having discussions and building a shared understanding of our current state, our goal and how we transition from one to the other. This is especially important when changing organizational structures, processes and responsibilities as it will likely affect a larger group of stakeholders and might have big impact on your success as a business.
Planning and executing organizational change
In our following story we deal with a “Delivery Platform Team”, a “Cloud Platform Team” and product teams which correspond to the Team Topologies stereotypes of platform teams and stream aligned teams. The “Delivery Platform Team” currently is responsible for operating the GitLab server, providing a solution to run Renovate for the product teams, as well as a couple of more responsibilities which we will omit from the diagrams for the sake of simplicity. The “Cloud Platform Team” is providing all sorts of cloud infrastructure, including a Kubernetes cluster the product teams run their application workloads on and cloud based VMs on top of which the GitLab CI/CD server is running. Additionally they offer a GitLab based CI/CD Pipeline to the product teams to build containerized applications and deploy them to the Kubernetes cluster.
As more requirements arise on the delivery side - support of different programming languages, code quality analysis, security scans, automated testing and reporting, etc. - we are tasked to shift some of the CI/CD responsibilities to the “Delivery Platform Team” so that the “Cloud Platform Team” can focus on their core responsibilities.
So here is what we did to plan and execute the desired organizational changes leveraging Team Topologies diagrams with some extensions:
We started by firstly drafting a picture of the current state including the platform teams, the stream aligned teams their relations and responsibilities. Unfortunately Team Topologies does not provide means to encode the responsibilities of components so we just opted to draw some grey boxes underneath the teams.
This initial diagram not only helped us build a shared understanding of the current situation but also discover components that we initially did not account for.
We had some discussions on how responsibilities should be distributed in the target picture especially surrounding the operation of the GitLab CI/CD VMs and the Kubernetes deployment parts of the pipeline. We were carefully weighing team autonomy against the required specialized knowledge and privileges to efficiently and safely maintain these components. Considering that operating the VMs themselves would not offer much benefit, and we wanted to integrate automated deployment for on premises workloads, we decided to rely on the hosting and deployment services of the “Cloud Platform Team”. On the CI/CD pipeline side this would require us to split the build and deployment parts of the pipeline and come up with a well defined interface. This would allow us to integrate them again so that to the product teams the pipeline would offer a seamless CI/CD experience.
These considerations and decisions left us with this desired target state.
Notable is that the desired state was not a clear picture from the beginning. During the discussion we collaboratively drafted multiple versions and later discarded the options we did not like.
We now had a pretty good idea of where we were and where we wanted to go. But it was still not clear on how to transition from the current to the desired state. Questions we had to answer were along the lines:
- Is our idea of the target state feasible?
- How do we ensure that required expertise is shared properly?
- When and how should responsibilities be transferred?
Again after some discussions, we decided to split the transition into two phases: A proof of concept (PoC) and a migration phase.
The PoC phase should serve the purpose of validating our assumption that the pipeline could be split in a clean and maintainable manner, into a build and cloud deployment part, whilst still being consumed as a single CI/CD pipeline. During this phase we would form a temporary team that, together with the “Cloud Platform Team”, should design the interface between the pipeline parts and build a prototype. The design process would require close collaboration between these teams in the design phase, until a stable interface was defined. On the other side the temporary PoC team would facilitate the adoption of the new pipeline prototype by a pioneering product team.
When looking at the temporary characteristic and the facilitation interaction mode of the PoC team with the product team, this perfectly fits the enabling team stereotype. Visualizing our idea after some drafting we came up with this picture of the intermediate PoC phase.
Assuming our proof of concept will show the validity of our assumptions, the following tasks would be to:
- Shift the responsibility of the build pipeline component to the “Delivery Platform Team”
- Move the CI/CD service offering to the “Delivery Platform Team”
- Make sure that the integration of the build and deployment pipeline works well on scale
Our resulting diagram clearly shows the shift of the “Build pipeline” component, and along with it, the provision of the “CI/CD as a service” to the “Delivery Platform Team”. It additionally makes transparent, that the project team will continue to enable the product teams during the migration phase, facilitating the adoption of the new pipeline and the need for collaboration between the two platform teams. The latter assures any obstacles not tackled during the proof of concept phase can be solved together, to provide a smooth customer experience.
Examining the diagram further, it might help in identifying additional tasks for the shifted service offering, such as the potential need to establish new communication channels between the “Delivery Platform Team” and the product teams. Also a phase out strategy for the old pipeline service offered by the “Cloud Platform Team” should be planned.
Depending on the length and complexity of such transitions, you might want to break them down in separate diagrams and play with a variation of phases. You should do so until you strike the right balance between concise communication and need for detail.
Creating these diagrams greatly helped us with building a shared understanding in the involved teams, in identifying tasks and communicating our plan to management.
Conclusion
Team Topologies is a good tool in your toolbox, to visually communicate organizational change affecting multiple teams. It creates a easily graspable representation of what your plans are for involved teams and management alike. Make sure to introduce the encoding and meaning up front to lay ground for a common language and understanding of your diagrams. This can quickly be done before presenting them, due to the reasonable size of team types and interaction modes.
I am an advocate of additionally encoding relevant components / responsibilities of your teams in your diagrams, as they will clearly show the boundary and intended purposes of your teams.
If your teams and interaction modes can not be presented by the existing stereotypes you can just improvise. But it might be an indicator that your teams could have a clearer purpose and boundaries and you might want to examine your organizational structure more closely.