Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Applying Team Topologies at PureGym
Similar to Applying Team Topologies at PureGym (20)
Recently uploaded
Recently uploaded (20)
Applying Team Topologies at PureGym
- 1. @
- 2. Less Than 10 People Project A Project B Bugs Small Changes GSD Projects BAU Project C Handover
- 3. Team Grew to 15 People Project D Project E Small Changes Project F Projects BAU Project G Project H Bugs GSD Handover
- 4. Bugs & Small Change Project G Project H Project I Project J Project K Trigger: Rapid Team Growth to 40 Projects BAU GSD Handover
- 5. The Monolith Site Project G Project H Project I Project J BAU Vendor API Reseller API Mobile App Mobile Team Customer API Membership Management System Single repository
- 6. Gyms Breaking the Monolith Site Class Listings Members Area Payments Help Centre Class Booking Join Process PT Profiles Gift CardsLanding Pages Project G Project H Project I Project J BAU Group Training Time Tables Blog Live Chat Kiosks …
- 7. Re-defining Teams SREDeveloper Experience Membership Management Gateway (MMG) Acquisition Join Process Landing Pages … Gym Team Time Tables Gyms … Payments Reconciliation Join Payments … Retention Members Area CRM … Other…. … Streams Enabling Mobile ??Platform
- 8. SREDevEx High Collaboration Phase Payments Team Acquisition Team Retention Team Gym Team MMG Mobile?
- 9. SREDevEx Using Facilitation and Developing X as a Service In Gym Experience Team Payments Team Mobile Team ? Acquisition Team Membership Management Gateway Team Retention Team
- 10. Continuous Collaboration and Facilitation SRE DevEx In Gym Experience Team Payments Team Mobile Team ? Acquisition Team Membership Management Gateway Team Retention Team
- 11. Summary
Editor's Notes
- Circa 2015-2016 When team was small (less than 10): Everyone knew and could talk to everyone Amount of code was small, cognitive load was low Everyone did everything Approach: Short-lived project teams BAU team focused on fixing bugs, making small changes (less than 4 days work) and Getting Stuff Done (GSD) – internal maintenance, tech debt, CI/CD pipeline etc
- Circa 2017 – Mid 2018 Team grew (15): Initially expanded by having more project teams. When the projects ended, the team disbanded and support fell back to a single team (cognitive load still not too high) Projects were decided by top-level (C-Suite) as there were only ever one or two strong clear messages on what focus was on. At the time it felt like there we not enough developers for parts of a system to be fully “owned” as it may be months between touching part of systems. During this period, the solution was getting too big to fit in peoples heads however we would often find that something would be worked on and then not touched for 6+ months (there was not enough capacity to deliver everything the business wanted in a particular area before focusing people on a different part of the system) . Splitting the team into two and giving half things to one team and half to another did not solve the issue as although they would have ownership there was still way too many things for one team. One of the main push backs on stream alignment was will “I have a team with no work”. If we set up a team that only looks after one area what happens when the business does not want to focus on that area in the next year and support requests are only a few hours per week? This became a trigger to scale the team further.
- Circa 2018 – Mid 2018 Rapid Team Growth (40): Project prioritisation became complex as there were so many projects and they could not be managed in same way Project time was split/passed between stake holders (3-6 month timeslots) People gained specialist knowledge as projects became longer and more complex however this could be lost as the project teams were disbanded It became hard to plan long term on product because focus was on the project delivery before stake holder lost their time slot Number of projects to maintain became larger so BAU team became overloaded Challenges to scaling: Speed to resolve issues due to cross team dependencies Inter-team communication and lack of system ownership Specialist knowledge lost after project teams dismantled Handovers at the end of each project were troublesome Project end dates forced a short-term view of products Competing and misaligned product owners
- Initially, an initial explicit decision was made to build a monolith application when the team was small in order to keep the code base as simple as possible. However, as the team grew, this resulted in all of the different project teams touching areas of code from across the entire estate. This increased dependencies between project teams but due to the short-lived nature of the teams there was no ownership of any particular area. Project teams were unable to plan for long-term architectural changes and deliver them in small increments due to the short-term nature of the projects. The monolith meant that we were limited to around 12-16 deploys per day and this was not scalable, if we want to increase throughput this needed to change
- In order to break the monolith we evaluated all the different areas of the site and attempted to determine relevant fracture planes that would help teams to become more long-lived, have a greater sense of ownership over the code base and more autonomy. Challenges: Deciding which teams owned what and how many things each team owned Took 3 months to design and explain to business colleagues and get “buy in” for the change
- Jan 2020 Most of the teams created were stream aligned teams. We used various fracture planes such as change cadence, risk, regulatory compliance and natural with the core focus on how can we reduce cognitive load and create more autonomous teams. Ideally there would be more streams aligned teams. However we used the annual goals to determine which product areas were going mostly affected over the next year because the biggest push back from upper management was “what if that team has no changes to their products in a year” and did not want a team without work. For example the Acquisition and Retention teams own various parts of the code which on their own might not have sufficient mass to warrant their own team at present, but new stream aligned teams may be introduced in the future as required. One challenge was how determining how we handle cross cutting concerns such as make the whole app work in another country and aligning. Previously, this was owned by a single project team that would make all of the changes across the entire application, with stream-aligned teams we would require more cross team collaboration in order to deliver efficiently. Mobile was a new project and as such touched all the other areas yet had a single stakeholder, so we aligned the mobile team as such. Team Types: Steam Aligned Teams: Retention, Acquisition, Payments, In Gym Experience, Member Services –– each would have a key stakeholder with clear business goals and would be responsible for managing bugs and small changes with their own areas of code. Enabling teams: SRE and DevEx Team – DevOps Advocates, responsible for helping the stream aligned teams deliver value as efficiently as possible Platform: Membership Management Gateway Team – responsible for all interactions and APIs required to access data from the Membership Management System Mobile - ??? Team – at present we are not sure how to classify this team
- After the initial creation of team boundaries, there was a phase of high collaboration between each of the teams that owned part of the monolith as we had different skill sets across the teams. This collaboration was between all the Stream Aligned, Enabling, Complex Subsystem and Platform teams in order to determine how to break the monolith up into smaller services that would decrease cognitive load and improve flow of change. The core focus of the collaboration was to agree boundaries, agree best practice in order for the DevEx and SRE teams to become the evangelists for the best practice. The shift in team definition and ownership meant that each team now had a roadmap of, not only their desired feature list but also the potential architecture, changes they wanted to make over the coming year. This meant that the teams could plan their interactions and determine the dependencies between each other.
- After a period of high collaboration, the teams began to implement the required X as a service configurations that formed dependencies between the teams. At this point, the DevEx and SRE teams were providing more of a facilitation role to help the stream aligned teams implement required build pipelines, infrastructure using IAC etc.
- After the basic team structures and collaboration modes were put in place we moved into a phase of continuous short periods of collaboration and facilitation between the teams. 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 of time in order to ensure consistency of feature delivery between them. Other cross-cutting concerns such as multi-lingual implementations there may be times when some of the stream aligned teams collaborate with each other 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 a facilitating fashion 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.
- 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 became more obvious, delivery slowed and friction between the teams became apparent. We knew 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 a simple and cohesive way. When we stumbled upon Team Topologies it felt like we finally had a way of communicating how and why we needed to change our working practices. By adopting some of the core concepts such as the 4 team topologies and interaction modes combined with the deeper understanding of cognitive load, Conways Law and Dunbar’s Number we were able to adapt the way we work and create a working environment that has boosted team morale and increase our productivity as PureGym continue to grow. There will be many challenges ahead and the journey is far from over, but with the help of Team Topologies PureGym now have a blueprint that will help shape that growth into the future.