In Q3/2021 TravelPerk created a Mobile Platform squad. Our mission is to be a servant of the product squads and empower them to build high-quality scalable applications.
Here’s what we’ve been doing.
Why now?
TravelPerk is growing, our backlog of amazing features to help our clients is also growing. What’s more, new colleagues will be joining the team this year and the next one.
We all come from different backgrounds and we know how hard is to scale up an app when you don’t have the right foundations. The answer to when the right time is to put the processes and tools in place to allow a team to double in size is usually the same: yesterday.
Precisely because of that we want to invest in our future, we’ve set up a platform squad to start preparing the ground.
Our team is still small, so we can implement profound changes without impacting too many people. And it’s easier and faster to align.
Squad composition and how we work
At the moment, we are an army of two: one Android and one iOS engineer plus an honourable mention to TravelPerk’s director of mobile engineering who is helping with a few tasks.
TravelPerk is an OKR-driven company. I won’t go too much into details about how each squad set their own OKRs (aligned with company and engineering OKRs in our case), but you can read more about it here if you’re interested.
Long story short: at the beginning of 2021 we defined our vision for the year, where we wanted to be by the end of it, what things we were missing and how could we get there. Our first OKRs were based on that vision.
Those OKRs translated into a bunch of Jira stories in our new squad’s backlog. Each team at TravelPerk can decide how to organise themselves freely, so we went for a Kanban approach with weekly alignment meetings.
Every Monday morning we get together, review what we did last week, what impact that made, what are our priorities for this week, and if something needs to be re-prioritised. That usually takes from 30 minutes to an hour. After that, down to work!
What did we do?
We had ambitious goals for our very first quarter. Our two OKRs were:
OKR 1: Take ownership of cross-squad components
OKR 2: Empower Product Squads: “you build it, you own it”
At TravelPerk, we work with cross-functional squads that own parts of the product. For example, we have a squad composed of mobile, backend and frontend engineers, designers, and product owners that manage the experience of booking trains on TravelPerk. And this squad owns everything related to that part of the business.
What does ‘owning’ mean?
For any product squad, it means developing and maintaining a feature of the product. They are ultimately responsible for monitoring that the feature works as expected and taking action on any problem that may arise.
For the mobile platform squad, we set for ourselves the goal of owning everything to do with the apps (and around them) that is not the product itself but rather tools or scaffolding other squads use to build upon.
This way, product squads can focus entirely on the part of the product they are responsible for without getting interrupted if suddenly the login breaks or the database needs a migration.
In practical terms, this means that we own things in three categories:
1. App modules
Those common or utils modules we all have in our codebase are our responsibility. We're also in charge of low-level components like network, database, tracking, settings, and authentication.
We use Codeowners to track this and get alerted of any PR that changes content in those areas.
2. Tools
There are several tools around mobile apps development that require time to maintain and improve. Without a platform team, it’s usually developers taking a few minutes here and there to quickly patch whatever problem arises so they can continue with their real task.
This can work for some time but it won’t let you build strong foundations for a great mobile engineering experience.
In Q3, our squad took ownership of Bitrise (our CI/CD tool). Because we had the time to invest in it, we made several improvements to our configuration.
We also added two more tools to our belt:
- Perfecto: a device farm provider to help us run our end to end tests
- NowSecure: a security assessment provider
During the quarter we configured these tools, the CI jobs to run them nightly and expend time documenting and teaching our colleagues how to use them.
Now every squad knows how to create end-to-end tests for the features they build and have a platform to run them.
3. Processes
There are two processes related to mobile apps development that we now look after:
- The Release Train process
- The Firefighter process
We release the Android and iOS apps following a release train process. If you want to deep dive into what this process is there are many great articles already, like this one from Soundcloud, this one from Skyscanner, or this one from Bitrise. I also spoke about how we run release trains at RockNDroid (🇪🇦)
We also defined how the release train process was going to work for TravelPerk mobile apps. The end result was a runbook document that defines what should happen at each stage of the process.
The process is still quite manual, though. We have several phases and we split the tasks between product and platform within each phase. For example, we manually execute the scripts that create a release branch when the ‘train departs’, and we submit the apps to the stores to begin the staged rollout when the QA phase is completed.
The metaphor we like to use is that ‘the platform squad drives the train and product squads add content to it’
The firefighter is a weekly rotating role. This person is the point of contact for both apps and the first responder for any incident during their designated “firefighter” week. They also need to check both apps’ metrics proactively and raise any potential issues. We also participate in the firefighting rotation as any other mobile engineer.
Owning these two processes means that we are ultimately responsible for making sure they are executed correctly and for adapting and improving them.
After a few months of running release trains, we’ve already identified a few issues in our runbook. Next week we’ll have a first retro with everyone that participated in a release process in the past months to hopefully improve how it runs.
Conclusions
After our first quarter, we’ve seen already great improvements in the mobile engineering practices at TravelPerk. Now we have separated ownership of components and tools between the platform and product squads, our processes for releases, end to end testing, and security assessments are up and running and we have, and we have better app monitoring than ever.
Now in Q4 2021, we are focusing on four big things:
- Identify the main pain points when consuming APIs from the mobile apps and define a plan to tackle those issues
- Automate the still pending manual steps in our release process
- Define a strategy for improving our app’s modularisation to be able to scale the apps smoothly
- Preparing the mobile engineering vision for 2022 at TravelPerk. The mobile platform squad needs are ahead of the curve for mobile engineering. We are solving today’s problems and also preparing for future ones. It’s our responsibility to define where we need to be next.
We’ll let you know how all that went in the next post
If you also have a newly created platform squad in your startup I’d love to know what kind of problems are you tackling and how are you organising yourselves. Leave me a comment down below!
