Scaling Web @ASOS Part 2
This is the second post where I will discuss how we have been transforming the Web team at ASOS, enabling us to scale through shared ownership. In this post I will look at how we are moving from component teams to feature teams. If you missed the first post you can read it here.
In the first post, I defined some of the problem statement. As well as the way we were structured, we also had some other inefficiencies, for example:
- Some changes might span across four or more teams
- We might have a change that requires further changes across multiple platforms (iOS, Android and Web)
- Some might touch multiple web apps eg ‘my account’ and ‘checkout’
Previously this would have meant stories were added to the backlog of the team who owned the component. Each one of these teams performed their own analysis on the change before proposing their design on how it should be implemented. This not only meant that the product manager was having separate conversations with each team, but there were also variations in what was being built.
A change was required, so we set out the following vision:
‘To have a single backlog of work and have the ability to work on the most valuable features to ASOS.
We are one Web and Apps team delivering value together.
We all own the product’
We outlined the key areas where we wanted to improve:
What did we do?
We tried something different….
As the new GDPR regulations were coming in May 2018, we had to make a number of changes across multiple platforms for ASOS to become compliant. This seemed a great opportunity to try something different; we wanted to use this as an experiment and use the lessons learned to form a model that we could apply across the wider team. There were a number of principles we followed:
- Minimise change and disruption to the engineers and QAs
- Create a team that can deliver all the requirements for its platform
- Limit the amount of waste
- Maintain consistency of user experience and design (UX+D) requirements
- Avoid synchronising delivery across Web, iOS and Android
The below shows how we restructured the team into two, rather than the five previously. This enabled them to deliver the entire feature.
The pilot was hugely successful and we had a number of positives to take forward. Following a retrospective, it was evident that there were some lessons to be learned. Due to the divergence in the components, it was difficult for a team to pick up something from scratch; the components were all coded, built, tested and deployed in completely different ways. This is one of the consequences of allowing autonomy across software engineering teams.
To solve this, we looked at what components and skills we had in the team, and then reorganised ourselves to have a better overlap of skills. This was done as inclusively as possible to enable everyone to have a say in what they thought was the best approach. The teams reformed themselves, re-evaluating how they work.
We really believe in the benefit of long lived teams, and, as such, we don’t want to move people for the shape of the work. In parallel, we have been developing a strategy to move to a more closely-aligned tech stack, following a maintainer model. Due to the diversity of the tech stack, it’s not expected that the teams and engineers are experts in everything, but as shown below, they will have areas of speciality as well as areas that they generalise in.
The change also significantly impacted the BA’s — previously they were coupled to a single team but we changed this so that the BA now has a ‘home’ team and manages the small changes that come in, but also runs a feature across Web and Apps.
What’s next?
We are still on a journey, and, at present we are not in a position where all of our teams are able to work on every part of the native app or website. This is partly down to time and exposure, but also due to us needing to continue to consolidate our tech stack and tooling, but we are gaining momentum. Right now, we have only addressed this at the front-end of Web and Apps at ASOS, but we have started to look further afield at the entirety of the ASOS tech estate to see where we can apply learnings to help us continue to improve.
About the author
Andy is a platform lead at ASOS, passionate about building great products, teams, and organisations.
