Team Topologies in Action: Early Results from Industry

Since the book Team Topologies was published in 2019, organizations around the world have started to adopt Team Topologies principles and practices like Stream-aligned teams, modern platforms, well-defined team interactions, and team cognitive load as a key driver for fast software delivery and operations.

We will look at examples from the following organizations:


Gjensidige Insurance, a leading Nordic insurance company with 4000 employees and business in the Nordic and Baltic countries, uses the four fundamental team types to clarify team responsibilities and interactions and is moving towards several “thinnest viable platforms” with Stream-aligned teams as internal customers

PureGym is Britain’s largest gym chain - the first to gain over 1 million members. As PureGym expanded, so did the need for software to enable their members to book and manage gym sessions. Since 2019, PureGym has re-aligned its teams and team interactions based on Team Topologies patterns, helping to scale the engineering teams and improve flow.


uSwitch / RVU, one of the UK’s leading consumer price comparison websites, has grown a modern platform from scratch, allowing stream-aligned teams to focus on consumers needs, offloading infrastructure provisioning concerns to the platform which also provides cross-cutting services around scalability, security and data management


Visma is one of the leading software development companies in Europe with nearly 1 million customers in 21 countries. Team Topologies has helped to define and accelerate a transformation begun in 2015 to improve service ownership and speed of changes.


Wealth Wizards is a UK company making financial advice affordable and accessible to everyone through online tools and apps. The engineering division at Wealth Wizards has used the Team Topologies ideas around team cognitive load to help right-size their teams and align teams to the most important flows of business change.


For each of these examples, we explore how the ideas and patterns in Team Topologies were useful to the organization and the results of the changes.

MP

Manuel Pais

Author, Team Topologies

MS

Matthew Skelton

Author, Team Topologies

Transcript

00:00:08

Hi, thank you everyone for attending this. Talk on Tim typologies in action, early results from the industry here at the DevOps enterprise summit, London virtual edition.

00:00:20

Hi, I'm Matthew Skelton. I'm one of the co-authors of the book team topologies, and I'm the founder of conflicts

00:00:27

And I'm an . I'm an independent consultant and trainer. I'm also co-author of the book, Tim topologies. So the book came out in September, 2019 by T revolution press. You can find it on Tim typologies.com/book. Some of the praise we've received around the book talks about a kind of new digital operating model. And we think the book helps address some problems that we hear about often. So some of the questions we hear are why is our transformation not achieving the kind of fast flow that we were expecting Or other questions that come up frequently is, you know, what's our purpose as a team and what's our mission within the wider organization. How do we interact with other teams? If we don't have clarity around how, what we're supposed to achieve ourselves as a team? Another common question is why are our teams not able to respond quickly to business needs? And here we're talking not just about new features, but also respond quickly to problems and respond quickly to changing customer needs. How can we safely remove flow level complexity from customer facing teams in order to make more space and effort available, to focus on the actual business problems and solutions.

00:01:57

So today in Tim typologies in action, we're going to look at some examples. So the book has been around for about nine months, um, since publication and we have five case studies that we want to share with you. As a reminder, there are four team types. So we talk about in team topologies, streamlined teams, enabling teams, complicated subsystem teams and platform teams. And there are also three core interaction patterns, collaboration X as a service and facilitating. You will find the shapes represented in the diagrams of the different case studies that we are going to see. So this is an example, diagram, a snapshot in time, uh, crucially, you should look at this as, you know, a flow of change being represented from left to, right.

00:02:53

So the first case study is from Jen Citigo. This is, uh, an insurance provider founded in 1847, a headquarter in Norway. I mean a strong presence in Norway and the Baltics. They've got 4,000 employees and they'd been on a cloud and DevOps transformation from 2015 to the present day back in 2015, uh, the software delivery, there was quite project based, quite waterfall, so quite slow and not particularly responsive, so they knew they needed to change. So they'd been on a journey since then. And, um, a key aspect of, of that transformation was, uh, streamlined teams teams with, uh, multi-disciplinary skills, um, that, that focused on a particular, uh, business product or service. And they have responsibility for the full kind of end to end lifecycle of that product or service. We've got KPIs on business outcomes and development speed, uh, quality of operation operability and KPIs on security so that everything to do with that product or service and the seams are supported by enabling teams in architecture and information security. And there's a complicated subsystem team, which is around the core mainframe system, obviously quite a lot older, so especially skills and so on. And then platform teams, multiple platforms, in fact, um, CRM, infrastructure, application, and analytics, and also design platform. The results of this way of working has seen over the last five years, a 40% growth in digital sales for Jensen to get, they seen a doubling of the, um, amount of customer services handled on digital channels and, uh, claims handling as is now 80% online with 40% automatically resolved.

