WIXLIB

For Application Development & Delivery Professionals4Build Five-Star Mobile Apps Retire the QA center of excellence. When it comes to testing mobile apps, traditional testingapproaches are too slow. The need for on-device testing, quick turnaround times, and specializedknowledge makes a traditional QA center of excellence less useful for mobile development teams.In every shop we talked to, the development teams take on responsibility for app testing. Manual,on-device testing was the most common approach, but several companies also deploy earlyversions of apps internally to other company employees or externally to a standing set of betatesters. Deploying beta versions is easy for Android apps — they can be side-loaded onto users’devices. It’s a bit more challenging for iOS apps, as Apple limits developers to 100 ad hoc licenses —but that’s still a good population for gathering feedback. Refocus your sourcing strategies. Some of the companies we spoke with are too small toengage large system integrators — yet their apps are doing exceedingly well in the stores. Theyare doing just fine with smaller digital agencies and hiring freelance talent. The bottom line isthat you’re better off looking for mobile specialists with mobile-specific design and developmenttalent. Specialist firms have already adopted many of the process techniques we’ve describedin this document, so they’re culturally capable of moving fast with a minimum of overhead. Ifyou’ve spent the past few years winnowing the number of firms you work with in order to gainhourly rate efficiency, you will probably need to rethink how you are sourcing developmenttalent to focus on skills rather than labor costs.Figure 1 Cross-Train Developers For Increased Bench DepthShared, cross-team rolesProduct owner/product manager (PM)iOS development teamScrum master/project managerDesign teamAndroid development teamLead iOS devWeb development teamLead Android deviOS devCross-trainAndroid devCross-trainLead web devWeb devCross-train71281 2012, Forrester Research, Inc. Reproduction ProhibitedSource: Forrester Research, Inc.November 7, 2012

For Application Development & Delivery Professionals5Build Five-Star Mobile AppsFavor Simple Development Tools Over Complex ALMWhen we asked our five-star shops what development tools they use to build, test, and deploymobile apps, one thing became crystal clear: They all employ a minimalist approach to applicationlife-cycle management (ALM). With a focus on time-to-customer-feedback, there’s simply not a lotof tolerance for any processes or tools that get in the way. As a result, these shops: Simplify and distribute software configuration management. All the companies we intervieweduse Git or Apache Subversion to manage their source code.4 Why? We heard a common refrain:They are simple to use, and the developers come in already knowing how to use them. With atendency toward faster releases, the need for long-running parallel branching, streams, orbaselines supported by more-advanced software configuration management (SCM) tools becomesless of a need. And with fewer developers, it’s easier for teams to work on a master branch orengage in rapid branching and merging through distributed version control with local repositories. Use visual designs, prototypes, and collaboration instead of textual requirements. We didn’trun into a single development shop in our interviews that uses textual tools for requirementscapture or management. Some shops use a very simple approach, creating bitmap screenmockups with tools such as Adobe Photoshop or OmniGraffle. Others use more-specializedtools for wireframing or mockups such as Balsamiq. They then capture user feedback generatedfrom these visual designs in lightweight change management tools such as Trello and AtlassianJIRA. A number of the teams we spoke with mentioned that they use file-sharing services suchas Dropbox or Google Drive to share screen shots and collaborate on updates. Test apps with emulators and personal devices. One of the biggest differences thatdevelopment teams face when building mobile apps is testing. You can’t simply throw mobileapps over the wall to a separate test group or a QA center of excellence. Not only are mobiletesting tools new and different, but they are also generally more complex. Setting up an Androidemulator or iOS simulator requires installing an integrated development environment (IDE).And simulator/emulator testing is not sufficient; on-device testing remains the best way toassess on-network performance. While cloud-based testing solutions are available to mobiledevelopers, current adoption among the organizations we spoke with is minimal. The currentreality is that teams use personal devices to test beta builds of many five-star apps. Thesedevices may be purchased and pooled by development teams or owned by developers, companyemployees, or trusted beta testers. The development teams we spoke with are interested in abetter approach but also maintain that their current approach to testing gets the job done.“We simulate the app on the computer to get through an initial test scenario. But even so,there are some things we can’t test on the simulator. Every day we run or walk with runensto get real feedback that we send to the developers. It’s the only way to ensure real usability.”(Marcio Cyrillo, VP marketing, Ci&T) 2012, Forrester Research, Inc. Reproduction ProhibitedNovember 7, 2012

