Chapter 5 Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais is a powerhouse. This chapter lays out the four fundamental team topologies with examples. I read this chapter twice during my first read of the book and I read it twice this week. We will approach thinking through the re-read over two weeks.
The four fundamental topologies are:
- Stream-aligned teams are aligned to a single “valuable set of work.” The stream-aligned team builds and delivers value independently and without handoff to other teams. These teams are cross-disciplined; they have the capabilities to get the job done.
- Enabling teams are specialists in specific capabilities that coach other teams so they can do their jobs more effectively. The authors point out that an enabling team help stream-aligned teams to be more autonomous. Enablement teams should put themselves out of business by improving other teams.
- Complicated-subsystem team is a group that supports a piece of an application that requires specific specialty knowledge to change that piece of code. These teams are rare and should only be formed when the work can be dealt with inside a standard steam-aligned team.
- Platform teams enable the stream-aligned team by maintaining services and structure the stream-aligned teams build on. The platform teams help to ensure the stream-aligned teams are autonomous.
Now on my second time through Team Topologies, I find being able to recognize the four basic topologies easily in the real world opens up ideas for how to use the material later in the book. I have found a second read and some practice is useful when trying to identify the four basic topologies in the mess most organizations call team design.
Three identification examples:
Several years ago I took a job inside an organization. I was an employee. I was an agile coach in a team of coaches and Scrum Masters. It was a fantastic time. The team worked with teams building and supporting software. We were there to help teams deliver value; we were an enabling team. The fact that we resisted measuring our impact was not among one of our best ideas – more on that next week.
A year before COVID (B4C —?) I worked with a Salesforce Team. The stalwart team of six maintained their own instance of the application, oversaw and permissioned API usage, wrote reports, provided user access, wrote functionality for all of the organization’s internal departments, and responded to problems in the middle of the night. This team was a combination of a stream-aligned team delivering value to their clients and a platform team. In their role as a platform team, they struggled to keep control over the platform. I remember listening to the business product owner deprioritizing needed platform work for critical business-facing work. It was only when the team was split into two different teams both focused on Saleforce-related work but with different missions that the fighting over the backlog ceased.
An independent testing team is the third example. Several functional teams complete (sic) their user stories and throw work over the wall to the testing team. The testing team prioritizes the work and does its thing trying to control quality. Some of the work they receive is good, some isn’t, some work gets returned to the Dev teams, and some … well it just goes into production and a user writes a problem ticket. This approach still exists. Is this an enabling team? No, it does not exist to increase the capabilities of a stream-aligned team. The test team is not coaching the dev team. They aren’t trying to put themselves out of business by making the stream-aligned team more independent. Nor are they a stream-aligned team in their own right. They fail the test of independence. The Dev team throws the work over the wall to them and then they handoff to another team. They are certainly not a platform team or a complicated-subsystem team. We will walk through the approach to solving this problem one organization is currently trying.
These are three examples of using the four topologies to consider the roles teams are playing. Where there is friction many times I find teams trying to fit into multiple topologies at the same time. The outcome is generally a mess and always increases the cognitive load on the team members, which reduces the flow of values.
Next time we will stay in Chapter Five and consider the behavioral characteristic described by the author to see where we can use the information to identify ways to improve flow in real-life teams.
Buy a copy and read along! – Team Topologies: Organizing Business And Technology Teams For Fast Flow
Previous Installments:
Week 1: Front Matter and Logistics – http://bit.ly/3nHGkW4
Week 2: The Problem With Org Charts – https://bit.ly/3zGGyQf
Week 3: Conway’s Law and Why It Matters – https://bit.ly/3muTVQE
Week 4: Team First Thinking – https://bit.ly/3H9xRSC
Week 5: Static Team Topologies – https://bit.ly/40Q6eF2