00:04:46

So it was a great results for Jensen to go with. Really we'd like to thank Christian ma the chief digital officer for sharing that with us today. The second case study is from pure gym. Pure gym is the UK is largest gym operator. There's more with more than 1 million members and 230 gyms throughout the UK. They're launched in 2009 and currently expanding into other countries in Europe. They've actually recently provided details of how they're going to keep, uh, uh, their gym safe for people in a kind of pandemic COVID-19, uh, context with separation that you can see in the photograph here of, uh, that they've least recently.

00:05:28

Um, so since 2015, there's been a huge growth in numbers of we've seen with more than a million members now, uh, particularly people joining using a mobile app, but also payments and bookings and so on as well. The diagrams in this, in this case study come directly from pure gym. So this is exactly how they see it. So back in 2015 is kind of less than 10 people, pretty straightforward way of building software and so on. Um, by 2017, the team, a group of 15 people, and it was kind of quite a lot more work. Um, at that time it was still a case of defining some projects and then passing that work to a business as usual BAU team to run it and to, to kind of find bugs and things. Um,

00:06:16

And then by 2019 and the team have grown to 40 people and they're starting to see problems, uh, with, particularly with handling over these, these projects into the BAU and run teams. Um, it was difficult to, to resolve issues in, in, in the live environments. Inter-team team communication became a problem. There's too much specialist's knowledge in different areas and so on. So there's a real awareness of a need to change. And the software was arranged as a monolith. It's made it difficult. Two teams were working on different services or different parts of the code base, but it was still inside a single code repository. So there's quite a lot of kind of crossover if you like, and, and, um, difficulty separating different concerns for different teams. So later in 2019, there was an attempt to break up this monolithic code base into different areas. So it took a roundabout, uh, three months to do this design work out, which areas of the website, um, were kind of distinct from the point of view of, uh, people using those features. And from the point of view of what the business needed

00:07:25

Early 2020 then. So the team topologies book has been published in, in September, 2019. So then, uh, the, the teams at pure gym looked at interbodies book and found really useful patterns, terminology, phrasing, and so on to help them work out what kind of behaviors or responsibilities different teams should have. So for example, they realized that that what they call that membership management gateway and mg actually really was a platform. And it should behave as a platform because it served many, many other teams and so on and help to accelerate delivery. They realized that that developer experience team and the site reliability team actually should be enabling teams. So that's shown in purple on the diagram here, and they had many other teams at where the best suit were best suited to the stream aligned type of team. So have you made these decisions? We've, we've kind of redefined the responsibility boundaries for the teams. What happens next? How do we actually make this work? Um, so then there was a very high collaboration phase, um, across multiple different teams. So you can see here that the developer experience team and the site reliability team and the platform and mobile teams collaborating very, very closely with the, with the streamline teams to try and work out where the boundaries should be, what kind of, um, responsibility boundaries needed to be in place. Um, after that,

00:08:50

It was possible then to start thinking about the kind of services that should be provided by the platform. Um, so you can see here that the teams are starting to have an X as a service relationship, uh, particularly with the platform, but we've still got the, the two, uh, the two enabling teams, developer experience and site reliability, facilitating the understanding of multiple, multiple stream aligned teams inside the organization to help them kind of get up to speed with new ways of working and new technologies and new practices and so on. Uh, and then this is the, this is a snapshot of how things look today. Um, it doesn't always look exactly like this, but the, the, the point of this diagram is to, is to emphasize it, there's some collaboration happening in certain areas. There's some facilitation happening in other areas, depending on what exactly is happening, um, at the moment.

00:09:40