For Application Development & Delivery Professionals6Build Five-Star Mobile Apps Use mock objects and back-end-as-a-service frameworks to manage multilayer complexity.Several of the development teams we spoke with use test mocks to model interfaces to theirexisting systems of record. The mock interfaces allow front-end user interface (UI) teams tomove forward on design in parallel with infrastructure teams as they flesh out linkages fromexternal web service application programming interfaces (APIs) to internal system interfaces. Ina similar way, we saw some teams employ a mobile back-end-as-a-service (BaaS) to quickly givefront-end UI developers objects in Objective-C and Java.5 Struggle with continuous integration as development grows decentralized. One recurringproblem we found mobile development shops struggling with is a fractured, immature toolchain. That’s partially due to poor integration APIs in Apple Xcode but also because targetingmultiple platforms requires multiple IDEs and platform-specific languages and deploymentsteps. As a result, most developers simply build their apps in their local Xcode or Eclipseinstance. Some development shops are trying to use Eclipse Hudson or Jenkins to recreate thecontinuous integration loops they’ve been used to, but none of the shops we spoke with reallyfeel like they have nailed it yet.Adapt Agile Principles To Meet The Demands Of Mobile App DevelopmentLet’s be clear: Our research shows that if you cannot implement Agile practices as part of yourmobile app development efforts, you will have difficulty maintaining a five-star mobile app. Sure,you might have a successful initial launch, but if you can’t quickly follow it up, then your app willlanguish, starved for features, or worse — it may stop working when the latest version of iOS orAndroid is released. In the past four years, Android has had 11 releases, and iOS is updated just asfrequently. You cannot keep your customers from upgrading, so you’ll need to plan on a minimumof two to three releases a year per platform just to tread water.Most of the mobile app developers we spoke with release far more often than two to three times a year:“On average, we release four to five times a year.” (Ben Zotto, founder, Cocoa Box Design)“We average about 10 releases a year.” (Bill O’Donnell, chief architect, Kayak.com)“We average a release every two weeks.” (Damien Patton, CEO, Banjo)At these release rates, it’s impractical to talk about using iterative methods, let alone a water-Scrumfall approach. You must be capable of releasing new updates on demand.The mobile app developers we talked to don’t take a dogmatic approach to Agile practices. Several usedScrum or eXtreme programming (XP) as an initial reference point, but they’ve modified traditionalAgile practices and added new ones that are particularly well suited to building mobile apps: 2012, Forrester Research, Inc. Reproduction ProhibitedNovember 7, 2012

