The Train Leaves in Four Weeks: Facebook’s Model For Mobile Project Management

If you release your mobile app too often, the user might delete it from just being annoyed at having to update it so often (wohoo for automatic updates in iOS7!). In addition, every time you release your app, all the previous reviews are in the Previous Review section, and your current version has no reviews.

Oh, and, by the way, Apple takes about two weeks to review your app, so any bug fix you release will take about two weeks to even get to the consumer. These are only some reasons for why quick-release-cycle agile development doesn’t quite work on mobile.

The Inevitable Cycle

Usually, the opposite of agile often happens. Let’s say the project manages plans on submitting to the app store in 4 weeks. Well, in week 3, new bugs and features come up. Even thought these features were not planned for the release cycle, these features are suddenly a “must-have” because the project manager knows that it’ll take another 4 weeks (probably more!) after the release of this version of the app to get these features to production. And so, the release gets inevitably delayed. And, the closer the app is to app store submission, the more stakeholders suddenly have opinions on what else needs to go in!

Moving out the release day is really toxic for the company. The users don’t get the already working new features and bug fixes for another few weeks. The developers are de-motivated, since it feels like the release will never happen, and of course the project is not shipped on time.

The Train Model

At last week’s Mobile Dev Day, sponsored by Facebook and Parse, I loved learning about how Facebook deals with this problem. They follow the Train Model of project management for mobile.

The train leaves in 4 weeks (every last Thursday of the month), and the bug / feature is either on the train – fully developed and QA tested – or not! And they’re just plain OK that some bugs / features will not make it on the train.

Since some features might be pretty big, and might not be done in 4 weeks, the feature on / off switch is controlled by the server. So while the app ships with some of the feature code, the feature will just be off until the next version of the app is released with the feature fully tested and working.

I really love Facebook’s Train Model. It gives everyone a mission – to get the features out of the door no matter what in 4 weeks. And if they didn’t make it on the train, the next train leaves the station in 4 weeks.

Have you experienced good models for mobile project management? Let me know your thoughts in the comments!

Enjoy the article? Join over 20,000+ Swift developers and enthusiasts who get my weekly updates.

  • Daniel Lu

    Ah the age old issue with project management.

    The question of shipping has always been around, with web development being more of the exception. I think we’ll see this culture shock more as people who started off in web apps transition to other types of development.

    With web apps you have the unique ability to ship at a moment’s notice for essentially zero costs. If we go back to the decade or so, software shipping software meant burning onto a disc, putting that into a cardboard box and sending it off to a retail store. The store would have their own process for distributing to individual stores. So software used to be much slower, and putting out a bugfix release was much harder.

    And now I realize I’ve just started an old grandpa “back in the day” type story… but what I mean to say is that we’ve solved this problem before.

    Holding to an exact 4 week release cycle is sort of on one end of the spectrum. With the other end being a “we’ll ship it when its ready” attitude. Blizzard tends to favor this mentality. Most of the time, the process is more in the middle. But you always have to be ok with some bugs / features not making it in. Otherwise you’ll end up in the state Duke Nukem was in and just never, ever ship.

    How I usually see it done is that as the deadline is approaching, the project manager (PM) will pick out features / bugs that have to get in. Meaning they should hold up the release. Meaning, if they don’t get in, the deadline gets pushed out. Often you’ll start a release cycle with a list of “things that have to get in” and ideally this is the same, but that almost never happens.

    If you start off with a list that can reasonably be finished, the deadline doesn’t have to be moved (yet). Other times, the PM will have to “upper management” right away and notify-them-of or negotiate-with-them-for the pushed back deadline. Sometimes the PM goes back to engineering to get more details or figure out different trade offs before talking to management again. That process can sometimes feel like an infinite loop.

    For larger features, you can always break them out into their own branch if you’re using something like GIT that makes branching easy. Or you can leave the code in, but remove/hide all the entry points into that feature. Thus making it at least theoretically impossible for a use to try and use a half-implemented feature. And I’m sure there are plenty of other ways to turn off features on the client side if you don’t want to use the server as the on/off switch.

    For major releases, plan on needing a bugfix release immediately. Make sure everyone is ready to help out with bugfixes and keep things in a releasable state for a while (a while meaning about a week, but your mileage may vary). Even if you don’t need it, it’s much easier to be ready and in a holding pattern. If it looks like your release is being received well, give an all clear and let everyone start merging and getting things messy.

    Hope that helps!