But the idea is that we've got multiple different kinds of interactions between different teams. And these are clearly, and very, very specifically defined. We understand what we're trying to achieve by a particular kind of team interaction was actually kind of interesting at the top of the diagram that you can see is that their mobile team, it doesn't quite fit into, uh, into these team types. We're still getting a feel for how the, the, the, the, the user experience and the kind of product features that the mobile app provides should be managed. So that's an ongoing conversation that we're having, and that's a good thing because they're, they're using the team to properties, interaction patterns, and sensing mechanisms to try and work out how that team should, should behave. So, John Kell, Mr. Who is a principal, a principal software architect, a PO Jim says Tina topology has helped us appeal to him to evaluate the relationship between our teams and the business strategy to increase team efficiency and evolve away from a monolith.

00:10:34

So the results of this, uh, that the, the technology teams are more business responsive. We've gone from projects and BAU to the streamline teams principally, um, and that means that separate services can evolve at different rates. So particularly the joining, uh, service, uh, needs to needs to have many more deployments than other services. That's enabled the technology to be more business responsive and more bouncing. The ownership of services team morale is higher and improve the team morale. And the architecture is, is much better in terms of the longterm evolvability of the platform. So let's say thank you to John kill, Mr. And rich Allen who have been both very, uh, key to this transformation, uh, and her shared their experience and learning, uh, for this, um, this case study today,

00:11:25

Next case study is from your switch.

00:11:29

Your switch is actually the leading comparison and switching service in the UK. So helping customers switch between different providers of gas, electricity, broadband, and so on. They've had quite an interesting journey, uh, in the last 20 years. So in particular, there are two points. Uh, the interesting to look at around 2010, they start introducing the idea of autonomous. So moving away from kind of generic engineering teams and organizing, uh, with teams that had more freedom and were aligned to some stream of work. And then in 2017, another kind of important change around team organization had to do with introduction of a platform. So we're going to see why those, um, came up, uh, and how that happened. So for context, back in 2015, they had kind of tabelized if, if you like around having this autonomous tumor line teams on things like energy, um, broadband, so different services that they provide to the end customers.

00:12:34

So this were teams with autonomy to decide, um, essentially almost everything that they needed for their software delivery, uh, and operations of their service. And this means that they were dealing with a lot of infrastructure parts. So the only kind of constraint was that everyone was using AWS. Um, but each team had the autonomy to decide how they want to set up their accounts, which services from AWS they want to use. And so on. So the interesting thing about this graph is that it's showing for a period of two years, um, the number of direct calls to AWS API APIs from the different services, uh, at your switch. And during this two year period, what they noticed was that at least half of the teams had doubled the effort that they were spending on a regular basis around infrastructure management, um, and those kinds of services and managing the usage of AWS services as Paul Ingles, um, who is now CTO at you switch said at the time people were spending more time having to interact with relatively low low-level services, thus spending their time on relatively low value decisions, as opposed to spending more time focusing on the business problems and solutions.

00:14:01

So this is when they decided to introduce a platform, um, and essentially change the way that the teams were organized in order to benefit from, uh, the platform services. But they did this in a very product oriented way, thinking about the platform as a product, and therefore thinking about how to engage with their internal customers, this team aligned teams. And one thing they did is identify kind of their first customers, which were the streamlined teams that were, um, having more pains around managing infrastructure. And some teams were lagging behind a little bit on practices like centralized logging metrics, auto scaling, et cetera. And so very quickly they, this new platform was adopted by those teams, uh, one team in particular that benefited greatly and collaborated very closely with the platform as they wanted to grow the platform in a kind of non mandatory way by having the stimulation teams adopt the platform because they saw the value. Then they were looking at the metrics that help them understand how effectively they were able to develop the right product if you like in terms of platform. So they were looking at how many teams were adopting platform, how many of their applications were using platform services. And they were even looking at kind of the traffic that was going directly to AWS versus traffic that was going through the platform. And they also started clarifying from a platform point of view, what are the, um, service levels that their services were providing?

00:15:54

