Team Topologies at PureGym - responding better to business needs with well-defined software teams
By John Kilmister and Richard Allen
Overview
As the IT team at PureGym grew beyond 20, the strategy of using short-lived project teams with handovers to maintenance teams started to result in reduced productivity and lower morale caused by the complications of managing multiple projects and complex systems. Their approach to value delivery needed to change.
Using the ideas described in Team Topologies, PureGym was able to communicate how and why working practices needed to adapt using the core concepts to give team members more ownership and autonomy whilst reducing their cognitive load. This case study describes PureGym’s journey in the adoption of the Team Topologies principles and practices.
A Brief History
PureGym was launched in the UK in 2009 and is now a leading international gym and fitness operator which provides its members with flexible, affordable fitness facilities. The group is the second-largest gym and fitness operator in Europe serving approximately 1.7 million members from over 500 facilities across the UK, Denmark, Switzerland and Poland. In the UK most of its gyms are open 24/7 and technology plays a large part in this, allowing members to join and manage their memberships both on the mobile app and website.
In 2014, PureGym was outsourcing the majority of its business functions including IT. As part of their growth strategy the decision was taken to bring the IT function in-house, with a goal of being independent of their existing supplier within 6 months. To keep the architecture simple and meet the tight delivery timescales, they chose to build a monolith. The team adopted good modern software delivery practices such as Behaviour/Test Driven Development (B/TDD), Continuous Integration/Delivery (CI/CD), Monitoring, Logging and Lean delivery processes. This meant they were able to deliver features up to around 8 times per day. After successfully delivering the initial website migration project, PureGym maintained an IT team of just 8 people.
Short Term Projects
During this early period, the approach to delivering business value was to set up small short-lived project teams who would then hand over to a small “Business As Usual” (BAU) team who focused on fixing bugs and making small changes (less than 4 days work). There was also a supporting team called the “Getting Stuff Done” (GSD) team whose focus was on internal maintenance, tech debt and the CI/CD pipeline. The original intention of having the BAU/GSD teams was to prevent the project teams from being distracted by bugs and unplanned work which might put the project timelines at risk.
Projects would typically run for periods between 3 and 6 months with each project team working with a stakeholder from a particular business area. After the project was completed, ownership of the operation and maintenance of any new features would be handed over to the BAU teams, which enabled the project teams to be disbanded and re-assigned to new projects working with another stakeholder in the business.
As with any growing business, there was demand for more and more features to be developed. In response to this, the team size was increased to allow more projects to be delivered. Each new project subtly increased the complexity of the software systems and over a relatively short period of time small knowledge siloes began to emerge. It started to become difficult for members of the BAU teams to keep a good understanding of all the systems in their head.
Challenges Presented By Growth
In early 2018 there was a major business initiative to drive growth and the IT team needed to double in response to this. Initially, the same strategy of adding more project teams was adopted but project prioritisation started to become complicated.
People in the project teams gained specialist knowledge as the projects became longer and more complex and when the project teams were disbanded that knowledge was dispersed into different teams.
The short-term nature of projects meant that long term business and architecture planning was hard because project team members needed to focus on meeting project deadlines and stakeholders did not know when they would have another project team available to them after their existing project ended.
Issues started to take longer to resolve, knowledge became more siloed, communication between teams started to deteriorate and a general lack of system ownership led to bottlenecks in the process.
It was obvious that the current team structure was not going to support the growth required from the business and something needed to change. In late 2019, the timely publication of the Team Topologies book coincided with our need to better describe how we felt the organisation needed to evolve. The structures set out in Team Topologies aligned well with our own thoughts and provided a roadmap for our desired transition to long-lived product teams and a clear way of communicating this with the wider business.
Taking a Team-First Approach
A key principle introduced in Team Topologies is the concept of reversing Conway’s Law. The law states “Organisations which design systems...are constrained to produce designs which are copies of the communication structures of these organisations”. By flipping this on its head it is possible to organise how the teams are structured to determine the desired architecture of the system. We used this principle as we began the re-organisation of the teams at PureGym.
We needed a way to split the teams that would help them to become more long-lived, have a greater sense of ownership and provide more autonomy over feature priority and architecture. Team Topologies proposes a team-first approach using terminology such as team types, team interaction modes and fracture planes that became essential in describing the team structures.
Team Types, Interaction Modes and Fracture Planes
There are four key team types; Stream Aligned team, Enabling team, Platform team and Complicated Subsystem team. Each team type has its own purpose, role, responsibility and interaction behaviour. Using these terms to describe each team allowed us to reduce ambiguity in our discussions about the organization redesign.
We needed to identify features of the software system that would be suitable fracture planes (natural seams in the system that allow it to be split into one or more parts).
To do this we looked at things like how often changes are delivered, the risk associated with the delivery of features and whether there might be areas of the system that are subject to regulatory compliance.
Reducing Cognitive Load with Autonomous Teams
When assessing which parts of the system each team should own it was important for us to bear in mind the potential cognitive load that the teams would be able to cope with. After analysing some of the product areas we felt that some were actually very simple and therefore did not require a team of its own. Following the Team Topologies approach we attempted to ensure that no team had ownership of more than 1 complex or complicated domain but they could own a number of other simpler domains. The result was the definition of the following stream aligned teams:
Acquisition - responsible for areas that onboard new customers such as the join process and landing pages
Gym Team - responsible for areas related to the in-gym experience such as class timetables and bookings
Payments team - responsible for taking customer payments and reconciliation
Retention team - responsible for areas related to ensuring the member gets the best experience
Each stream aligned team would have a key stakeholder with clear business goals and would be responsible for managing bugs and small changes with their areas of code, removing the need for BAU and handovers.
The goal of the stream aligned teams is to deliver value within their stream as effectively as possible and to support them in achieving this we introduced two enabling teams for Developer Experience and Site Reliability Engineering. The members of these teams are DevOps advocates who help guide the stream aligned team members on good practices and provide advice when setting up environments or CI/CD pipelines.
The Membership Management Gateway Platform Team owned all interactions and APIs required to access data from the Membership Management System. Each of the stream aligned teams would interact with this team in order to manage or utilise member data.
During this process we found it difficult to classify the Mobile Team into one the four team types because it seemed to include many aspects from the other teams such as retention and class booking but also had its own stakeholder within the business. At the time of writing, the Mobile team most closely resembles a stream aligned team - however Team Topologies is an evolutionary process and the team structures are likely to change over time.
Defining The New Team Interactions
Team Topologies describes three team interaction modes: Collaboration, X-As-A-Service and Facilitating. These modes define the “rules of engagement” between teams of different types.
After creating the new teams, there was a phase of intense collaboration between each of the stream aligned, enabling and platform teams to determine how to break the monolith up into smaller services. The core focus of this collaboration was to agree on boundaries and the good practice for which the DevEx and SRE teams would become evangelists.
After this, the teams began to implement any required X-As-A-Service APIs which would allow the teams to engage with each other. The DevEx and SRE teams played the role of facilitator to help implement any required build pipelines and infrastructure using Infrastructure As Code (IaC).
Once the teams had settled into their new roles they moved into a phase of short periods of collaboration and facilitation when required. For example, if a feature cross-cut both the mobile app and the website, then the mobile team may need to collaborate with the Retention and/or Acquisition teams for a short period to ensure consistency of feature delivery between them. With other cross-cutting concerns, such as multilingual implementations, there may be times when some of the stream aligned teams collaborate or act in a facilitating role for a period if they have some expert knowledge that could be shared.
Depending on the stage of development of a product, each stream aligned team could interact with the SRE team in the facilitating mode if they need help setting up some new infrastructure or they might collaborate with the DevEx team to help improve their working environment. The DevEx team would then help spread that knowledge around the other teams to help ensure consistency and efficiency where possible.
Introduction of Team APIs and Chapters
After creating a clear definition of the purpose, role, responsibilities and interaction modes for each of the teams it was possible to start creating a Team API which is used to help other teams understand how they should interact with the team.
At present this takes the form of content on the company wiki which includes information about the team’s processes, the product areas they look after, the tools they use and any knowledge base articles that might be relevant to their products. Over time this will be expanded to include details on the product APIs that they provide “as a service”.
Each team has people with different skill sets from front end JavaScript developers to backend database developers and test specialists. In order to keep communication flowing between members of different teams across the organisation that may have similar interests we have also introduced the concept of Chapters. For example, a Front End Developer chapter meets regularly and discusses anything specific about JavaScript, CSS and HTML good practices. There are also Software Security, CMS and Content, DevOps and QA chapters.
Conclusion: Increased productivity, boosted morale
Something didn’t quite feel right about the way we were setting up and tearing down project teams at PureGym. When the team was small, the issues weren’t so obvious but they were lingering in the background. As the team began to scale, the cracks in the process emerged, delivery slowed and friction between the teams became apparent.
We knew we wanted to move towards longer-lived product teams and we had an idea about what needed to be done to change, but it was difficult to convey to the management team in simple terms. Team Topologies provided us with a way of communicating how and why we needed to change our working practices. By reversing the principles of Conway's Law and adopting concepts such as the 4 team types and interaction modes combined with a deeper understanding of cognitive load, we were able to adapt the way we work and create a working environment that has boosted team morale and increased our productivity as PureGym continues to grow.
There will be many challenges ahead and the journey is far from over, but with the help of Team Topologies, PureGym now has a blueprint that will help shape that growth into the future.
About the Authors
John Kilmister - PureGym
John Kilmister
Principal Software Architect, PureGym Ltd
T: @johnkilmister
Richard Allen - PureGym
Richard Allen
Head of Consulting, Conjurer Solutions Ltd
E: richard.allen@conjurersolutions.co.uk
T: @rich_allen