Setting up teams to work collaboratively is one of the challenges that organizations go through when adopting Agile. The functional team setup (all DBAs, all testers, all windows devs together, etc.) is not acceptable for teams that want to quickly develop and deliver products and services to the market. But neither is it possible to have all possible skills (sometimes 10’s of skills) in one team because organizations simply don’t have that many people with certain skills.
In this episode, we talk about the possible team topologies, and how each of those affects our ability to deliver in different organizations.
How we set up teams directly affects the quality of the software teams deliver
We start this episode by discussing a phenomenon that was observed by Mel Conway back in 1969. His observation (later dubbed Conway’s Law), establishes that the way we set up our teams, will directly affect what type of software architecture they are able to implement in the software. The second aspect of Conway’s Law is that, in reverse, architecture also affects which team setups we can implement in practice.
Realizing this double-sided impact will help us be more deliberate about setting up our teams, and therefore affect the quality of the software they produce.
The most obvious example of Conway’s Law is the old debate around Component Teams vs Feature Teams. In this segment, we discuss when each of those team setups might be appropriate for your organization.
When DevOps becomes the bottleneck, the transition pains to DevOps
When DevOps started to expand in adoption, there was a common misconception (which still prevails in some places), that DevOps was a different team, outside software development. Of course, that is a possible setup, however, it has a high impact on the ability for other teams to deliver software to production. In this segment, we mention a blog post by Matthew Skelton, which later originated the book Team Topologies. In that blog post, Matthew Skelton discusses some of the anti-patterns when implementing DevOps and why we must constantly assess and improve the teams’ setup over time.
Is your DevOps team becoming a bottleneck for the rest of the organization? Read Matthew’s blog post to learn more about why that happens, and what setups might a better fit for your organization.
How to learn what works: What team setup works for my organization? 3 principles for designing your teams
The question in everybody’s mind is, of course: “what is the right team set up for my organization?”
Although every organization is different, and many aspects need to be taken into account, there’s a process to analyzing and defining the possible setups that work in any organization. In this segment, we discuss what that process looks like, and what Matthew and Manuel have used in their work.
Further study resources
Matthew and Manuel recommend the following resources for you to dive deeper into the topic:
- The book they wrote: Team Topologies, by Matthew Skelton and Manuel Pais, as well as the companion website, where you can find their newsletter
- A large resource of talks on the topics of DevOps and team topologies can be found at the DevOps Enterprise Summit
- The book From Project to Product by Mik Kersten
- The book Thinking in Systems by Donella Meadows
- The book Guide to Organisation Design: Creating high-performing and adaptable enterprises by Naomi Stanford
- The book Team Genius: The New Science of High-Performing Organizations by Rich Karlgaard, Michael S. Malone
About Matthew Skelton and Manuel Pais
Matthew Skelton is co-author of Team Topologies: organizing business and technology teams for fast flow. He is Head of Consulting at Conflux and specializes in Continuous Delivery, operability, and organization dynamics for modern software systems.
Manuel Pais is an independent IT consultant and trainer, focused on team interactions, delivery practices and accelerating flow. Manuel is co-author of the book “Team Topologies: Organizing Business and Technology Teams for Fast Flow“. He helps organizations rethink their approach to software delivery, operations and support via strategic assessments, practical workshops, and coaching.