So when we look at the graph kind of the same graph as before, but now for a four year period, you can see that on the right side, the number of direct calls to AWS CPI started going down. And this was a good thing. This meant that those calls were now going through the platform. And what is pretty, I find pretty interesting about this graph. It is kind of a proxy for the team cognitive load on those teams around having to deal with this, um, infrastructure issues and, uh, the effort that was being spent there. So you can roughly see that after two years of introducing the platform more or less than two cognitive level, um, around infrastructure had gone back to the levels around early 2015, but there were still some teams that were not adopting platform. And for good reason, in particular one team, which had kind of the highest maturity around engineering, and they were bringing in a substantial part of the revenue for the organization, they were a bit reticent to adopt a platform because they knew their success with our customers, uh, dependent on, or was strong, connected to the performance and reliability of the service that they were providing.

00:17:15

So if now they will depend on the platform, they were not sure if they would meet those same requirements around performance, scalability, reliability. So the platform team actually had to start measuring and demonstrating their own reliability, performance, scalability, uh, numbers. And they did that by identifying their, uh, SLS service level objectives, and actually creating dashboards that were visible to all the other teams and even a service itself in the platform that provided these dashboards to anyone that wanted to, uh, create their own SLS and manage that. So once they proved that the platform was reliable and that it could be, uh, used to provide the same levels of, uh, expectation as the downstream teams had, then, uh, those last teams also adopted the platform

00:18:17

Kind of interesting thing. Would you switch to, they're kind of still relatively small size that we can have this kind of broad view of their teams and interactions going on. Um, but again, it's more important to look at the snapshot in time and understand what's happening in this moment. What are we trying to do and how should we evolve? So this is, this diagram is actually showing the current situation, um, more or less where the cloud infrastructure team is actually working on a cannery deployment service. And they're collaborating with some of the streamlined teams to actually understand how that service should look like. And it, meanwhile, they have other services that are being consumed, um, on a regular basis by all the teams you can see on the left, there's also necessary team, uh, working as an enabling team. And because this team is quite small, actually only two people, they will, uh, at most be facilitating a couple of stimulant teams to understand the performance reliability of their services. Interestingly, this sorcery team works as a kind of sensing mechanism and identifying problems that are common to several teams and which might be good candidates for the platform to provide a service around this and solve the problem for multiple teams.

00:19:39

Another kind of snapshot on another part of the organization, they actually have different types of platforms have an affiliate marketing platform, which is not exactly or not specific to it, uh, traditional services. Um, and this took a while for them to actually identify what are the good boundaries around this marketing platform and, you know, what should be provided by the platform versus what should the responsibility of and teams. But once they figure that out, this has proven to be, uh, proven to be very effective. So Paul angle says that the engineering principles that guided the way they organize teams were loosely coupled and highly cohesive teams, and we tend apologies. Uh, the great thing is to tie a lot of these ideas together, and most importantly, giving it some common language,

00:20:35

Some of the results that you switch achieved include this kind of curated platform experience from understanding what the different teams actually need from the platform. Also complexity, especially around infrastructure, uh, for teams, so that they can free up more time to focus on the business. Uh, you'd also addressed cross team needs that perhaps no individual team would put in the effort to, to find an elegant solution, but the platform team is going to have the, that capability and solve the same problem for many teams. They moved away a little bit from the idea of fully autonomous teams, understanding that actually having a dependency on the platform services is okay, as long as the team is still self-sufficient, they can self-serve and not be dependent, um, and not be blocked in their flow of work. The patterns that they start applying within it, they actually found to be useful beyond it, like in the marketing platform example. And along along all this time, they've been trying and successfully balancing the achieving fast, slow, but with sustainable, um, reliability and operations. So to learn more about this case study, go to Tim topologies.com/examples. We want to thank Paul Ingles and Tom booth for providing the information in this case study.

00:22:07

The next study case study is from, uh, FISMA. FISMA is a software solutions provider based in Norway. Uh, they provide software in the accounting and ERP HR spaces for companies. Uh, they've got like 1 million customers, mostly Europe and Latin America, and around 11,000 employees

00:22:37

Before 2015, they have very large software releases roundabout every two months. So this made it very difficult to be kind of nimble and respond to market market needs and customer needs and so on. So in 2015 they realized they need to make some changes. And one of the sets of changes they made was in how their teams were organized and they adopted what they called a service delivery teams, which had end to end responsibility, uh, for a product or service or some part of a product or service, um, on us as their thinking and, and the shape of the organization evolved they're reading books like continuous delivery dev ops handbook accelerate. And of course in September, 2019, the book teen typologies was probably used to. And so they, they, they, they looked at the team typologies, but, and one particular thing that they took from the book was around content load team, cognitive load, as a key design principle for thinking about the boundaries of, uh, responsibility, boundaries of teams, um,

