If your organization has not been developing mobile apps for several years, you’re going to make some major strategic mistakes as you plan your mobile development. And if you’re using waterfall or some other non-agile methods, then transitioning to Agile principles and the Scrum process is a significant paradigm shift. So it’s extremely likely that without professional Agile transition guidance, you will encounter one or more of some common major Agile implementation mistakes.
In Part 1 of this Mobile App Design multi-part series, I covered some design and project management strategy. In Part 2 I’ll drop down a level and discuss some lessons learned through pain and triumph in the real world, and try to boil them down to some Dos and Don’ts. Such as:
- Do choose your platforms wisely
iOS and Android stats and tips that app developers care about and which is more profitable. - Do make quality and working software a top priority
Tips to ensure that developers and Quality Assurance (QA) engineers are the most productive. - Don’t take shortcuts with Scrum
Learn how not to make mistakes with Agile and Scrum. - And much much more…
Do choose your platforms wisely
Contents
I’ll give you lots of facts and figures and supporting evidence for my recommendation here, but first, I’ll just cut to the chase for ya’. You’ll need to build your apps for Android and iOS. And don’t waste your time and money on anything else.
If you’ve been paying attention to the mobile space, it should be painfully obvious to you that iOS and Android own the smartphone market, and it’s gonna stay that way. Blackberry committed suicide some time ago, and Microsoft has never been able to get a mobile OS right after well over a decade and they still don’t get it and it’s just too late for them now.
Numbers that Matter Most
The US market share data from comScore makes it clear – iOS and Android are growing and everyone else has lost. While US share numbers show Android 9% higher than iOS, Android share lost 2% in the last year. However, worldwide Android share numbers are a lot higher than iOS.
 |
| US Smartphone Market Share by OS |
But market share numbers are not what matters for app developers nor are they a good indication of how the platforms are really doing. Many pundits and analysts cherry pick the numbers – and numbers can lie. The numbers that matter most are things like profit share, actual usage or traffic. And especially important for app developers are the real size of the market of potential customers that they can sell to or will use their apps and things like how much do customers spend and costs of development.
Usage Stats
Web usage is one important number for app developers. A source of these stats that is commonly referenced in the press comes from Chitika, an online advertising network that collects web usage stats from ad impressions all over the web.
 |
| Smartphone Web Usage by OS |
Chitika’s April 2014 numbers of smartphone usage puts iOS at 53.1% and Android at 44.5%. With Android market share higher, but web usage higher for iOS, it implies that people use their iOS smartphones a whole lot more than Android users do. And indicator for app developers that iOS users will use their apps more than Android users might.
 |
| Tablet Web Usage by OS |
In tablet usage, a Q2 2014 report shows that iOS tablet web usage share was a ridiculously huge 77%. Making it practically a no brainer for tablet app developers that they should focus on iOS tablet apps first.
OS Adoption Rates
The latest version of iOS, version 7 released in Sept 2013, is currently installed on 89% of devices, according to the current chart on Apple’s App Store support page, last updated on June 29, 2014. This includes all iOS devices that accessed Apple’s iOS App Store.
 |
| iOS Adoption Rates |
The iOS 7 adoption numbers are dramatically higher than the 14% of devices that are currently running the latest version of the Android OS, v4.4 KitKat released in Oct 2013, according to Google’s Android Developers dashboard page, last updated on June 4, 2014.
 |
| Android OS Adoption Rates |
Although it is important to note that Google’s numbers may not be accounting for a large number of Android devices on the street, because they can only account for devices that are able to access the Google Play store via their new Google Play app. Since Android device OEMs can distribute, or not distribute, anything they want on their devices, they might not include the Google Play Store app. For example, Amazon devices use Amazon’s Store not Google’s.
 |
