The ever-increasing pressure to deliver more features sometimes derails the value streams from focusing on their core differentiated offering. They might get pulled into tasks that are temporary but require a deep skillset, or experience, which they don’t necessarily have the time to learn.
This pattern frequently surfaces in organizations that, for example, are migrating their applications from one technology stack such as OpenShift (RedHat’s Kubernetes offering) to EKS in AWS. Not all value streams might be aware of the peculiarities of such a migration and the dependencies in their application stack that they should consider evaluating. To spearhead the progress of such migrations, it often helps to set up enablement teams, a temporary structure that is formed of individuals who have been involved in similar migrations, for many other workloads in the company. The experience they have had in the past can be a big value add for the teams who want to do something similar.
Figure 10.1 highlights the flow of change in software and the respective interactions within different teams – all with a common goal – providing value to their customers:
Figure 10.1 – Collaboration between different team structures (Source: https://github.com/TeamTopologies)
You might have somewhat similar or largely different team structures within your organization. If you are just establishing your teams from scratch, you could consider these structures as a guiding force. If you already have an established working model, you might want to align that with the principles that these teams live by. Doing this will allow the right balance of autonomy, growth, and ownership. Defining the boundaries of responsibilities is essential for effective communication within and across the teams.
Establishing a culture of collaboration and learning
Breaking down the teams into smaller focused groups has its advantages, such as complete autonomy, team cohesion, end-to-end responsibility, and clear alignment with customer expectations. Sometimes, this can also mean that there are pockets of innovation happening within these teams that might be valuable, but unknown to other parts of the organization. Or, there could be recurring patterns of problems that each of the value streams faces, which might hint at underlying gaps in the offerings from the platform team. This is where establishingCommunities of Practice (CoP) plays a very important role.
A CoP is a group of people within the organization that share a concern or passion for something. They meet regularly to collaborate and learn from each other. These communities might have multiple dimensions of purpose; sometimes, helping other communities with everyday work needs, sharing best practices and guidelines for the organization, or fostering breakthrough innovations and new practices. As shown in Figure 10.2, a CoP is an overlapping structure that spawns multiple teams in the company and gets everyone with similar interests together in a room:
Figure 10.2 – Establishing a CoP for shared interests and passions
Organizations typically plan these collaborative working sessions at least once a week, when undergoing major transformations. In later stages, they might want to revisit the cadence by further reducing or increasing it, depending on the value that the teams are driving from the setup.