I was recently asked to speak about my experience scaling a single mobile team to multiple squads and the lessons learnt in the process. This post is a summary of that talk.

The problem

After the initial Covid lockdowns there was a lot of funding for new mobile projects – awesome! But how do we scale from one squad with four mobile developers to five squads with over 20 developers while maintaining our ability to release new, high-quality features quickly with minimal issues?

Life as a single mobile team – easy!

Having all iOS and Android knowledge centralised in one team is very convenient due to the many unique mobile development best practices such as staggered app store deployments. And as the only team delivering to these mobile apps we have the flexibility to delay or cancel a release if it suits. 👍

What about five teams?

When new teams are spun up from scratch or existing teams add mobile capabilities there is bound to be some gaps in their understanding around streamlined processes for mobile development. Even something as common as writing a single set of requirements for iOS and Android stories might not be known, resulting in duplication of work and divergent implementations.

New feature teams may also have limited budgets and be short lived, creating an environment where cutting corners on quality might be considered and leaving us with features we don’t understand and can’t maintain.

More importantly, how do we keep the codebases highly maintainable and minimise tech debt when a dozen or more new developers start contributing while spread across many teams? We were very protective of our 4.5+ star ratings on the Play Store and App Store, and wanted to ensure users continued to enjoy using our app.

And lastly, how do we align and schedule feature releases when everyone is working to different deadlines?

The Mobile Platform Team

To help drive quality and consistency across the iOS and Android apps we created a “platform” on which squads can be added and removed as needed. The owner of this platform is the Mobile Platform team.

In general, this team is not product/feature focussed but would commonly implement broad features and tools such as analytics, tooling updates, and CI/CD. A huge feature of the Mobile Platform team is that it allows feature squads to focus on new products and features.

Initially this platform team consisted of a single Android and iOS lead but eventually we were able to add another iOS and Android engineer, as well as an Engineering Manager.

A large part of our work was to liaise with feature squads, namely around onboarding of new teams and developers and release management using our release train process.

Onboarding & collaboration: New Mobile Developers

The Mobile Platform team was responsible for hiring developers for feature squads to ensure they had the skills necessary to use our current set of architecture and testing tools and patterns. Once hired we held several sessions over their first week to ensure familiarity with the app and products, as well as quality requirements such as unit and UI testing, and code reviews.

After that we continued to collaborate with the developers in other teams by way of:

• Weekly huddle and dedicated Slack channel to discuss engineering updates or issues
• Monthly hack day for all devs, including contractors
• Developer experience surveys to drive continuous improvement

This helped ensure no one worked in isolation from the other engineers and was generally well received. 🙂

Onboarding & collaboration: New Squads

Each time a new team “joined” mobile we held a one-hour mobile “Bootcamp” session with all members of each new squad to go over:

• Existing conventions for UX design and UI components overview
• Testing tools and practices, e.g. Charles Proxy
• Detailed explanation of delivery train process for pushing new features into production and recommendations for internal and marketing communications
• Other advice depending on squad’s experience with mobile

This was not always well-received. ☹️ In hindsight we didn’t provide enough reasons and benefits for the platform processes, which could appear cumbersome, complex and inflexible, when in fact we were trying to provide the opposite: predictability, consistency and stability.

Fortnightly release train

With many teams all trying to release things at various times there needed to be a structured, predictable release process with clearly defined roles and responsibilities so that everyone knows how and when to get their features released on the mobile platform. The mechanism for this was a fortnightly release train.

Below are the key checkpoints for testing and communications; this worked well most of the time.

But sometimes …

“The business needs this released on this date!”

“Why can’t we release on that date?”

“Why can’t you wait a few days for us to finish this feature?”

Inevitably there were times when demands were made for us to deviate from the process of cutting a new release immediately at the end of each sprint in order to meet a specific delivery date that had been promised to the business. This was always accommodated but we encouraged scrum masters and product owners to adopt more Agile approaches and iterative delivery over rigid deadlines.

Recommendations

Overall, the centralised Mobile Platform team structure help us add multiple teams over a long period, deliver dozens of new features and maintain all our key metrics including app store ratings. Here are a few final thought for anyone involved in scaling up the size of their mobile teams:

• Have at least one person responsible for the mobile apps/platform as a whole or you might find features are built without consideration for the long-term health of the apps.
• A centralised UX/UI design function is also good. This is done by ANZx with a team dedicated to designing, building and maintaining their suite of UI components.
• Release trains work well but try to build in some flexibility.
• Investment in innovation and good engineering practices will easily pay for itself, for example hack days, CI/CD and time to address tech debt. It also helps to attract top talent.
• Prioritise stability over new features.

As always, please leave a comment if you have any other tips or interesting experiences building mobile apps at scale.