For Application Development & Delivery Professionals7Build Five-Star Mobile Apps Introducing the concept of a minimum viable product helps teams get feedback faster. Whenyou’re in a competitive market, it’s tempting to add as many bells and whistles to your mobile appas possible — after all, it’s got to be better than your competitors’ apps, right? Wrong — the morefeatures you add before release, the more time it takes to develop those features. And unless youhave a deeper understanding of your customers than most development teams, there’s a highprobability that you’ll miss the mark on your first shot. Instead, ask this question: “What is theminimum feature set we need to collect the maximum amount of information about customerswith the least effort?”6 Creating a minimum viable product (MVP) allows you to stop guessingand start learning about how your customers are using their mobile devices. Kanban boards help manage atomic demand. At systems integrator Ci&T, a small subteamhas built a highly rated mobile app for runners called runens. The runens team mixes a Kanbanboard with a more-traditional Scrum process because it helps it manage unpredictable demandat an atomic scale.“We use our board as an organizational tool that complements our daily stand-ups. It’s wherewe see things moving. When we first started, our backlog was immense, but as thingsstart to move toward our release, the board’s a visible confirmation we’re making progress.”(Marcio Cyrillo, VP marketing, Ci&T)Mobile app development efforts are often smaller than traditional application developmentefforts, so user stories and epics may prove too coarse-grained for teams to get a feeling of flow.Managing demand at the feature (or even defect) level lets teams further decompose larger workitems while mixing in user requests or defect fixing. Using wireframes helps drive feedback and build backlog. App developer Banjo describes itsdevelopment process as “Agile on steroids.” But there’s one important design step that must takeplace before a Banjo development team starts a series of sprints: wireframing. Banjo useswireframe mockups of app screens with potential users to flesh out basic design concepts andwhat the service should do. After wireframing is complete, the team refines its backlog to answera simple question: “How can we get the minimum viable product out as fast as possible?” Severalfirms we spoke with mentioned wireframes as their primary requirements-elicitation technique. Prototyping sets the stage for broad-brush feedback. Wireframes are a good starting point,but they don’t necessarily capture the realities of touch interaction or the finer points of UIdesign. That’s where higher-fidelity prototypes come into play. Several of the shops we spokewith use mockups of nonfunctional screen images deployed to real mobile devices to assess howusers respond to different designs. The prototypes are “nonfunctional” in that they have no codeand no business rules behind them. What they do help with is screen flow and navigationaldesign. Prototypes answer questions such as, “Should the user tap a button or swipe to the nextscreen?” and “Is an accordion a better interaction design than tabbed folders?” 2012, Forrester Research, Inc. Reproduction ProhibitedNovember 7, 2012

For Application Development & Delivery Professionals8Build Five-Star Mobile Apps“I’m huge on prototyping. We spent about a month creating low-fidelity wireframes for ourinitial iPhone release, and when our founders were comfortable, we moved onto prototypingand then to code.” (Danilo Campos, UI/UX designer and iOS developer, Hipmunk)Prototypes can be used with target customers, but more often than not the shops we talked toexpose prototypes to development teams, business sponsors, or company employees to gatherearly feedback on interaction design. Think of a prototype as a low-cost way to institute ascientific approach to design (i.e., early stage A/B testing). Developers that use prototypes maystart with two different graphical layouts or navigation flows so they can see which one users likebetter. The results refine the design before the team engages in the real expense of cutting code. Personas provide insight into user behavior. Several of the shops we talked to use explicitpersonas to guide their app design. A persona helps answer questions about a user’s mobileapp objectives and can provide clues to appropriate technology decisions. When NatureSharedesigned the Audubon Birds app, it started the process based on the team’s understanding ofhow existing birders use the paper field guide. The team also knew that the app was likely tobe used in the field and that there was a high likelihood that connectivity would be spotty. Thisknowledge of user behavior pushed NatureShare toward a device-centric, native app with alarge amount of content. It also allowed it to put a higher price tag on the app (currently 9.99)because the team felt that the app’s target users would understand that the app provided morevalue than the standard field guide at a fraction of the price. Journey maps add a multichannel dimension to the user experience. Whether they are takingmeeting notes, traveling, banking, or even drinking good beer, customers expect a seamless,multichannel experience. As a result, an increasing number of mobile apps are not standalonebut connected to a larger set of interactions. For several years, we’ve seen leading interactiveagencies map a customer’s journey as he tries to accomplish an evolving set of tasks as partof brand engagement.7 Now we see these design firms extending journey maps to include anelaboration of prioritized digital touchpoints (see Figure 2). A journey map that details when amobile app is a priority engagement channel is helpful in defining a minimum viable productfor an initial release and also in sharpening a development team’s focus on the mobile tasks thatreally matter. Organic release schedules help teams meet user and market demands. Many applicationdevelopment teams try to normalize release schedules — say, one major release a year or spring/summer/fall/winter releases. But in the mobile world, a regular release cadence is almost ananachronism. Think about it: You’re not shipping DVDs or CDs. The user gets proactivelynotified that a new release is available, and there’s really not a strong drive for annual updates todrive support contracts. The mobile shops we spoke with adopt a release-when-ready approach. 2012, Forrester Research, Inc. Reproduction ProhibitedNovember 7, 2012

