Software Delivery in Small Batches

[00:00:00] Hello and welcome. I'm your host, Adam Hawkins. This episode is a small batch of software delivery education. If you enjoyed this episode and share it with your friends and colleagues,

[00:00:17] Hey there, Adam here for a solo episode of small batches, just got myself, a nice ice cold glass of Colum onstage. So I'm ready to get into today's episode today, I'm covering the 2019 book team topologies, organizing business and technology teams for fast flow written by Matthew Skelton and Manuel Peisch.

[00:00:40] Let me read off their official bio Matthew and Manuel coauthors of the book team topologies have worked together on organization design for modern software systems with many clients around the. They're training sessions on organization design from modern software systems. I've helped numerous organizations to rethink their approach to team inner communication and software architecture, improving flow and the effectiveness of software delivery.

[00:01:05] So I'm stoked to finally discuss team typologies on small batches. This book has come up so many times in my work as an SRE at Skillshare, and it's tangentially related to pretty much everything I've discussed on small batches. This is because team architecture and software architecture are directly related to software delivery performance.

[00:01:27] And that's particularly why I enjoyed team typology so much because it's truly a book about a high velocity software delivery. In fact, it's right there smack in the title. Plus it provides us a language to discuss this facet of software delivery. My guess is that you've likely encountered some of these concepts before.

[00:01:45] So this time around it may just be a new land. I'll share a personal anecdote from an earlier time in my career to set the stage for today's episode. Roughly five years ago, I led the platform team through a complete ground-up rewrite at a previous company. We were divided up into technology teams.

[00:02:01] There was the web team, the mobile and the platform team, given these boundaries, each of their respective team bleeds set out to create their internal architecture, nothing to see here, just Conway's law and action. While the platform team created API APIs for the web and mobile teams. It worked well here because we had isomorphic technology and team architecture.

[00:02:20] Then something happened out of the blue shortly after the rewrite completed, the organization went through a total reorg that changed the team structure, their responsibilities, and how they interacted without doing anything to address the underlying technical architecture. This created confusing boundaries, ownership, responsibilities, and let the so-called independent feature teams at the mercy of the small number of capable back and engineers working across the various internal servers.

[00:02:46] These problems could have been avoided with some foresight and planning. Plus it's just especially bothersome to me because the entire engineering team had just finished a ground-up rewrite that architected a system to support an entirely different team typology. If there was ever a time for a reverse combo maneuver that this was not.

[00:03:06] This example speaks to the importance of Conway's law and how team and software architecture fit together to create fast flow or on the other hand, just inhibited team typologies provides a framework that avoids this problem from the outset by optimizing for fast flow

[00:03:24] team, typologies addresses the relationship between software delivery and team structure. The book's thesis is that the teams are the means of software delivery. So organizations must structure teams for fast flow. The term typologies refers to both the structure and dynamics in an organization. Imagine for a moment, a running river structure is like the rocks or the logs and plants along the river's path.

[00:03:48] Dynamics is how the water flows and moves between the rocks, logs and plants. The water may take a different path as conditions change. That's the dynamics at play as water navigates, the rep restructure organizations must consider both the structure and dynamics when constructing their team topologies.

[00:04:06] All of this is inseparable from Conway's law. Conway's law has searched that organizations are constrained to produce application designs, which are copies of their communication structures. This often leads to unintended friction points when organizational structure, but up against technological architecture, the quote in inverse con women.

[00:04:27] Seeks to avoid this problem by evolving team architecture and organizational structure, to promote the desired architecture team typologies, to find his team as a stable group of five to nine people working towards a shared goal as a unit teams may be responsible for different parts of the software system.

[00:04:45] However different parts of the software system are owned by exactly one team. This means there should be no shared ownership of components, libraries, or. Teams may use shared services at runtime, but every warning service application or a subsystem is owned by only one team. The corollary is that ownership increases cognitive load.

