A product team’s success highly dependent on its iteration speed—how quickly it can get changes in front of its users and respond to their feedback.

Web developers are used to shipping new versions of their work to customers multiple times per day. In mobile engineering, the process of getting a new version of the application into the hands of Android and iOS customers is much more often measured in days. Hence, most mobile shops use the concept of a release train to ensure that development can continue while a release is in progress.

How does the release train move? How frequently and when should it depart and reach its final destination? What are the constraints that slow it down and what levers can be pulled to enable it to arrive faster?

This is a story of Slack’s recent experiment with moving to a more frequent release train schedule—a process that involved listening to engineering teams and distilling their hopes and fears into success criteria, instrumenting the release process to gain a full understanding of bottlenecks, optimizing release automation to enable moving faster and, finally, tracking the success of the experiment.

It will be especially informative to developers who (like me, until recently) haven’t been involved in the release process of your mobile application.