| Android OS Adoption based on Web Usage |
Another source of stats on possible adoption rates comes from the Android smartphone web usage stats from Chitika. Although their stats include only Android smartphones while Google’s and Apple’s numbers above include all devices, their numbers show that Android v4.4 KitKat generated 37% of the web usage.
The other issue that keeps Android adoption rates slow is that distribution of OS updates are limited by device manufacturers and carriers. This huge lag in Android OS adoption rates has been a big problem for a long time.
 |
| Android KitKat OS Adoption by Manufacturer |
Google devices are always the first to get the latest Android version right away, which is why the Nexus devices are the ones I use. So naturally Google Nexus devices have the highest adoption rate of v4.4 KitKat, about 96%. While others lagging way behind – Samsung is at a low 39%. But this year Google, Samsung and other Android device makers are getting more aggressive about fixing this problem.
Profitability
Market share, revenue generated, usage stats, all are interesting and useful to know, but the bottom line is literally profit. App developers need to be most concerned about the profitability of a platform. Profit matters most over everything else. If you ain’t makin’ money, what’s the point ?
As far as the platform players, in Android you’ve got Google, Samsung, Amazon, Motorola and many many more all wrestling for the pieces of the Android ecosystem – hardware, app stores, traffic, etc. On the iOS side you’ve Apple and……. well that’s it. Apple makes it all, and so as far as platform profits go, they earn them all and don’t have to split it up and fight over it. By contrast, in the Android platform space everyone is struggling to make profits, especially hardware players, many of which are losing money.
So in platform profits, Apple wins. In Forbes, Tony Bradley made this observation back in Nov, in his article Android Dominates Market Share, But Apple Makes All The Money:
“Apple made more money than all of its competitors combined, taking in 56 percent of the profit in the mobile device market.”
“The profit data illustrates how Apple’s primary rival is really Samsung—not Android. Samsung made 53 percent of the profit for the quarter. Apple and Samsung combined actually add up to more than 100 percent of all profit for the mobile industry, because all of the other players, like HTC, LG, Motorola, Nokia, and BlackBerry lost money.”
But let’s look at profits for app developers. If more people spend more money on their Apple devices, then that is very good for app developers.
 |
| Thanksgiving Sales from iOS crushes Android |
For example, last Thanksgiving holiday season consumers generated more traffic and spent dramatically more money with iOS devices versus Android devices. I have personally done a lot of work in eCommerce and Mobile Commerce development for huge name brand omni-channel retailers, and so I can tell you first hand from their internal revenue and traffic numbers, that this is absolutely the case. These are big names in retail that everyone recognizes, and their individual experiences mirror the market as a whole.
 |
| Traffic and sales versus market share |
There is a gigantic difference in the profits and customer usage generated, between iOS and Android. As a result, the companies I’ve worked with not surprisingly prioritize their iOS app development over Android. They ship on iOS first, and follow it up later with an Android release. And they also innovate and build it first on iOS, then later for Android. They spend more money on app dev for iOS than for Android. Money talks, and that is why iOS comes first for them. Simple.
 |
| Mobile App Developer Priorities |
But big time eCommerce is not the only type of app, that developers ship for iOS first. Many mobile app developers still prioritize iOS first and Android second. But Android is naturally gaining. As the number of Android devices increases and the ecosystem matures and gets easier to develop for, Android app dev priorities rise.
This TechRepublic article summed it up with this:
“Bottom line: More people are engaged with their Apple devices, and more people are spending money on their Apple devices.”
The real market size of potential customers
Just because someone has an Android device does not mean they are a potential customer of your apps. There are a lot of factors that will determine IF a potential customer can run your app or whether they can even get it.
Some of the factors are:
- Are they running a version of Android that your app is compatible with ?
- Are they using a device that you enabled your app to run on ?
- Can they even access the app store that you published your app in ?
By contrast, iOS is easy – One app store, easy support for multiple devices, most devices are running the latest iOS 7 and the small amount that aren’t, are mostly running iOS 6.
You see, Android fragmentation is a serious problem. When considering fragmentation, some only consider hardware fragmentation – hardware differences of the many many Android devices out there, such as display size, sensors, features, etc. But the fragmentation story gets worse than that. It’s also about the fragmentation in Android OS versions – the device OEM’s add-ons and extensions to the OS and the app ecosystem the devices have been designed to support. For example, one analyst quoted in this TechRepublic article took a rough guess that:
…”less than one third of Android devices are truly engaged deeply with Google’s digital platform”
App Development Costs
Developing for more devices and OS versions will cost more money. Of course it will. More device types and more OS versions requires more design work, more coding, more complexity, more testing, more support. More… So plan accordingly.
To try to minimize your app development costs, you are going to have to limit the devices, screen sizes and OS versions, that you will support. Apple makes it easy because most customers are running the latest iOS version, there are a limited number of device types and the development and app store tools are more mature.
Android will cost more to support the same percentage of devices as you do for iOS, because of the fragmentation and less maturity in the Android market. Hardware fragmentation and OS fragmentation will cut into your budget in a big way. Apple dev tools are more mature. Plan accordingly…
Steve Cheney in his article Why Android First is a Myth notes:
“All of my conversations over the past year…confirm a simple hard reality: building and releasing on Android costs 2-3x more than iOS. This is due to a multitude of reasons: less sophisticated tools, generally more cumbersome APIs, fewer exposed advanced features, enormous QA issues brought on by fragmentation, etc. The rough rule of thumb is for every iOS engineer you actually need two Android engineers—or twice the development time.”
Plan to spend more time and money testing and supporting your Android apps. In my experiences developing both iOS and Android apps, this has all proven true. But I am by no means alone in this experience. Search the mobile app communities and you’ll see many experiences similar to mine. It’s why many mobile app developers still prioritize iOS first and Android second.
In the TechCrunch article, The Fallacy Of Android-First, Dave Feldman , a mobile app entrepreneur, talks about his experience developing for Android first and:
“why Android didn’t work out for us and why you should think carefully before going Android-first”
Learn from Dave’s experience.
“In the year since we moved to Android, it’s become more popular to launch Android-first. And for some products it may very well be the right answer. But consider the trade-offs carefully. We’ll never know how things would have gone had we stuck with iPhone from the beginning. But here’s my guess: we would have launched our beta in April (not July) and our 1.0 in August (not October). We’d be building more functionality in less time. Our UX would be more polished, we’d have fewer bugs, and our addressable market would actually be larger.”
Plan for the Un-Expected
Some hardware fragmentations issues, like screen sizes, are obvious. But some are not so obvious, and you can get surprised at any moment. And if you try to take advantage of the newest hardware, it gets even more complicated because of fragmentation.
In the article On The Future of iOS and Android, Steve Cheney noted:
“Fragmentation continues to crop up on Android in weird ways for devs but now is going to the next level—affecting the ecosystem.”
He gave us this “It came outta no where” example:
…”a friend I know has been seeing a lifecycle bug crash the keyboards on ALL Samsung phones. It’s not an Android version issue, it crashes the app across revs; it’s something non-standard Samsung is doing to Android itself. These are the types of problems that slow down developers and cause them to reevaluate Android support next time.”
Again I suggest, plan accordingly. Go into it understanding all of the issues and budget your time, and your dev and support costs to deal with your reality.
Do make quality and working software a top priority
Here are a few tips to use for both Android and iOS app dev, to ensure that developers and Quality Assurance (QA) engineers are the most productive:
- Use Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD) techniques. These are Agile techniques that tightly integrate development with QA to produce working code faster then meets requirements more completely.
- Use QA automation to make testing manageable and build better software, faster.
- Developers and QA engineers must work side by side – literally. Simultaneously developing automated tests and code. This dramatically increases agility, speed and quality. Essential to a highly effective Definition of Done that produces working software quickly.
- Cross train developers and QA engineers. Pairing them together using TDD techniques will result in better code, faster. And deepen the skills of the entire team and break down the silos that often exist between dev and QA, especially in old waterfall environments and ones still going through an Agile transition or practicing bad Agile.
- Use cloud and local virtual machines and emulators for automated testing.
- Invest in as many physical devices as you can. There are plenty of reasonably priced device options, such as the iPod Touch, iPad Mini, Nexus and other Android tablets.
- Give all of your team members devices. Don’t be a cheapskate, buy everyone a device.
- Run your automated QA test suites on both virtual and physical devices.
- Distribute beta builds to as many end user testers outside of your dev team, as you can find. Distribute your beta app builds with TestFlight for iOS apps and TestFairy for Android apps. In Feb Apple acquired Burstly, the company offering TestFlight. TestFlight is now offered as part of Apple’s iOS Developer program.
- Build user feedback, statistics collection, automated crash and error reporting functionality in to your apps.
Don’t take shortcuts with Scrum
In Part 1 we covered all the great reasons why you need to use Scrum to manage your mobile app dev projects. There are tremendous advantages to using a project management method as well known, as well established and as proven as Scrum. So don’t mess with what works.
 |
| Project Success Rates: Agile vs Waterfall |
Thinking you’re smarter than the worldwide community of Scrum experts, and trying to create your own flavor of it or bending it to fit your old way of thinking, is a huge mistake. Resist the urge to choose a “best of breed” solution – It won’t be a best of anything.
Scrum is much simpler than any breed of waterfall or project management method I’ve ever seen, and I’ve seen a bunch. So don’t over complicate things with baggage from your past. Let it go. Leave it behind. Because if you don’t, it WILL trip you up.
Another important thing to keep in mind is that if you stray from Scrum by adding your own bits, you’ll lose a major competitive advantage, that I covered in the Scrum is a Competitive Advantage section of Part 1.
Taking short cuts with Scrum principles and techniques and cherry picking parts of it to use will result in ScrumBut or Scrummerfall. A highly compromised mess that is worse than a good waterfall process.
Here is a great definition of Scrummerfall and why you should not mess with Scrum, from Aaron Ericsson’s article Scrummerfall: World’s Worst Software Development Methodology.
“Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.”
I’ve seen it over and over and over again.
“We will use Scrum….. But…. We’re different [read: unique, special] so we need to change this and that and the other thing.”
Don’t take this the wrong way, but… You’re not special. You’re not unique. Not so much so that your process needs to be just your’s. And that’s a good thing. Because you can fully embrace a set of principles, processes and tools that have been proven to work for over a decade and there is a ton of expertise in the job market that can help you do it right.
Don’t let yourself get sucked into the “Not invented here” trap. Standards of all kinds, technology and methodologies, improve products and make work better and more fun. Technology standards dramatically accelerate the development of products, just as methodology standards like Scrum, dramatically accelerate product development, the happiness of your teams and the competitive advantage of your organization.
Scrum has seen it all. The creators of Agile and Scrum have been where you are now. And so have thousands of other companies and hundreds of thousands of other people. So don’t make their mistakes. Learn from their experience. There’s a reason why Agile principles are so popular and Scrum is the leading Agile software development framework all over the world.
If you think that modifying Scrum to “fit” your way of doing things, or your organization’s culture, will make it easier – it won’t. Natalie Warnert does a great job of summing up the reasons why you should not change Scrum in her article Why making things “easier” makes them harder: The argument against modifying Scrum:
“The [percentage that] Agile Scrum methods are modified is exponentially proportionate to the [percentage] of extra work, complexity and team stress that results.”
If avoiding pain isn’t reason enough to convince you to not mess with Scrum, then how about money ? If you change Scrum or do a lousy job implementing Agile principles, it will cost you more money, likely very much more. Cost you more money in more time to get things done, in failures that take too long to discover, in lost productivity and lost employees.
Do support your Superheroes – ScrumMasters and Scrum Product Owners
In Part 1 I wrote:
…”to create breakthroughs, you don’t need just great leaders and UX designers…. You need artists !!! You need superheroes.”
ScrumMasters and Scrum Product Owners are your leaders. And great responsibility requires great powers – a useful inverse of this popular quote. They need to be superheroes.
In a nutshell: ScrumMasters are focused on the process and the team. Scrum Product Owners are focused on requirements and ROI. But in mobile app dev, one or both of them needs to also be able to provide the leadership and vision in UX design that mobile apps require, more than anything else.
ScrumMasters need the people leadership skills to bring together potentially competing interests. For example, I did some work for a extremely large wireless cellular company, that everyone would know. And being such a well known household brand, they had a long and deep relationship with a creative firm that developed their branding and advertising. And our team brought the technology expertise. Our common customer were business people. Conflicts between tech versus creative is a fairly common issue in these types of situations and will certainly be in mobile apps.
In that project it fell to me to bridge the significant gaps between creative, technical and business worlds. Language translation between the 3 worlds was a common need – translating jargon, requirements and intentions, handling diplomacy and negotiating common ground.
For background info see the following references that run from basic to more sophisticated:
- Scrum > Roles at Wikipedia.
- Core Scrum — Values and roles at ScrumAlliance.
- Product Owner refined for enterprise scale at SAFe
- Check the book review article I wrote on 3 Agile Scrum Books You Must Own.
- The Scrum Guide by both creators of Scrum, Ken Schwaber and Jeff Sutherland.
- The Scrum Papers by one of the co-creators of Scrum, Jeff Sutherland, and other Scrum Resources at ScrumAlliance.
Don’t micro manage
The Scrum team needs to be a self managing entity to reach maximum productivity. Put an experienced ScrumMaster and an experienced Scrum Product Owner in place. Once you’ve built the team, get out of their way. Don’t let people and agendas outside of the Scrum team interfere with the Scrum process.
The Scrum process provides more than enough opportunities for change. Change from customers, from executives, from end users, from everyone. The change is very well managed through the Scrum artifacts and events like the Product Roadmap, Product Backlog and the Sprint Reviews. So don’t let anyone micro manage the process or the team.
Do get serious about top down management support for Agile
I’d like to be able to tell you that transitioning from waterfall to Agile is quick and easy. Sadly it’s not. It constitutes a wholesale shift in thinking. And so it will encounter major cultural and organizational resistance. So you’ll need to get serious about the top management fully supporting the Agile transition in not just words, but actions and dollars.
If your management doesn’t get it, you’re gonna be in big trouble. BIG trouble. And running a team using Agile, in stealth is fraught with danger. Because a waterfall culture will always screw up an Agile team. Waterfall and old school project management principles are in direct conflict with Agile principles and practices. Ignoring this reality is foolish. And so it can only result in failure.
I’ve see it and heard it over and over about bad Agile, people’s unpleasant experience with an environment that claimed to be Agile. And on further analysis I uncovered this is always the root cause.
Here is how devastating the lack of top management support can be. I was involved in an organization that was a big proponent of Agile principles and the Scrum framework. Like many organizations, they were having transition challenges, but were on the right track because the management at the time supported Agile. Then, new executive management came in. Who claimed to know Agile, but it quickly became obvious that they only really knew bad Agile – ScrumBut, Scummerfall. And their mindset was stuck in old school ways and waterfall thinking. It didn’t take long for that to creep in and corrupt all of the progress that the organization had made towards Agile. This naturally upset the engineering talent a great deal, and a brain drain began very quickly because of those few new clueless executives. It was sad. But a lesson, that it only takes a few bad apples at the top, to destroy so much.
Don’t be a cheapskate
 |
