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!