For Application Development & Delivery Professionals9Build Five-Star Mobile Apps“Our release time is as short as a month and as long as three to four months. It varies basedon numerous factors, such as the complexity of the functions being built or an operatingsystem update. We like to build releases around themes. You also need to consider markettiming. For instance, you want to be wary of shipping a release right before Christmas,because it wipes out user ratings and resets the clock on an app.” (Ben Zotto, founder,Cocoa Box Design)The bottom line is that you should expect and become comfortable with a more organic releaseschedule. One common pattern several companies described is a major release followed byseveral quick follow-up releases, with a longer period of stabilization (see Figure 3).Figure 2 Multichannel Journey Maps Plot Customer Engagement Across ChannelsIdentifycustomerand stagesof ibeeach stepin thejourney; thecustomer’sneeds andperceptions.81114510NeutralMissed mary(andsecondary)devices foreach step.Source: Strativity Group website (http://www.strativity.com/)71281 2012, Forrester Research, Inc. Reproduction ProhibitedSource: Forrester Research, Inc.November 7, 2012

For Application Development & Delivery Professionals10Build Five-Star Mobile AppsFigure 3 Release Schedules Vary Based On User Need And Market FactorsFeatures plusdefect fixesV 2.0V 1.2.1V 1.2V 2.1V 1.2.2V 1.0(minimumviableproduct)New OS version releasedRegression plus emergency patchRegular internal sprint cycle plus beta testing (2 rce: Forrester Research, Inc.Balance Release Speed With An Increased Focus On QualityWith an increased focus on achieving a speedy release, it would seem like a continuous deploymentregimen and a focus on rapid releases would be a natural fit for mobile developers, right? Well, notso fast: We got what seemed like a counterintuitive set of warnings about releasing too fast fromthe development shops we talked to. These shops recommend a cautious deployment approach thatbalances release speed with an increased focus on testing and quality assurance. Here’s why: Initial quality is important because of app store intermediation. Most public app storesmanage the relationship between developers and customers. That’s great when it comes tomarketing and getting paid for apps that you develop, but it’s not so great when you make amistake and a glaring defect slips through your QA process into production. The hard truth isthat you have no control over how long it takes a reviewer at Apple, Microsoft, or Amazon.comto approve your emergency patch, and you have no insight into how long the queue of appswaiting to be approved is. 2012, Forrester Research, Inc. Reproduction ProhibitedNovember 7, 2012

For Application Development & Delivery Professionals11Build Five-Star Mobile Apps“The consequence of putting out a build that fails or doesn’t start for 20% of users is dire. Tobe blunt, you’ll get slaughtered. I don’t put a release out unless I know it’s good.” (Ben Zotto,founder, Cocoa Box Design)It may take a day, but it might take a week or more, and there’s nothing more frustrating thanwatching poor reviews come rolling in when you’ve already fixed the problem in a queued-uprelease.“Before a release goes out, we go through an extensive QA process. We start with a day runthrough of the app manually according to our checklist. Then we install the build on about30 devices. We have people use it for several days and record any bugs/crashes, and there’salso a feedback button to submit any problems they have.” (Damien Patton, CEO, Banjo) Expedited releases are possible — but no substitute for real testing. In spite of thoroughtesting, problems still crop up. At least half the development teams we talked to reported defectsthat affected their overall ratings when they shipped a subpar update. When it was an Androidapp, they quickly spun a new release, and in many cases they were able to get a same-day updatefor iOS apps by asking for an expedited review. While an expedited review may sound like agreat safety valve, be careful. The teams we talked to advised against crying “wolf!” more thanonce a year. Don’t use an expedited release to cover for poor QA processes but as a rare safetyvalve to escape a truly unforeseen problem.The opinions from the shops we spoke with were unanimous — it’s worth it to spend money andtime to make sure there are no huge bugs before release. To balance release speed with app quality: Use mobile deployment and feedback management tools. Several of the shops we talked wi

Design, cynergy systems, Digby, EffectiveUI, Hipmunk, Kayak.com, natureshare, path, Roundarch Isobar, and Untappd. Related Research Documents mobile Technologies That Drive sales August 10, 2012 Build Great mobile Apps That Drive Engagement June 28, 2012 Building mobile Apps? start With Web;