Founded in 2005, 15 years later Footasylum has 70 stores nationally and a thriving ecommerce platform, with revenue of £260m per annum and over 2500 employees. Making its name in the sneaker and streetwear space, Footasylum gives fashion-focused youth a multi-branded retail experience mixing global sportswear household names with emerging brands and its own stable of in-house labels.

We spoke to Andy Norton, Software Development Manager at Footasylum, about the ways in which Team Topologies has helped to shape teams and software delivery within Footasylum.

The Team Topologies book has put names to emergent patterns, and allowed our teams to create effective lines of communication based on collaboration. These patterns have become even more important during the COVID-19 pandemic as our teams moved into a more asynchronous way of working, where direction, purpose and agile governance were required in order to give the teams the autonomy to help our business succeed.

The Product Managers from each team took special interest in the team interaction types as it helped them to have useful, directed conversations about upcoming work, they could essentially fact-check their different roadmaps and make sure that the interactions required were lined up in advance.

the interaction modes defined by Team Topologies gave us real insight into how we could maintain effective practices, and also cross-team collaboration.

A Year of Change

Footasylum’s transformation began with the appointment of a new IT Director, Paul Martin, in February 2019. Over the next 12 months the IT department would completely change the way it worked, it’s shape and even how it was seen by the rest of our business.

It was clear that change was required. IT had become a silo, with no work aligned to the needs of the business. A reorganisation was needed to understand the challenges of our business and colleagues.

This started with looking how work was flowing through the system, and the way the team communicated with each other.

Dysfunctional Team Dynamics

Historically, a piece of work would start with a Senior Product Manager, who would in turn give this to a team of Product Managers, each of which would then assign the task to a developer. The teams boundaries were drawn up by their location, instead of the product they worked on. The IT department in the U.K. was made up of 27 people across development, product management, support, infrastructure and data, while there were over 40 people in teams in Romania and India. The work was assigned to individual developers, with a handover of work from a Product Manager team to the development team. This formed not only a constraint, but also a complex communication path for context to be lost in.

Individual developers were responsible for features and bug fixes, as well as being directly contacted by people in other departments. This led to the priority of work changing to meet the short term need of frustrated colleagues, instead of focusing on a wider business outcome and creating transparency and a closer working relationship.

Constant context switching meant that features were half implemented, which led to a brittle system where shortcuts were taken and technical debt accrued. The trade-offs for not paying down this debt meant that creating safe systems would be sacrificed in order to deliver to deadlines.

It was apparent that the organisation of the teams were creating poor outcomes for the department due to their way of interacting.

Conway’s law states that -

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”

A typical example of this within Footasylum were similar implementations of features across different teams, all tightly coupled to the same underlying service or database because of a lack of a shared vision. Updating a core service would need significant coordination across multiple teams, frequent re-work, and would typically lead to issues for downstream consumers.

Each of the teams - due to the way they were split based on location, would focus on multiple systems at a time, an example being a team in Romania which would develop an EPOS system written in Java as well as ERP middleware written in C#. The cognitive load on this team was immense, with them having to understand two complex systems without clear boundaries of ownership.

The decision was made to disband the teams in India and Romania, and instead invest in building multidisciplinary product teams at our offices in Rochdale and Manchester, fostering an environment where a culture of innovation and effective delivery could take shape.

Forming, Shaping and Patterns

The first step of reorganising the teams was to identify boundaries between each part of the business from a domain point of view, and create small product teams to align to a business unit, with the ability to work independently of other teams. By the team having everything it needs to do the job without hand-offs to other teams, it gave the team autonomy, clear purpose and ownership of their problem domain.

As the teams moved into alignment with areas of the business, there was still the problem of how to share key services and bounded contexts such as stock or pricing information. Previously each team would access the same database - an anti-pattern in itself, or implement their own version of an integration with a 3rd party. Moving forward, in order to reduce hand-offs and downstream issues, there was a clear case for another kind of team, one that would provide services to each stream-aligned team.

It was around this time, in June 2019 that the authors of Team Topologies presented at DevOps Enterprise Summit London, and having watched their presentation, we identified clear parallels with the teams we were trying to build, and the patterns of successful teams that Matthew Skelton and Manuel Pais codified. It provided key insights, shared terminology and clarity on how to build teams capable of effective software delivery.

The Product Managers from each team took special interest in the team interaction types as it helped them to have useful, directed conversations about upcoming work, they could essentially fact-check their different roadmaps and make sure that the interactions required were lined up in advance.

Creating a Stable Platform

In August 2019 the Team Topologies book was released, and we purchased copies and shared them round the department. Teams were able to see where they fit in the 4 fundamental team types, and our Services team renamed themselves to the Platform team, and even had a cake to celebrate.

The newly christened Platform team’s first task was to start breaking up the complicated legacy backend systems that shared a database - into components that could be individually deployable. Increasing safety was their primary goal at this point, building quality in at an early stage by adopting a lean, loosely-coupled, test-driven approach.

Connecting the Dots

Now that we were starting to see the shape of teams emerge, we shifted our focus to how they should work together so that we were reducing the cognitive load on each team but also optimising interactions in order for a team to work with as few dependencies on others as possible.

the interaction modes defined by Team Topologies gave us real insight into how we could maintain effective practices, and also cross-team collaboration.

Being a retail company, we have a value chain that stretches from our high-street stores, website and mobile apps to our warehouse operations and logistics processes. Each of the stream aligned teams across this chain works at a different pace, so enabling fast flow was key, and the interaction modes defined by Team Topologies gave us real insight into how we could maintain effective practices, and also cross-team collaboration.

