DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Lyft’s PM: Make the Pain of Mobile Releases a Thing of the Past

Lyft’s PM: Make the Pain of Mobile Releases a Thing of the Past

Golden advice from Lyft on how to create faster mobile cycles. 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.

Kendrick Wang user avatar by
Kendrick Wang
·
Dec. 02, 15 · Tutorial
Like (4)
Save
Tweet
Share
4.41K Views

Join the DZone community and get the full member experience.

Join For Free

David

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?”

Image title

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.

Lyft Cadence Speed

“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?

Train Schedule Board

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

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.

Release (agency) agile mobile app

Published at DZone with permission of Kendrick Wang, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Writing a Modern HTTP(S) Tunnel in Rust
  • How To Use Terraform to Provision an AWS EC2 Instance
  • GPT-3 Playground: The AI That Can Write for You
  • Deploying Java Serverless Functions as AWS Lambda

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: