The Problem With Sort Of Doing Agile Mobile Development

Agile development combines process, technology, and mindset in a deliberate way. If you neglect any one of those three pillars in mobile development, you’re setting yourself up to fail. “Sort of” Agile just won’t work.

 

Here’s why: Mobile users and desktop users have very different expectations. On desktop, if your website has low-priority defects, users won’t abandon you immediately. They don’t demand fast, continuous improvements. On mobile, users are far less forgiving. 

 

People run mobile apps on the move. The need is always urgent (in their minds) and their purpose is usually focused. If your app has any issue, be it latency or random crashes, you will hemorrhage users. Why would they depend on a flawed app when alternatives are a few taps away? 

 

Mobile apps also have less features than their web counterparts. An airline’s app might have 20 features that help people book flights, while its website probably has 100, or more. Do the math: If one feature out of 100 fails, it’s not the end of the world. If one feature out of 20 fails, the app store reviews will get ugly real quick.

 

Because mobile users have higher and different expectations than desktop users, you can’t cherry-pick Agile principles and expect good results. Agile process, technology, and mindset work in concert to meet mobile expectations. 

 

 

Mobile entails shorter life cycles. Apps are a dime a dozen and retire fast. You could identify a need and then test and deploy an app within 24 hours using public APIs. New mobile devices and operating systems come out every 12 months or less. Thanks in part to these extremely short product life cycles, mobile demands shorter development cycles. 

 

In the desktop world, quarterly releases are standard. In the mobile world, we strive to deploy new versions in two-week or shorter cycles. However, Scrum teams can release as often as daily, or less often, depending on customer desires. In other words, you can choose an interval that makes business sense.

 

With a quarterly cycle, you might get away with sloppy Agile and still hit your deadlines. With mobile, the sloppiness will prevent you from hitting two-week cycles. You’ll disappoint mobile users, many of whom provide continuous feedback (which is publicly available for all to see) and expect immediate fixes.

 

I’ll share a common example of a busted process. In the transition from desktop to mobile, development departments often fail to organize into Scrum teams. In a desktop process, the dead weight of a big team matters less because you’re already moving at a slower pace. In mobile, big teams miss deadlines. 

 

Agile process demands small, three-to-nine-person Scrum teams that can move, communicate, and build together. If you have more people than that, you can organize them into multiple Scrum teams. The Scrum Master and Product Owner do not contribute to this nine-person ceiling (so the ceiling is eleven if you include them). In terms of team sizes, think Special Forces versus infantry.

 

Collectively, these differences in process mean that every aspect of mobile development moves at a quicker pace and over less predictable terrain. You will almost certainly find problems during testing. 

 

 

Automation is integral to Agile mobile development in a way it is not with desktop development. 

 

In a typical “Agile” desktop development, there’s usually one code base. Everyone writes separate code, coordinates the merging process, and then moves it all to a test environment. The team writes fixes, merges again, tests, and goes to production.

 

With mobile Agile, developers write, merge, and test code on an individual basis, many times over. It’s called CI/CD: Continuous Integration/Continuous Deployment. It requires a cloud platform like Sauce Labs, which automates the testing process.  (Note: I recommend CI/CD for desktop and web development too. Many organizations deploy CI/CD best practices in all their development to improve speed and quality)

 

Automated testing is essential because mobile apps have to work across all potential combinations of devices, OS releases, and hardware, all of which change constantly. Regression testing is the most crucial part. If you want to introduce a new feature, you need to be certain that it won’t break your 20 existing features. Manual regression testing across that many combinations takes too long in two-week cycles. 

 

 

Many companies adopt Agile process and technology, mistakenly believing that will be sufficient for mobile development. That leads us to the third pillar, mindset. Companies underestimate the importance of the Agile management mindset, and the way it clashes with middle management thinking.

 

Middle managers worked hard and climbed the ranks to a position from which they can give orders. They feel they’ve earned the right to command. But Agile development can’t function without changes in the distribution of responsibility and authority. 

 

As Agile teams self-organize their roles, some power transfers into Scrum Roles and away from functional or departmental managers, who will focus more on strategic issues and save tactical issues for the teams. The members need a manager to facilitate and coach the process, not give orders. 

 

In companies that adopt Agile without Agile management philosophy, middle managers can hijack the process. Uncomfortable with uncertainty and self-organization, they spend a whole month planning and gathering requirements. The Waterfall model creeps back in. If the manager’s plan has flaws, or user demand changes, team members don’t have the authority to pivot.

 

Middle managers feel they need to control what individuals are doing so they can hold people accountable. In reality, Scrum teams take responsibility collectively and deal with accountability on their own. Managers need to give up the perceived sense of control and learn to trust their teams.

 

 

In Agile mobile development, gauge success by your pace and use a workflow tool like JIRA Software to track and manage results. Strive for two-weeks cycles and examine what you accomplish in that time frame. How many builds do you run between each release? How many tests do you execute? How accurately do you predict the length your development cycles? An effective organization has a high number of builds, a high number of tests (because they prevent errors), and a high level of predictability. 

 

Agile mobile development and Agile-ish desktop development are two different species. If you want to compete on speed and quality with the world’s leading tech companies, you can’t “sort of” do Agile. You must be as fast and relentless as mobile users are impatient and unforgiving.