| 3 Agile Scrum Books You Must Own |
As with most things, with Agile you get what you pay for. So don’t be a cheapskate. Make an investment in your people and your future.
If you’re not fully versed in Scrum then start here with the ScrumAlliance. Get your people trained and certified in Scrum. Get everyone some books on Scrum. Don’t nickel and dime it. This will be the most important investment in your success, that you will ever make.
Get experienced and trained ScrumMasters. And get your teams a Scrum Coach to help with the transition and provide the guidance essential to achieving maximum agility.
Do take the requirement of having a Scrum Coach seriously
Sports teams wouldn’t think of trying to win without a coach. Same principle here. If you want to be successful with Scrum, you need a Scrum Coach.
The role of the Scrum Coach is to support your Scrum teams in following the process and dealing with the inevitable questions and challenges that will arise. The coach can support multiple Scrum teams and participates in Scrum activities to observe, provide guidance and answer questions about Scrum. This is even more critical when you’re transitioning from waterfall. People will naturally start to fall back in to old bad habits, and the coach is there to re-enforce and support the new better Scrum habits.
Don’t over load ScrumMasters with too many projects
The Scrum process principles say that each Scrum team should have their own ScrumMaster. This is ideal, but sometimes might not be possible because it’s difficult to find good experienced ScrumMasters and it costs more. I do not recommend it, but if you must share a ScrumMaster between more than 1 team, then be very very careful not to overload them. A good rule of thumb is to not exceed 2 to 3 Scrum teams per ScrumMaster.
Do fully commit Scrum Product Owners
Same principle above for ScrumMasters, also applies to Scrum Product Owners. The Scrum team needs a lot of interaction with the Scrum Product Owner in order to get the customer’s perspective. But sometimes when transitioning from old ways of doing things, a conventional Product Manager or Business Analyst might be pushed into the Scrum Product Owner role and not be able to give the team enough attention.
If your Scrum Product Owners don’t give the Scrum teams their full attention it will result in delays and less agility. Because they are not available to clarify requirements in stories and review story results to determine if they are done, in a timely way.
Don’t split teams
Don’t split your Scrum teams across locations or projects. All Scrum team members should be colocated in the same office space. And all Scrum team members should be dedicated to only 1 project at a time. Not shared across multiple projects. Only 1 project should be the priority. If everything is a priority, then nothing is a priority.
 |
