Small teams, short deadlines, the importance of usability -- a lot of mobile application traits point to using agile development techniques.
Apple is talking up its new iPhone 4S, just 14 months after releasing iPhone 4, touting a faster chip, voice controls, and hooks to cloud-based storage. Here's a question worth asking: Is your company's application development strategy ready for the blistering pace of the mobile world?
Mobile apps are a different beast from big, conventional enterprise IT projects. They tend to involve smaller teams. They're often (not always) less complex. Usability factors can make or break a mobile app, many of which are built for the end customer. And the deadline to create a mobile app is almost always terrifyingly short, as companies fret over falling behind smartphone-touting customers, and their competitors.
All these factors make agile development techniques a good fit for many mobile apps. I say "techniques" because companies often rely on elements of agile--like iterative development and frequent reviews by business unit partners--without embracing the complete agile methodology. And they often work with outside partners who do the actual development.
Another agile-friendly feature of mobile apps is that they don't need to be perfect out of the gate, says Leigh Williamson, a distinguished engineer with IBM's Rational dev tools division. Mobile developers will commonly put out an app with a limited slate of features and update it with more later, Williamson says, and that process fits with the iterative nature of agile.
"Good enough for 1.0" isn't a mentality business IT shops tend to embrace easily. Guardians of company brands don't do so well with it either, so together project leaders need to figure out--on the fly, during development--which features make the cut and which wait for the next version.
Williamson is seeing enterprise IT shops who had never used agile development experiment with it when faced with a mobile project. When business units decide it's time to build a mobile app, "they set timelines that are typically quite aggressive--six to eight months to get these out in production," he says.
Another fact that favors agile development is that mobile apps are still the shiny new object--everyone is interested, and everyone has an opinion. One of the barriers to effective agile development with conventional enterprise apps can be the short attention span of business unit leaders. Will they put in the time to review work every week or two, for months on end, to make sure the latest code’s doing what they expected?
With mobile apps, "there’s constant stakeholder feedback," Williamson says, since usability is critical and the interest level is sky high. The challenge is likely to be too many conflicting opinions, in fact. But better to sort those tensions out early, rather than when the app is nearly "done."
As my colleague Thomas Claburn notes (5 Questions For Companies Building Mobile Apps informationweek.com/1312/apps), companies with mobile app fever first need a good answer for why customers need an app, and how it will pay off for the company.
Beyond the difficult business strategy decisions, IT leaders face the tough choices about their mobile app dev plan.
How much in-house mobile talent do we need, versus relying on outsourcers? Should we invest in iOS and Android skills for native apps, or bet bigger on hybrid apps and HTML5? Does our team even understand our end customers enough to build apps for them? Do our IT security skills transfer to assessing mobile risks?
And if we needed to deliver a new iPhone app for 1Q 2012, could we deliver?