In order to understand the environment we found ourselves in, we turned to Wardley mapping. This technique gave us the ability to see our value chain, the systems involved and dependencies across our teams. It also helped guide our strategy and the target architecture we were attempting to build.

We started the interactions between platform and stream aligned teams by focusing on fundamental bounded contexts which would need exposing as services, starting with the services needed around our ERP system - as the ERP was treated as the source of truth for the data close to the warehouse, including product and pricing information.

The ERP team’s system is a commodity and well understood. Using this team first would allow for us to refine how a service should work, by exposing a key data point ‘Products’ which could be consumed by teams as ‘X as a service’, with a focus on self-service based on interacting with auto-generated API documentation.

Applying a pattern for team interactions allowed for shared terminology to be applied during conversations about roadmaps, helping to facilitate discussions where there was a clear idea whose responsibility it was to build a service, and how the teams should act at different points in coming months.

Optimising for Flow

The aim of the platform team is to optimise for flow and to reduce cognitive load for stream aligned teams. As stream aligned teams were moving quickly, with assumptions to test, it was clear that the idea of a thinnest viable platform would reduce the time taken to validate assumptions by providing the minimal amount of what’s needed, in the book this is described as even being a wiki page.

In our case it was making the first conversations between the teams around the data, the problem it was solving and the outcome they’re looking for. By questioning the nature of the data and the outcome of the service, we were able to reduce overheads now and think about complexity later.

An example of this interaction was the locations service which would need to provide information about our 70 retail stores for our EPOS system and mobile applications. Following the Thinnest Viable Platform pattern - the team started with static data instead of pushing for a full service that might need a database and a service layer. A simple hard coded JSON response from the API gateway would be enough for the stream aligned team to carry on working, as they only cared about a list of stores, and because the frequency the data would change was so low, it didn’t add value to make this dynamic. The assumption being at a later point they would come back to iterate on it, six months later static data is doing just fine.

We started to see the need for composite experimental services that may call multiple underlying services, bringing data together before returning a subset to a client. The backend for front-end architecture for our mobile application is a good example of this arrangement of services, with core services, owned by Platform being called by a stream aligned service (a service with only one direct consumer).

Platform would collaborate with the mobile app team, making sure the cognitive load of the mobile team was limited to iOS development, without the team having to worry about the intricacies of stock calculations. To them, their lightweight API backend service built in collaboration with the platform team, may as well be calling a 3rd party for it’s core data, as they had no need for any understanding of stock beyond what the self service API documentation provided.

Scaling and Evolution

Early on we recognised the importance of our microservice evolution, and how these services would change over time. We identified that we had 3 types of service

Using Simon Wardley’s Pioneer/Settler/Town Planner framework we recognised that pioneer services would be our TVP, with the Platform team giving the Stream Aligned team static data via a simple API endpoint, or access to a sandbox environment on Azure. They could build the minimal service themselves, and as they validated assumptions and needed to grow the service, the interaction would change from X as a service to collaboration.

Platform’s role at this point would change, instead of handing over the minimal platform needed, they now helped developers on the stream aligned team to get started on a proper implementation, including scaffolding pipelines, linking telemetry to existing monitoring and alerting services and allowing the stream aligned team to work purely on the implementation details, and advising on how to connect core services such as stock, into their service (settler).

As the service matured, it could move from a custom build into a commodity, and start to be reused, there were also overlaps in services required by different consumers, such as website and mobile applications requiring a shared basket. This basket service would start life as a static dataset returning a dummy basket, and as the needs of the service evolve, it’s data source would shift to the SaaS ecommerce platform, and the returning data would be enriched by a core service (town planner).

In future the stream aligned team for the mobile app might want to incorporate this basket service into their iOS app, Platform would facilitate the changes, working with both the current consumer - the ecommerce team, and the new consumer - Mobile App team, to make sure it’s following the practices that all services need to have as it moves from an experimental service to a product service. Considerations such as resilience and an ability to scale become important factors, with minimal changes required to deliver a service for both.

Emerging Teams and Practices

So far we’ve covered only 2 of the 4 team types, as we’re still in the process of evolving our teams and their interactions. We’ve also grown our teams into additional areas aligned to new business objectives, including our loyalty program and an in-store mobile app. We’re also just starting to see the emergence of an Enabling team. Initially our plan was to have data people in each team, but instead we’ve seen data people join teams as and when they’re needed. A database engineer might only need to work with the team for a week until the team is self-sufficient, and business intelligence developers might only need to verify data is reaching a data lake, in these cases, they’re essentially an enabling team.

As our systems become more complex, we will start to need specific skills for a short period of time. The 4th type of team, Complicated Sub-System, will likely emerge in the coming months as we invest in new experimental services outside of our current teams’ cognitive load.

The Team Topologies book has put names to emergent patterns, and allowed our teams to create effective lines of communication based on collaboration. These patterns have become even more important during the COVID-19 pandemic as our teams moved into a more asynchronous way of working, where direction, purpose and agile governance were required in order to give the teams the autonomy to help our business succeed.

Follow Andy Norton:

• LinkedIn: https://www.linkedin.com/in/andrewjamesnorton/

• Twitter: https://twitter.com/andyjnorton

Follow Footasylum:

• LinkedIn: https://www.linkedin.com/company/footasylum/

• Careers: https://www.footasylum.com/careers/

• Twitter: https://twitter.com/FootasylumTech