Moving fast is obviously a good thing on mobile, but how do we go about achieving it? Last week, we shared Waseem Daher’s take on why you should make small, iterative changes to your app. In his talk, Daher raised the issue that one of the biggest constraints to using agile methodologies and MVPs was having a slow release cycle. This week, we’ll share insights from Lyft PM David Dryjanski on to create those faster mobile cycles.

“How do we know if we’re moving slowly?”

via GIPHY

“One of the biggest indicators is that a release is like a very special occasion,” chuckles Dryjanski. If you take a look at the version history of most apps today, you’ll notice that updates come in slow, lethargic releases every few months. Contrast that to the top apps in every vertical and you’ll find that those top teams are instead releasing every 1-2 weeks.

Having a short release cycle such as these is vital if you’re trying to make small, iterative changes to improve your app quickly says David. He added that it gives you the ability to react to the market and learn quickly from your users. If and when the competitive landscape changes, new regulation is passed, or consumer demand shifts, you’ll be able to respond speedily. However, changing to a fast release cycle isn’t as simple as just deciding to do it.

“When I started out at Lyft, we had a monthly release cycle. And now today, we release every week.” The change was by no means immediate. Lyft’s transition from a one month cadence to one week didn’t happen overnight. It was a gradual process that they slowly chipped at, decreasing their cycles down to three weeks, two weeks, and eventually one week.

While the process takes some time, Dryjanski identified a few key adjustments that greatly contributed to the success with this methodology and increased their speed.

Shift to a Fixed Release Train Schedule

One of the most fundamental tenets of tightening Lyft’s release cycle relied on created afixed release train schedule. Most companies do feature-based releases on mobile. That is, release dates are decided based on whenever features are completed. Maybe your team does the same. The problem with that is that there’s a great deal of uncertainty as to when the next release is going to go out. Any delay or hiccup can push an entire release back indefinitely.

No one wants to wait and see their feature take months to get out the door. Not knowing when the next release will be, developers sometimes scramble to get all their features and updates in on time, even if they’re not 100% ready. This widely accepted practice can lead to buggy, unrefined code that can crash or ruin the user experience. That’s the last thing you want to do.

Instead, Dryjanski suggests adopting a release train schedule.

What Is a Release Train Schedule?

The “train schedule” part refers to an actual physical train or subway system. Whether you’re onboard or not, trains and subways are going to leave the station at a set time, based on a schedule planned out months in advance. They don’t wait to see if you’re ready to go. If you’re not on time, you can catch the next train. Similarly, release train schedules are schedules of planned releases that happen at regular, pre-planned intervals, regardless of whether or not features are finished and ready to go. Whether it’s just bug fixes or an app overhaul, the release is still pushes forward according to preplanned dates. Dryjanski also suggests making these dates public, so there’s no internal confusion as to when the next releases will be.

Compared to feature-based releases, this method relieves a lot of pressure and uncertainty. Teams know that there’s always a “next train” and exactly when it’s coming. If a change isn’t 100% finished, it’s not a big deal. It can simply go on the next release. As a result, there’s a much greater focus on getting the code right, instead of simply getting it out. When user experience is everything, having this mentality is vital for mobile success.

Fixed is Flexible

Surprisingly, having a fixed release train schedule actually allows for additional flexibility when unexpected issues arise. “Being strict actually gives you more flexibility. In that if you have that high profile request coming, you can put that on the next train.” Instead of dropping everything to take care of a high priority change, current development can simply be postponed to the next release, rather than derailing the entire process.

Make It a Clear Priority

“There’s some companies that don’t want to ship a bug fix only release. They want to ship something noteworthy to users at every update, because it’s risky because they might not update right? You have to get past that, because otherwise it affects your rhythm, and your schedules get off track.”

Moving faster isn’t simply a lone effort. It’s a collaboration that requires buy in from your entire mobile team. Most importantly, it’s a shift in mentality: that it’s okay to ship small changes. Instead of making large feature-based releases, you and your team need to get comfortable shipping unpolished MVPs or simple bug-only releases. Explain to your team about the benefits of moving quickly and the system by which to do so.

Identify a Release Manager

Another key tenet Dryjanski recommended is to identify a release manager. This person will have the responsibility and authority to push out releases and build trust in the method across the entire organization. Don’t worry, you don’t need to go find and hire someone specifically for this. Usually an engineering or product manager can fill this role well. As a champion for this methodology, the release manager needs to get the team and the organization onboard, as well as demonstrate the benefits of tweaking the workflow. Assigning this responsibility makes it clear who to consult on anything release related.

Use Feature Flagging Push Forward with Confidence

Flags give you confidence like George Washington

“Make sure you have the right set of tools that allow you to operate at this speed.”

Most mobile teams have been slow to adopt feature flagging, yet it’s probably the industry that needs them the most. Since the app stores force teams to resubmit rather than revert their apps to a previous state, a major bug can send any team into panic mode. That’s why feature flagging is so vital to success. It allows teams to push forward with confidence.

“You gotta build your features behind feature flags. This allows you to minimize risk when releasing a feature.” says Dryjanski. Feature flags give teams the ability to do staged rollouts and roll back changes, without having to resubmit to the app store. Staged rollouts allow you to have granular control over the deployment process, rather than rolling out a change for your entire user base and praying everything goes smoothly. If something isn’t perfect, feature flagging also allows you to roll back a change immediately, and avoid any major catastrophes.

Feature flagging allows additional flexibility when testing MVPs. That increased confidence is a huge factor for teams looking to move quickly, knowing that they’ll be able to swiftly address any issues their users may face rather than be at the mercy of the app stores.

Wrap Up

There are huge benefits to using agile methodologies and creating MVPs on mobile like Waseem mentioned in his talk. However, doing so requires a vital investment into the infrastructure to make it work.

As David shared, there are four key adjustments teams need to make in order to support this speed. Doing so requires teams to tighten up their release cycle and create a regular, reliable release schedule. Buy ins from the team are vital, and identifying a release manager is important for that. Feature flaggins is also a great way to minimize risk and allows you to push forward confidently.

To learn more about how Apptimize helps team move faster, feature flag changes, and excel in the mobile space, visit our homepage.