Scaling Web @ASOS
Over a number of posts, I will discuss how we have been transforming the Web Team at ASOS, enabling us to scale through shared ownership.
Where we started
As part of ASOS’ move to a microservice architecture in 2016, the Web Team modelled itself into micro web apps — which, simplistically assigned one team to one app (page of the website).
These teams were very much your typical scrum teams, following two week iterations with a dedicated Product Manager. This had its benefits as those teams knew the app inside out, had built it to the best of their ability, and had a constant flow of work. However, it also had a number of drawbacks.
The problem
We were not working on the most important thing for the business or our customers. We were in a position — where — due to the differences in technology, tooling and process teams, we were not able to work on other areas of the website. This meant certain teams developed backlogs full of high-value features while others were looking for work to keep them busy.
We suffered from inconsistency across the pages in the styling and patterns we followed — for example, form validation, which was evident to our customers, and made the site feel disjointed.
The move to InnerSource
The move to InnerSource is to help enable us to meet the goal where all web teams are working on one backlog, a single set of priorities and are able to work across the entire code base.
‘InnerSource takes the lessons learned from developing open source software and applies them to the way companies develop software internally. As developers have become accustomed to working on world-class open source software, there is a strong desire to bring those practices back inside the firewall and apply them to software that companies may be reluctant to release. For companies building mostly closed source software, InnerSource can be a great tool to help break down silos, encourage internal collaboration, accelerate new engineer on-boarding, and identify opportunities to contribute software back to the open source world.’
There is an active community with some great reference material
The benefits of InnerSource are very compelling — ones which we would like to explore for the whole of ASOS Tech, but, with all changes of this type, there is a large cultural element to consider, and it’s always best to start small and prove it will work first.
In Web, we have already moved over to GitHub and the teams are familiar with the techniques as they are practised within their teams. What wasn't happening was teams committing to another team’s repository (repo).
To support this, we performed a wider change by restructuring the Web Teams (so that each team had a better mix of skills). The apps (each app has its own repo) were divided across the teams based on familiarity and the teams then became the assigned maintainers. In practice, there was little change with the core apps, but a few of the smaller libraries that were homeless needed a maintainer team.
These teams are the custodians of the repo and have the ultimate say about what changes are made to the code base. Currently these changes come from any Web Team, but, more importantly, these can be opened up to anyone at ASOS who wants to contribute via a pull request.
We are very keen to improve collaboration and work as one team, although we don’t expect pull requests to be raised without first having a conversation with the maintainer team, so that they understand why a change is being requested and what it is.
For each repo, it’s very important to clearly define the rules of engagement, so that anyone who is proposing to make a change understands the standards of the maintainer — and how the code is built and run. We expect the contributor to respect the decisions made by the maintainer, these are defined in each repos CONTRIBUTING.md in GitHub.
We have embraced this by setting up our template standards as an InnerSource project https://github.com/asosteam/asos-standards (Shout-out to Tony Gorman for this).
We are about four months in and we have seen a healthy amount of collaboration across the teams, and active creation of new shared libraries. We have delivered a few large features that have required teams to work on apps that they would not previously have touched and it would have required a story to be scheduled with another team.
What we have noticed is that not all apps are in a state where anyone can pick them up and some are not currently meeting the standards defined in the InnerSource template. However, this is a journey and teams are actively working to adopt these.
The signs are really positive and we are moving towards our goal, but changes like this take time to embed themselves and be part of the culture. To support this move, we will continue to update the apps to get them to a position where they are suitable to be inner sourced. We know that changes will take longer initially while we raise the quality bar, and we will support teams through this. We will also make sure we upskill the teams on apps where they are not the maintainers.
What’s next?
In the next post, I will discuss how we have moved to feature teams — watch this space.
About the author
Andy is a Platform Lead at ASOS, passionate about building great products, teams, and organisations.
