Scrum is an agile framework in which people address complex, adaptive problems while productively and creatively delivering the highest possible business value.

However, using Scrum for mobile application development can be difficult due to various challenges that exist when building mobile applications:

1. Environmental dependencies: Issues inherent to mobile development often halt sprint progress. For instance, applications written using the iOS or Android emulators may crash when they are tested on real devices; using a virtual desktop infrastructure (VDI) on Windows to develop Android and iOS applications on a hybrid mobile application development platform (MADP) can allow you to debug Android code but not iOS code; and emulators often crash due to insufficient RAM.
2. Platform limitations and troubleshooting: Sometimes the team spends lots of effort in requirement grooming and designing a feature that might not be fully supported by the MADP used by the organization, and this eventually compromises the user experience and the functionality. In other instances, plug-in issues pop up and necessitate raising a ticket with MADP providers for support; proxy settings don’t white-list the specific MADP links, leading to IDE issues; and existing mobile applications throw errors when upgraded to the new MADP versions.
3. Unplanned service outages: In a client-server model, when a host server goes down abruptly or the back-end team brings it down deliberately, mobile developers cannot log in to the mobile application or access specific web services, which halts sprint progress.
4. Ownership and access issues: When a team doesn’t have access to the back-end systems that communicate with the mobile applications for debugging or testing purposes, there are frustrating waiting periods that impact productivity. For example, a credit card must be added from the back end to test a particular module of a banking application, but only client SMEs have the access to do so, so the team has to wait.   
5. Sprint duration: Sometimes a sprint is too short to deliver any concrete value amid a volatile environment and dependencies. This impacts the team’s morale and their confidence in the upcoming sprints.

Here are some tips for overcoming these five common mobile application development issues when using Scrum.

1.  Know your development platform beforehand

It is important to examine three aspects of your MADP before the start of your project: whether it is able to support the proposed business functionalities; how much of a dependency on the MADP provider exists day to day, so troubleshooting time can be factored into sprint planning; and what support channels for your MADP providers exist and how timely of a response can you expect.

Architects and senior developers should ask enough questions during backlog refinement meetings to clarify any gray areas related to the MADP that might impact the accuracy of estimates. If some issues are still unclear, teams should consider creating spike stories to identify possible MADP solutions before committing to delivering associated stories.

To learn from others’ experiences, teams should also consider reaching out to a Mobile Center of Excellence or mobile development teams on other projects to understand their best practices, major challenges, and proven ways to troubleshoot MADP issues. Also document your experiences too, so other teams can learn from you! 

2. Focus on technical excellence

Striving to adhere to the agile principle of technical excellence helps teams understand how to best use mobile technology beyond the front-end application.

For a new MADP, consider additional factors for rapid development, such as:

• Using mobile as a back-end service (MbaaS) middleware, which helps in quickly writing the services independent of the host servers and enables reusability of these services across mobile operating systems
• Exploring open source platforms for development to remove dependencies on particular providers
• Leveraging cloud-based solutions that give access to multiple real devices for testing and may save time on operational aspects

Also, get all the access permissions in place for different user profiles you need for development and testing on mobile platforms. Create a task to track progress of getting this access and discuss the status in the daily scrum. Involve leadership quickly when necessary access is not granted in a timely manner.

Finally, arrange access to test your mobile applications on real devices as early as possible in sprints. Even if you perform unit testing with emulators, try to rerun these tests on real devices before proceeding to your end-to-end testing for system integration and performance. This approach will greatly ease debugging during end-to-end testing, as any unit level issues should already have been removed. 

3.  Empower the team

Enable teams to take on day-to-day mobile application development challenges in each sprint. 

First, add some experienced MADP staff to the team who can help troubleshoot intermittent and common issues, mentor new team members on mobile development best practices, and provide necessary collaboration with your client and customer SMEs on requirements and designs.

Also, determine your strategy for testing mobile applications on multiple OSes and devices.

There are often many options for performing various testing activities that need to be discussed and agreed on. For instance, can a mobile application for iOS be effectively tested on a Mac virtual machine via the Windows VDI, or is a separate Mac VDI necessary? As emulators can consume lots of memory, make sure appropriately configured test machines are properly set up and available in order to avoid mid-sprint issues.

Finally, make sure you do regularly scheduled retrospectives to discuss processes, the problem areas encountered, and what new techniques, tools, and approaches can be tried to improve productivity and reduce costly delays sprint over sprint. 

4. Be pragmatic at the beginning

Considering the volatility involved in mobile application development, the team should avoid making big commitments to deliver too many features or value in early sprints.

Instead, factor in time for research and development, ticket response from MADP providers, environment installation and setup issues, and possible process delays to draft, and then adjust a realistic sprint goal. In a true inspect-and-adapt style, set time aside up front for exploration to find the best course of action for mobile development and testing platforms before committing to delivery goals.

The ScrumMaster should maintain a RAID log to keep stakeholders posted about early sprint mobile device issues that are impeding productivity. An updated RAID log gives an understanding of the status of sprints to the stakeholders so they can set realistic expectations and not get surprised.

New teams that haven’t dealt with mobile development before may struggle to deliver value if the sprint is too short in duration. Consider adjusting the amount of time for upcoming sprints if the team thinks that will help them as they learn to estimate mobile development accurately. I think it’s a good idea to start sprints with a three-week duration and then reduce or increase it by one week accordingly, after evaluating various aspects in the retrospective meeting. 

5. Collaborate constantly

The biggest success factor in mobile application development is the amount of collaboration required at different levels.

When faced with tough business competition, aggressive timelines in go-to-market strategies, and the team’s inability to deliver concrete value in the first couple of sprints, set proper expectations with the customer so they don’t go into “escalation mode” early in a project, as this will impact the team’s morale. It is the ScrumMaster’s job to keep product owners informed on all delivery challenges and engage leadership quickly when there are unresolved issues.

Teams must also collaborate frequently with their MDAP provider and any third-party vendors to resolve issues quickly. Seek dedicated and direct channels or points of contacts with those who are responsive to keep issue resolution rolling. Timely support from any IT operations group associated with your middleware and back-end infrastructure is also critical. They can help resolve VDI slowness issues and get any internal access approvals done quickly.