00:23:45

And the chief cloud architect at Alexander lifestyle puts it like this team topologies has changed how we formed development teams and so does the team get the right support from enabling teams? What is the, some of the cognitive load on this team and so on? So it's really helps to them to think about how they design teams, how they allocate work and the responsibility boundaries around those teams, the results of these kinds of changes, going back to 2015, uh, that, uh, they've changed from 60 plummets per year in 2015 to two deployments per week in many areas. And in some areas, even multiple deployments per day, and have increased the sense of ownership and responsibility within the teams. Uh, and you can find more information@tinaproperties.com slash examples. So thank you to, uh, Alex lifestyle for, uh, for sharing the experience with us. The final case study today is from wealth wizards.

00:24:43

They provide financial advice online founded in 2009. The customers are both consumers and companies, and they've been increasingly successful over the last few years. Um, prior to 2019, there was a significant growth in the number of different products that were available. So going back to 2017, there were just two products, one pensions, one on retirement advice. Um, but then, uh, 2018 additional products around other kind of investment advice, other kinds of pension advice. And so on came along so effectively, there's a six times increase in the number of different products and services that needed to be offered. Uh, and so the complexity was increasing. The Kobe side was increasing and so on. Um, this all came to a bit of a head in the middle of 2019. When, um, when, in the words of the CTO, we ground to a halt. So releases were taking a long time, sometimes months to appear.

00:25:45

Um, teams were having to look after many, many, many different microservices, um, and the platform that they built at the time made it very difficult to have a consistent user experience across multiple different products. Um, the teams were having to think about many, many, many different things. Fortunately in September, 2019, the team topologies book was published. Uh, and again, in the words of CTO, uh, it was just at the right time and wealth was found the kind of patterns and, uh, language in the book really, really useful for, for thinking for a new way of thinking about this, this kind of challenge and, uh, team boundaries and where, uh, who should be responsible for what and so on. So here's an example of, uh, the new, um, architecture that I came up with after reading Tim typologies book, you can see that at the top of the diagram, we've got some streamlined teams towards the bottom in blue, uh, a series of platforms on the right hand, some enabling teams. And there's a complicated subsystem of team in there for doing some complex calculations.

00:26:49

So Richard Marshall, a CTO at wealth wizards said since apologies has given us the tools we were looking for and, uh, have helped us to build a plan and confidence that we know where we're going and how to get there. So the results of applying this kind of team to probably's approach, uh, that they've got clear patterns in language for conversations between different groups in the organization. They've got a framework for making decisions, design decisions, and they've got confidence in, in their approach to scaling the, the technology part of the business. So thank you to Richard Marshall CTO wealth was us for sharing that.

00:27:30

Okay, we're going to do a quick recap of the main points we talked about today. So we saw this five different case studies. Some of the common aspects were that the streamline team should be a starting point. If we want to achieve fast flow and fast feedback from running systems, We saw how Tim topologies provides a common language and a set of patterns for the whole it organization. We need to explicitly design for team cognitive load, have that always in mind when we're making design decisions. The fact that the platform is not just a set of services, but it's a curated experience for engineers to accelerate and simplify software delivery. We're looking forward to see what's next and hopefully share more case studies with you in the near future. At the moment, we're working on a free workbook around applying team typologies for remote teams, given the current context with the pandemic and most people working from home and the expectation that's going to continue. Um, for, you know, for some time We have a number of free resources. If you want to hear more about remote first interactions, uh, good team typologies.com/remote. First, we have a number of tools and templates available on github.com/tim topologies.

00:29:02

We're also open to feedback and other examples, you can contact us by email or info@timtypologies.com or on our Twitter at Tim topologies, We have remote friendly training available. And if you want to keep up to date on news around the workbook or training or other industry examples, uh, sign up for news and tips on Tim typologies.com.

00:29:33

So we'll be answering questions on slack now, basically. And later on today, 1755. Uh, there'll be an ask me anything session on zoom. So AMA, uh, so hope to see some of you there. Thanks for joining the session today.

00:29:48

Thank you very much.