[00:05:06] Cognitive load is all the stuff that teams must keep in their head to effectively build, deploy, and operate their services. Cognitive load must be throttled to keep teams running effectively. Team topologies recommends limiting teams two or three domains, but never to a complex don't. That's T O too. The key is balancing the cognitive load against the team's ability to respond, to work in a timely fashion.

[00:05:33] These quote domains relate to the team's position in the value stream. Some people are better suited to making user-facing software. Some people are great at building infrastructure. Some people love doing sales, others, write documentation or handle frontline customer service. This position in the value stream impacts how they interact with other teams.

[00:05:55] This is where we get to the meat of team topologies team typologies provides four fundamental team types, one stream aligned to platform three, enabling for complicated subsystem. There's also three interactions. Collaboration X as a service and facilitating let's begin with the team types, then cover the interaction modes.

[00:06:21] First up is a stream aligned team. A quote stream is the continuous flow of work aligned with the business domain or organizational capability. Continuous flow requires clear purpose and responsibility so that multiple teams can co-exist. Each with their own flow of work, a stream aligned team is a team aligned to a single valuable stream of work.

[00:06:43] This might be a single product or service, a single set of features, a single user journey or a single user persona, but it's not limited to those. Those are just examples. These teams are nimble. They can quickly change course and integrate feedback into their daily work. More importantly, only they are on the critical path to completing their work.

[00:07:06] This means zero or minimal hand-off to other teams. These are the organization's primary teams, but they cannot exist in a vacuum streamlined teams have end to end responsibility for completing the work. AKA you build it, you run it, requiring the team to manage every technical aspect of that process would create undue cognitive load, thus impairing the team.

[00:07:29] This is where the other types of teams come into the. Their core purpose is supporting this dream aligned teams. Now onto the enabling team, the enabling teams typically work closely with stream aligned teams. Their job is to increase the autonomy of stream aligned teams by growing their capabilities, the focus on their problems first and not the solutions you can think of them as technical consulting team.

[00:07:54] They're members tend to have specialist knowledge in their particular domain. These teams tend to focus on a specific area like release engineering or painless livery or testing. They're likely able to create skeleton solutions that apply best practices for other teams to build on. However, they're not, the owners are permanent dependencies.

[00:08:13] If the enabling teams doing its job well, then the interaction will be short-lived after bootstrapping the capability, they may move on to work with another team. Next complicated substance. The complicated sub-system teams help shed cognitive load from the stream aligned teams they're created when the domain is complex enough to warrant specialist knowledge to make any change to the subsystem, think of something like an operating system or container orchestration system or a facial recognition algorithm.

[00:08:43] These are sufficiently complex. That deep understanding is required to be productive and working in the substance. Also note that clear boundaries between the complicated subsystem and their consumers are prerequisite. The important bit about this team is that these teams are created to offload cognitive load from streamlined teams, not by a desire to share a subsystem.

[00:09:05] For this reason, there should be a small number of complicated sub system teams and zero in some cases last and not least. And the teams, I typically find myself in as a platform. The platform team provides autonomy to stream aligned teams. Platform is defined as a foundation of self-service API APIs, tools, services, knowledge, and support, which are arranged as a compelling internal process.

[00:09:32] Autonomous delivery teams can make use of the platform to deliver product features at a higher pace. And with reduced coordination, the platform team assumes the cognitive load that would have been placed on the streamline team. If they were asked to build everything themselves platform teams, or how they collaborative by their names.

[00:09:52] They tend to work closely with their users, AKA the stream aligned teams to build tools that solve their problems. No. What that in a large enough organization, the platform team may actually be a team of teams. Imagine AWS, that's a single platform composed of streamlined teams for individual services, as well as their enabling teams, complicated sub-system teams and internal platform teams that completes the 14 types now onto interaction model.

[00:10:20] Team topologies to find three interaction modes, collaboration mode, two teams work together on a shared goal. Particularly during discovery of new technology or approaches. The overhead is valuable due to the rapid pace of learning X as a service mode, one team consumed something provided by another team, such as an API, a tool or a full software product here.

