Running an Effective Mobile Team, Part 2: Creating Predictability

Predictable. The team has a regular cadence. They can set goals and expectations around deadlines.

Challenge: Shipping compiled code.

Most advice about improving team velocity talks about continuous delivery. Ship constantly! As many times a day as you call! Roll back if you need to! Tell us about that time you broke prod! YOLO!

Here’s a fun story about a simple mistake on an iOS build. An early build of the – much anticipated – GMail for iOS broke notifications, popped up error messages constantly, and had to be pulled from the store. I worked next to that team at the time (had worked on that team, even), and I remember it, viscerally.

That was 2011, and things have improved since then. We have better Continuous Integration, and we know which build is signed with what certificate. The app store has improved, too, and wait times are shorter. You can expedite an emergency bug fix. Google Play even has staged rollout (how did we live without that?) although iTunes still doesn’t. You cannot rollback an app in the iTunes store, or on Google Play.

With auto-update, it’s easy to think that everyone gets the latest version. This is not true. People can turn it off, be selective about what they update, or go several days without connecting to WiFi. We have to remember that the typical tech worker on their high end device with fast internet at work and at home downloading the latest new shiney is not our typical user.

The worst case scenario has got less bad, but ultimately, remains the same. There is no “lol that time I broke prod for 2 minutes!” story. There is a frantic patch and test and release and impatient waiting and in the time that takes, the vitriolic reviews from users you would never otherwise hear from. Reviews that insult everyone on the team and suggest you all need to be fired (genuine paraphrasing from reviews I have read about things I have worked on).

One small mistake. Several hours to fix. Months of trying to rebuild your star rating.

A regular release cycle is the core of a predictable mobile team.

However this is not just about the decision to release on whatever cadence – but everything that goes into it.

How do you build confidence in that release?

What is your automated testing like? This will catch bugs as you write them.

Do you have manual QA? Is it thorough? Do you ever find bugs that should be caught in QA? This will catch bugs after you wrote them, but you want to be confident they are caught before you release them. It’s great for discovering weird User Experience edge cases that happen with humans (but not so much with automatons). Tell them ahead of time what’s coming up so they can think about how to test it (and look out for it).

Do you have internal users? Do they actually use the app and tell you about their experience?

Do you have beta users? Do you communicate with them?

Can you commit to the release train?

The thing that will most easily derail your release cycle is trying to stick things into it because you don’t want them to wait until the next release. This is why an effective release cycle is 1) short and 2) rigid.

Short because people are more willing to wait if they don’t have to wait long.

Rigid because patching things in and hoping for the best will result in a delayed and buggy release. You might get away with that once or twice, but not every time, and ultimately breaking those rules undermines them.

Finally, you also have to be willing to kick things off the release train. Feature flags help with this, but ultimately you need to be willing to say about the feature that’s causing problems in the alpha (and FSM-forbid, the beta) this is not ready to launch yet; it will have to wait until the next one.

Perceived Velocity

A common complaint about mobile teams is that they are slower. Mainly this is not about how the writing of code is slower, but that the releasing it to the world is. Even with a rigid two week release cycle, code can be around for up to a month before it goes out in the world. A PR review takes a little longer, it misses the train and voila… two more weeks to go.

A regular release cycle means you can communicate when those changes will be out in the world. A regular release cycle means that leadership (and users!) see improvements regularly, even if it’s not their pet one – yet. They know it’s coming.

Deadlines Goals

I don’t really believe in deadlines. I believe in prioritization, scope, and regular releases.

But I do believe in goals. An effective team can set themselves goals – and meet them.

It’s hard to achieve goals surrounded by chaos, which is why the rhythm of a regular release cycle helps.

Beyond that, prioritizing – what is most important and why? And scoping – what is a unit of measurable improvement? Go a long way.

These are not rocket science. But they require much of the same discipline required to make release cycles regular. A commitment to the realistic, and a willingness to say no.

Read the next part, on setting priorities.