| Project Success by Team Distribution |
These are some of the fundamental principles of Scrum because it produces the best possible results. Creating working software faster, with better quality and with higher customer and team satisfaction.
Each Scrum team should have all of the skills needed to be able to bring a Story (requirement) to Done. So that means development, Quality Assurance (QA), UX design skills should all be on the Scrum team and 100% dedicated to solely that team and that project.
For example, I did some work as a ScrumMaster and project manager for a very large well known omni-channel retailer (eCommerce and brick and mortar stores). They would often take a single software development project and split the work effort between multiple teams, vendors and across several very distant geographies. It was the perfect storm of what not to do.
The results were horrid. Silos between teams and sub-teams. Information sharing suffered tremendously. Bugs and issues that would take days, or sometimes weeks, to resolve, that should have taken hours. Sprints that would not be completed within the time boxed 2 weeks and would remain active for weeks after. Work tracking systems that would not get updated and so they could not be relied on for reporting, status and planning. Just complete chaos.
Do keep it simple
One of the principles responsible for the tremendous success of Apple and Steve Jobs was simplicity. In his book Steve Jobs, Walter Isaacson talked about How Steve Jobs’ Love of Simplicity Fueled A Design Revolution. Simplicity has always mattered in product design, but in mobile it matters more than ever. Isaacson has written a lot about Jobs and runs the Aspen Institute.
In apps, simplicity expresses itself in the User eXperience (UX) design. UX design is the most important thing you will do in developing a mobile app. Apple and Steve Jobs provide us with the best examples of design and simplicity and this topic fills books and books. So the best thing I could do here is tell you to try to follow Apple’s example.
There’s been a very recent burst of press and coverage about Apple’s design geniuses. That is very uncharacteristic of Apple, so it’s quite significant. Apple’s Senior Vice President of Design Jonathan Ive and industrial designer Marc Newson were interviewed by Vanity Fair and Charlie Rose back in Nov. A book titled Jony Ive: The Genius Behind Apple’s Greatest Products also published last Nov. By The Sunday Times in the UK last March, which was also covered by Time magazine. The New York Times and another with Bono this June.
Do outsource, if tech is not your core business
Mobile is complicated. I’ve worked in tech a long time, and mobile is the most complicated tech ever, because in order to be successful it requires more talent and expertise than anything else before it. It’s not just about tech expertise. It requires a great deal of design and creative expertise too.
Even just the technology expertise alone can be complex with many mobile apps. Requiring not just mobile app dev skills but also expertise in cloud, SaaS, networking, massive scale backends and more.
So, if your business is not tech, then don’t try to build it yourself. If your business is retail or biotech or finance, you wouldn’t build your own building or car or computers. You’d buy from or hire a company that makes that their business and therefore has the deep expertise needed to be successful and build great things. Mobile app dev should be handled the same way. Instead you should focus on using the tech to make your core business more competitive. Don’t try to build the tech yourself. Outsource it.
Do invest for the long term
Most mobile OSes get a major update every single year. Apple, for example, has released a major new version of iOS and devices every year. Android is not as consistent – OS releases are about yearly, give or take a few months depending on release. New devices and OS versions are released very frequently, and recently the Android marketplace seems to be moving towards a 9-12 month cycle. And every new OS and device has added a lot of new features and put new demands on mobile app developers.
Apple ships new hardware each year at about the same time, and the new iOS version is designed to take full advantage of them. Requiring mobile app developers to update their iOS apps. As a small example, iOS 6 released in Sept 2012, added support for the iPhone 5’s larger display size. And iOS 7, also released in Sept in 2013, added support for the 64-bit A7 processor and the new M7 motion coprocessor in the iPhone 5s and new iPad Air.
In addition to taking advantage of new features and hardware, mobile apps must also be updated to ensure compatibility with the newest OS version. Apps must be tested constantly as new minor updates of OSes are released throughout the year.
Here’s an example of the trouble you can get yourself into, if you don’t invest for the long term. I did some mobile project management work at a very very large company with a global presence. They had made a huge investment in Apple mobile tech over several years and had deployed many tens of thousands of iPhones and iPads world wide, and developed nearly 150 mobile apps for iOS for internal enterprise use by employees, deployed through their own enterprise app store. It had grown pretty organically, with no enterprise level guidance, until enterprise mobile teams were finally put in place.
So while we were preparing the enterprise for the next iOS release, we needed to have the many disparate mobile apps tested, updated and confirmed compatible with the new iOS. What we discovered, as we tried to track down the owner’s of the apps, was that in many cases no one really “owned” the app. And what was worse, that there was no process to keep track of who owned which apps and not even a process to retire an app when it became obsolete or no longer functioned with a new iOS.
Even with apps that had owner’s, many of them had not budgeted any money to pay for the app updates that would inevitably be required every single year until the app was retired from the enterprise app store. Most of the app owner’s were managers in non tech business management roles. So they were surprised by the notion that mobile apps needed constant maintenance.
This was a company that was highly de-centralized, which in business is usually a very good thing because it brings critical decision making down to the front lines, in the country and market that the unit operates. But in this case they forgot to recognize that this was an area that needed the support of a core team of mobile tech experts, that could guide and support the de-centralized business units. So there was also no budget to fund this from a central unit either.
Don’t let this happen to you. Recognize, plan and budget for the long term. Take ownership for your apps until you retire them. And budget for maintenance, fixes and upgrades to keep it compatible with the constant stream of new mobile OSes and hardware.
Coming Soon, Part 3: Design Principles for Tablets and Phones
I’ll follow this article up with a part 3 that will focus on some high level design principles you should follow when designing and developing mobile apps for both tablets and phones.