[00:10:43] Collaboration is minimal. Lastly, facilitating. One team, usually an enabling team facilitates another team and learning or adopting a new approach. Different team types, prefer certain interaction models, stream aligned teams. Use X as a service or collaboration. Enabling teams use facilitation, complicated sub-system teams.

[00:11:06] Use X as a service and platform teams use X as a service for teams that consume their platform. Now that's probably a mouthful. So I recommend you check out the show notes for links to infographics and presentations on these models. This information is better digested with some visual aids. The book includes examples of many common scenarios and anti-patterns in team structure and interaction modes.

[00:11:32] So my brief summary will have to do with. Organization should adopt a team's first model and then design teams, accounting for cognitive load and boundaries. This may be done using what the authors call fracture planes. The first fracture plane is the business bounded domain context. This is similar to what you'll find in domain driven design.

[00:11:54] The next plane is regulatory compliance. This is a natural boundary because regulatory compliance tends to form firewalls and organization. This often requires specialized knowledge that would only add cognitive load on other teams. Third is change cadence, certain areas of the organization move faster or slower than others.

[00:12:15] This allows teams to adopt cadences that best suit their work. Say a maintenance stream aligned team compared to a high velocity product stream aligned team. Next comes location or geography. Some things work better. Co-located it. In an office. Some things can be done. District. That and each person also has their own preferences.

[00:12:34] One example is a globally distributed follow the sun SRE team where members can be on call during normal working hours. The fifth plane is risk differentiating. Risk profiles allows mapping that technology changes to business, appetite or regulatory needs. It also allows each subsystem to evolve its own risk profile over time and adopting practices like continuous delivery.

[00:12:58] That allow increasing speed of change without incurring more risk. Next is performance isolation. This is similar to risk, different subsystems have different performance requirements. A real-time video streaming system is different than an SMS delivery. API. Each requires a different set of skills and different SLS.

[00:13:18] The seventh plane is technology. This is the classic separation. Like the one I mentioned in my earlier. And likely may be avoided by using the other fracture planes. This plane tends to focus on the how, rather than the why. However, this is useful when dealing with older technologies that don't play by the same rules as others.

[00:13:39] I'm looking at you COBOL. The final plane is user personas. A good example is enterprise customers of a SAS. Those users have different needs and pay different. Splitting a team around supporting them provides clear. Of how those users succeed with the product. Also odds are your marketing team already has a few personas drafted up.

[00:14:02] If you need a place to start. Now, all of these are factors in determining your team architecture. I'll leave you with the key quote to remember, and your decision making process overall, the team DePaul, just approach advocates for organization design that optimizes for a flow of change and feedback from running system.

[00:14:22] This requires restricting cognitive load on teams and explicitly designing the intercommunication between them to help produce the software systems and architecture that we need. So that's team topologies and a nutshell, just remember that all the things discussed here are not intended to be static or that organizations evolve over time.

[00:14:42] And the team topology put in place at one moment in time may not make sense a month or six months or a year or a few years down the line. The point of these typologies is that they allow you to create an organization that evolves and changes to fit the needs of the current moment. This book changed the way I think about the relationship between team architecture and software architecture and the overall impact on software delivery performance.

[00:15:10] It's now permeated in my subconscious in a way that I cannot un-see it. That's why I wanted to share it with you. And perhaps it will have the same effect on. That completes this batch visit small batch.fm to subscribe to the show for free. Would you like a topic covered on the show then call plus +1 833-933-1912.

[00:15:31] And leave your request in a voicemail. Hope to have you back again for the next episode. So until then happy shipping one to learn more about dev ops without wasting your time and send them from my free email course@freedevopscourse.com. My course combined is the best from the dev ops handbook, accelerate and years of software delivery experience.

[00:15:50] You'll learn the three ways of dev ops and the four KPIs of software delivery performance. More importantly, I'll show you how to put that theory into practice. That means shipping better software faster. Sign up today at freedevopscourse.com.