Why do mobile projects fail? !

!Matthew Langham

!Indiginox GmbH

Warning: There is no source code in this presentation!

Why do mobile projects fail?

!Matthew Langham

!Indiginox GmbH

Warning: There is no source code in this presentation!

STILL

Short answer

Because it’s harder than it looks!

!

!

!

Thanks and enjoy the beers coffee!

http://www.flickr.com/photos/cameronparkins/3220496811/

Matthew Langham

• Co-Founder - Indiginox GmbH

• Independent enterprise consultant for Mobile strategies

• Technical project management for Mobile operator and corporate customers

• Visiting Lecturer for "Mobile Engineering” - University of Applied Sciences - Münster

• Author & Speaker

• matthew.langham@indiginox.com

• @silentpenguin

Goals of this talk

• Pin needles into the map of mobile project development to provide you with some “focus points” for your own projects

• Provide some insight into things that can go wrong and how to improve them

• Yes, some of it is “trivial” and not just mobile related

• But all the following has really happened (to me) in a mobile project

So, why do mobile projects fail?

• Of course - for the same reasons other IT projects fail ...

• Too little stakeholder involvement

• Poor or unrealistic requirements

• Unrealistic time scales

• Scope creep over the development period

• No management of change control

• Quality assurance

But often ..

“No matter what they tell you, it's always a people problem.”

Gerald Weinberg (The secrets of consulting)

Why mobile projects don’t usually fail

Because of bugs in the app

These have been identified and can be fixed

Additional challenges

• Challenges affect the different phases of a mobile project

• Conception

• Finding resources

• Implementation & Testing

• Deployment

• Business

Eric Schmidt (Google) said: “Mobile First!”

!

I say: “Think First!”

The biggest mistakes are made before a line of code is written

Conception phase

http://www.flickr.com/photos/mukluk/174688752

Do you know what you’re doing?

• Starting the project without understanding what you are dealing with can be deadly

• “We’ve bought 500 iPads - and now we need an app!”

• “We need a native app for iPhone, iPad, Android, BlackBerry - oh - and Windows Phone”

• “Have you thought about a cross-platform Web app?”

• “huh, what’s that?”

• “Our budget is xyz € and we need two apps that work on both iOS and Android finished by the 1st of December - can you do it? We haven’t completed the requirements list but we know someone who knows someone who did a prototype in 5 days”

No, seriously, do you really know what you are doing?

• Is (some of) the core functionality even allowed in the country you want to roll-out in?

• Legal implications such as data-protection, sharing of media, allowed content etc.

• Is (some of) the core functionality even possible on one of the platforms you are targeting?

• What are your key differentiators?

• Are you sure you aren’t just building a “me too” app?

• Have you asked your users what they want? Maybe you just need to make your Web-site mobile-ready?

Are you sure?

• Remember - if you are working in the mobile space then you are probably not representative

• Use-cases

• Devices (shiny and new)

• Operating system

• The newest and the bravest

• Networks

• LTE vs. 3G vs. 2G

Are you sure?

• Functional requirements from people who don’t understand the technology

• “Build a mobile HTML 5 widget game that is just like ‘Need for Speed’”

• “Build an Android Facebook home-screen widget for this low cost device that is just as fast as the native app on my high-end device”

• “The key proposition of the iOS app is to back up data in the background”

• That was before iOS 7

• “I want my App store to launch with 1.000 Apps!”

How much time do you have?

• Typical way a project is defined in a large corporation

• Product Management / UE

• “We want an app that provides roughly this functionality. We haven’t actually thought things through yet but you get the idea - right?”

• “We’ll start working on the requirements right away and get the wireframes done. Shouldn’t take long.”

• “Oh, by the way, the release date is in 14 weeks, that’s plenty of time for you to develop it.”

• QA

• “Well, we will need 4 weeks to do the testing cycles at the end of the project. Lots of countries, different networks - that takes time”

• In the end it took 6 weeks for the requirements to be defined which left exactly 4 weeks for the implementation

Pro-Tip: Never trust someone who wants to dictate a project’s deadline and scope at the same time

Requirements documentation

• Wireframes

• Requirements document

• Use-Cases

• Which tool?

• Jira, Confluence, Word, something else

• However you decide to document your requirements

• Make it easy for the developer to understand what you want

• Do not link things together (e.g. Jira issues pointing to Confluence pages that point to Sharepoint where the UE spec is stored)

• Developers won’t read pass the first page

• Don’t change things silently without informing the development team

Silent requirements

• Silent requirements are those discussed informally in meetings or at the water-cooler

• Rarely documented

• No-one is able to remember them a few months later

• They will come back to bite you

Change Management

• In long-running mobile projects changes will happen (you had better be prepared)

• New versions of the operating system

• New devices

• New “ideas” / Hurdles for implementing old ideas

• Team fluctuation

• Establish a change management process as early on as possible and make sure the implications of changes are clearly communicated

Are you being over-ambitious?

• Way too much work is done before sanity checking

• Defining a scope for the version that is way too large to be implemented by the team

• Defining functionality that cannot be supported by the platform you are targeting

• Defining, specifying and designing the client before checking if the needed backend APIs are actually available

• Yes, this really happens :(

• Iterate!

The challenge

How can we educate all project stakeholders so that they know enough about the mobile technology to make informed decisions?

The perception challenge

Perceptions

“The Product Owner has no idea what the product should be doing and he doesn‘t understand how difficult it is to do all that on Android”

!! “The developer doesn‘t share my vision for the product

and he isn‘t providing me with alternatives or solutions“

Self-Perception

Self-perception of a developer can be either: ! Overcautious: Won‘t change anything without spending a week looking at

the code and complaining that it really is too difficult to touch ! Over-enthusiastic:

!“I want to change A to B“ “Are you sure changing to B won‘t cause side-effects?“ “Absolutely“ !Then spends following week fixing side-effects of changing to “B“

Repeat after me: “GitHub is not a communications tool” !Too many discussions carried out via commit messages

!And neither is Skype!

!If you are sitting 5 Meters away from the other person

Communication

Communication

Getting developers to actually TALK to each other is the single most important thing you can do to improve the development project

! Regular standups can help If you are the project manager then look-out for the

tell-tale signs of bad communication

Communication

Be careful when mixing developers and product managers into the same meeting

When a developer says something is “unstable” he may not mean what the manager thinks he means

Improvements

• Make sure the product manager actually installs the app that’s being developed for him

• Make sure the developers understand why certain features need to be added

• Listen to feedback from your developers when conceiving the product - they know the platform

Improvements

• Arrange regular meetings between product owners and developers

• e.g. Sprint Reviews

• Don’t just send out an invite to the daily standup and be done with it

• Certain people just don’t understand why they should attend and think it isn’t worth their time. Most often they will only attend at the beginning or when things go pear-shaped

• Make sure all parties understand the “cost” of changing something during development

• Starting out with an iPad app and then deciding you want it on iPhone as well

http://en.wikipedia.org/wiki/File:Handshake_(Workshop_Cologne_%2706).jpeg

Save the date!

Implications

• A day or so later …

• “Does our app run on iOS 8?”

• “Can we use the new functions that were shown at WWDC yesterday?”

• “Can I see our app running on Android ‘L’ ?”

• “Please provide an estimate on the effort to adapt our app to use ‘Material Design’ by COB tomorrow”

Examples

Examples

Prevention tactics

• As soon as possible after the “event”

• Send out an email to major stakeholders outlining what was shown (relevant for the app) and what areas need to be evaluated

• Install a pre-release version of the OS and run the app on it to find any major issues

• Note that in many cases the beta version of an OS will improve over time fixing issues you may see in the first version (looking at you Apple)

• Work with QA to “contain” any damage reports - i.e. you don’t want this to happen:

• QA installs first beta of iOS 8, tests app and then sends out an email to stakeholders outlining all the crashes and problems

• The perception will be that these are app issues (!)

Technology “ripening”

• Operating systems for mobile devices are often released too early

• Very short release cycles during device and system development

• Often several times a week

• Functionality comes and goes depending on the release

• “..and the critical iOS 7.0.6 update just completely bricked my iPad. Awesome.” - @parislemon (28.02.2014)

!

• Trivia question - how many Android versions were released in 2013?

Android in 2013 - 6 versions

• 4.2.2 (11.02.2013)

• 4.3 (24.07.2013)

• 4.3.1 (03.10.2013)

• 4.4 (31.10.2013)

• 4.4.1 (05.12.2013)

• 4.4.2 (09.12.2013)

!

• “but that’s cool - lots of new shiny things to play with”

!!

• (source: http://en.wikipedia.org/wiki/Android_version_history)

Pro-Tip

Stay ahead of any incoming technological changes (new OS etc.)

Even if you have to “wing it”

Technology influence

• Vendors and operators influence what goes into the device (and operators own the network)

• Don’t make assumptions on what your customers are using!

• The underlying operating system plays a major role for your application

• Even if you’re designing a mobile Web app

• Keep looking at what your users are running the app on and adapt for that

• There are plenty of SDKs that allow you to “track stuff”

• Check out what is causing the most crashes of your app and fix that first!

• Before worrying about adding the next cool feature

Who’s leading Who?

• Mobile technology is still developing very rapidly

• Make sure your project won’t be obsolete by the time it’s finished

• Plan iterations to make sure you keep up with new developments

• Did you develop for WebOS? (Or BlackBerry?)

• Today, software innovation outpaces network innovation by at least a factor of five: application developers often reach market in only three to six months, while operators take 18-24 months to launch a new service.

• Mobile-Developer_Econonomics_2011 (VisionMobile)

Technology cracks

• Fragmentation will remain the problem

• And I don’t just mean Android...

• Mobile browsers

• iOS 6 vs. iOS 7

• 10% of our current iOS users are still running iOS 6

• Should the next version of the app support it?

• The answer depends on who you ask

• The wrong answer can cause lots of issues

• Support drag and drop in Android version of the app (also in old Android versions)

• Support background uploads/downloads in old iOS versions

Choosing resources

• You’re looking for a Web developer

• Pretty straight-forward

• Frontend: HTML, JavaScript, Responsive Design

• Backend: PHP, Node.js, Ruby on Rails

Choosing resources

• You’re looking for a “mobile developer”

• Say what?

• Do you mean Android? iOS? Windows Phone? HTML 5? Or all of those?

Choosing resources

• “Developers, Developers, Developers!”

• “Readily available” mobile development is still relatively new

• Downloadable SDK

• Accessible devices

• Testing via simulators

• It’s difficult to find an all-rounder

• iOS, Android and mobile Web please

Choosing resources

• Google releases first “early look” Android SDK

• November 2007

• Apple released the first beta version of the native iOS SDK

• March 2008

• So, don’t go looking for the mobile developer with 10 years of Android development expertise!

• And also don’t trust anyone that experienced

• Choose motivated and technically savvy resources with “mobile” experience and an eye for the challenges

Choosing resources

Choosing resources

• Does your developer really know mobile?

• “They don’t seem to grasp that one must understand the native environment you’re working in before going ahead and writing a program to run within it.”

• Andy Firth - http://altdevblogaday.com/2011/08/06/demise-low-level-programmer/

Choosing resources

• “Developers use 2.5 platforms at the same time, which is down from 2.9 in our Q3 2013 survey, pointing to consolidation.”

• Down from 3.2 platforms in 2011

!

• “iOS is the preferred platform for developers in North America and Western Europe while Android wins in every other region. The difference is especially pronounced in Asia, where 46% of mobile developers prioritise Android vs. 28% for iOS.”

!

• (Source: Mobile-Developer_Economics_Q1_2014.pdf - Vision Mobile)

Choosing resources

• But it’s not just developers...

• Great application user interface design

• Not every UI designer knows mobile

• Photoshop is not a mobile development tool!

• Find designers who understand the technology implications

• resolution, screen size

• touch vs. non-touch

• mobile vs. tablet

• browser vs. app flow

• implications of using native components vs. “roll-your-own”

Choosing resources

• Find experienced mobile project managers, designers, developers and testers who can lead the team and act as mentors

• Make everyone part of the team

• Build up teams combining different skill-sets

• If you are developing for several platforms then don’t put all the good developers into a single team

• Have regular “brown-bag” sessions where knowledge can be shared through the team

• Encourage good mobile developers to coach developers who are not as good

• Have a process where any code-commit needs to be reviewed before it goes into the codebase

Implementation & Testing

Before we begin

“Most programmers regard anything that doesn’t generate code to be a waste of time. Thinking doesn’t generate code, and writing code without thinking is a recipe for bad code.” (Leslie Lamport)

!

http://www.wired.com/opinion/2013/01/code-bugs-programming-why-we-need-specs/

Before we begin

• Storyboard the application using mockups

• Use a tool like Balsamiq

• Test out your concepts with a target audience

!

• Even paper and pen is better than no mockup!

Storyboard

Before we begin

• Designing a native mobile app is different from designing a Web app

• Make sure everyone knows this

• Design the application with an understanding of the technology you’re targeting for

• “Well it looked fine on an iPhone 5s”

• Did you remember not just to design for portrait mode?

Before we begin

• What about tablets?

• “Can’t we just stretch the UI?”

• “We want these really cool sexy view transitions”

• Did you test things like that on low-end devices?

• Show your User Experience design to developers as well as product managers!

• Don’t just throw the wireframes over the wall

• Remember: One design does not fit all

Before we begin

• Make your mobile Web design “intelligent”

• Use things like CSS media queries to be responsive

• Computers aren’t the only piece of hardware with a web browser anymore

• Look at “Mobile First” and add other layers as needed

• Make sure your application is designed to look as though it is doing something

• Mobile networks can be slow - so pretend they’re not and cache if you can!

Bad design costs lives

• A single bad screen can cost millions of dollars in lost revenue and brand value

• You get only one chance to make a first impression

!

!

!

Mobile UI Performance

!

!

!

!

!

!

!

!• http://www.smashingmagazine.com/2011/07/18/seven-guidelines-for-designing-high-performance-mobile-user-experiences/

Development model

• Whichever model you choose

• SCRUM

• Waterfall

• Something else

• Make sure all project members can live with the decision

• Not just the developers

• This is probably harder than it looks

• “I don’t care which development model you use, just make sure you deliver on March 31st”

Development estimations

• Sceptic vs. optimistic

• Try to estimate individual tasks and not just roll the dice on a whole project

• Use something like story points and planning poker to gauge how much the team can achieve

• If you are using a SCRUM model then start off with a sprint that will let you “test” how good the developers are at estimating

Development platforms

• Each has its own challenges

• Native (Android, iOS, Windows Phone)

• Support for required functionality in all versions of the OS

• Support for required functionality across platforms

• Various frameworks available that need evaluating and then integrating

• Technical decisions made at the beginning of the project will come back to haunt you!

• Mobile Web

• Do the requirements match what is actually possible?

• Which libraries are you going to use

• Provide a hybrid app?

HTML5 is not a silver bullet!

• Don’t let anyone tell you it’s “either or”

• It should always be a well-informed use-case based decision

• You still need developers who know HTML 5 and related libraries

• If you plan on providing a hybrid-app

• You still need a stable environment that supports your target platform

• You still need to test on different devices and operating system versions

!

• By the way - your “native” mobile app developer will probably try convince you not to use HTML 5 (and vice-versa)

Mobile browser usage

source: http://www.quirksmode.org/blog/archives/2014/01/browser_stats_f_7.html

Internationalization• The pain of deploying the same app for 18

countries

• Language translations

• Are you still using an Excel sheet?

• Look at online tools such as transifex.com

• Get the regional branches involved in the translation process

• Set concrete deadlines for translations

• Even if you supply your base language file in “English” - remember that there are other “versions” of English

• Some languages are easy - IT, ES, DE but what the heck is SQ?

Internationalization

• Networks

• Other countries have different network qualities

• Don’t just test your app on LTE

• Check for silent failures if the network is down or just 2G

• Country specific issues

• Displaying months - remember to use the functions for obtaining standalone month names if needed

• Displaying tax information in certain countries

Internationalization

• Get the countries involved as soon as possible

• Check (or do) translations

• Provide any local laws that are relevant

• Perform testing in local networks and provide feedback

• If your app is data-heavy then you may notice a difference between testing in Munich and testing in Albania

Testing

“I tested the reported bug and couldn‘t reproduce it” ! “Did you test in on the same device / operating system /

network version it was reported on?” ! “Umm.. No... Why?”

Testing

• Testing a mobile application is time and resource consuming

• Plan enough time and resources in your project for testing

• Make sure test-cases reflect actual use-cases

• Simulators are available

• Often part of the SDK (e.g. iOS)

• HTML 5 - Ripple - http://ripple.tinyhippos.com/

Testing

• Testing on actual devices is mandatory!

• And not just on an S5 or Nexus 5

• Make sure you test on the different OS versions

• Different memory configurations

• Also consider services such as DeviceAnywhere.com

• Regardless of how much you test (on how many devices)

• Someone, somewhere will be using a device / operating system combination you didn’t test on

Testing

Pro-Tip: Make sure you know which device your boss / customer is using - and test first on that one

Testing boredom

• Testers become bored if they have to repeatedly test the same stuff

!• They will look to make life interesting by e.g. rapidly

tapping on something to see if they can make the app crash

!• They should be focussing on testing the main functionality

!• Rotate testers around projects to keep things fresh

• Don’t get them too integrated with the developers or they

will know which things not to test

Testing hell

Email from central QA department to development team:

“We have found a critical issue on a certain - not yet released - device that we may or may not be able to provide to you tomorrow.

However can you please tell us if the fix can be in the next version you plan on releasing?”

Deployment

http://www.flickr.com/photos/isawnyu/4566381520

Deployment

• Deploying an app into a store takes time and effort

• Plan for app signing

• In a large organization - that may be harder than you think

• Plan for the acceptance period (dependent on App store)

• Remember that release date you were given? You have 2 weeks less than you thought!

• Plan for iterations as you need to update assets such as screenshots, descriptions (multi-language anyone?)

• Check the assets (still) fit the app - especially if updating the version

• Don’t photoshop screenshots - you will be found out (yes, really)

Deployment

• If the App store is available in different countries - have you tested with foreign sim-cards?

• Do you know what the limitations of different countries are?

• Does the App store support the business model you are considering?

• In-App purchases, Vouchers etc.

Deployment

• You don’t need to launch in all countries at once (and you probably shouldn’t)

• Select certain ones as trial markets

• “Turn on” new markets selectively

• Make sure each market has met its requirement

• e.g. set up the correct pages showing Terms & Conditions

Release Cycles

• A release cycle needs to be planned

• Development, testing, deployment

• Fixing a bug and pushing out a new version is not always a “point and fire” process

• Developers find that frustrating

• “Well, I quickly fixed the bug, why isn’t it in the build we just released?”

Business

http://www.flickr.com/photos/59937401@N07/5474437939

“Your cell phone has more computing power than all of NASA in 1969.

!

NASA launched a man to the moon. We launched a bird into pigs.”

!

(via Twitter)

Hot sellers - easy money?

• Angry Birds .. not quite so simple..

• Rovios 52nd title

• Titles written for companies such as EA, Digital Chocolate

• Initially spent € 100.000 to develop Angry Birds

• When it was released in December 2009 in the English speaking App Store - it was a flop!

• Tough to break into that market from the get-go

• Rovio tried to get a following in the smaller markets

• Sweden, Denmark and Greece

• Then published via Chillingo and with Apple’s help featuring the app on the UK App Store - launched new versions in February 2010

• And the rest is history

!• https://technology.ihs.com/403311/angry-birds-developer-raises-42m

Hot sellers

• What makes Angry Birds successful?

• Simple to play - difficult to master

• Constant rewards in the game

• Active continuous relationship with the customer

• Regular updates for free and new versions with a theme (halloween etc.)

• Cared about feedback from the customers

• Phoenix bird that ignites the structure was a suggestion from a customer

• Rovio were able to create a “buzz” around the game

Hot sellers - short life?

• Flappy Bird

• Independent developer

• Developed over only a few days

• Released in May 2013 - became very popular in early 2014

• Criticized for level of difficulty and alleged plagiarism (but considered addictive)

• End of January 2014: Most downloaded free game in app store

• According to developer it was earning 50.000 $ a day through in-app ads

• Removed from both iOS and Android stores on February 10th 2014

• Developer said that he was under too much stress due to the games success

• Since it was taken down

• 60 Flappy Bird clones submitted to the app store every day

• source: http://www.forbes.com/sites/insertcoin/2014/03/06/over-sixty-flappy-bird-clones-hit-apples-app-store-every-single-day/

Hot sellers - one hit wonders?

• Candy Crush Saga

• Free to play (but to really play means you pay)

• Downloaded more than half a billion times

• $2 billion in sales in 2013

• $567 million profit

• Now looking for an IPO (valuation over $5 billion)

• But

• Company has published over 100 titles

• 80% of revenue comes from Candy Crush

• How long will that continue?

So think about this…

“Typically, companies will have that one big product, and then they’ll sell some sequels to it. But, unless they manage to become the center of an ecosystem, over time they tend to weaken and disappear.” (Prof Michael Cusumano, MIT) !source: http://www.newyorker.com/talk/financial/2014/03/17/140317ta_talk_surowiecki?mobify=0

Before you get too excited

• The average smartphone user in a study added just 2.5 new apps per month.

• 37 percent of users added no new apps at all.

http://www.wirelessintelligence.com - Study was based on an analysis of more than 2,100 smartphone users (iPhone, Android, BlackBerry and Symbian) in the US and UK during January 2011

Before you get too excited

!

!

!

!

!!

• http://www.phonearena.com/news/The-average-global-smartphone-user-has-downloaded-26-apps_id47160 (Sept 2013)

Actually, things are getting worse

Auch in Deutschland

http://netzoekonom.de/2014/08/31/zwei-drittel-der-deutschen-laden-keine-apps-mehr-herunter/

Lots of downloads - but no money!

• PunchQuest launched in 2012 in the App store

• Free to play

• Quickly reached over 600.000 downloads

• Critics loved it

• Business model was in-app-purchases

• But: It didn’t make much money (only just > $10.000 after a few weeks)

• People were playing but not paying

• Company was worried that the popularity would quickly drop off leaving them with a loss - even though everyone liked it

• Eventually switched to a pay-for-play model

So is Freemium the best model?

• In January 2014

• Only 1.5 % of all freemium players actually bought something

• Of those payers

• 49% only bought once

• on average, 0.15% of the payers are generating 50% of the IAP revenue of a game - they are the “whales”

• average time to purchase is 24 hours

• Of those purchases

• Purchases between $1 and $5 make up 67% of all purchases but only 27% of all revenue

• on average, 0.7% of all purchases are over $50 and this makes up 9% of the total revenue

• source: http://swrve.com/weblog/some-thoughts-on-monetization

So, before you get too excited

• “Our latest Developer Economics survey shows that 60% of [Android] developers are below the “app poverty line”, i.e. earn less than $500 per app per month.”

• “1.6 % of app developers earn more than all others together”

• “23% make less than $100 a month”

!!

• (Source: Mobile-Developer_Economics_Q3_2014.pdf - Vision Mobile)

It’s just business

“Mobile apps aren’t a get rich quick scheme where you can be oblivious to best practice. “

“Usual business rules apply and there are extra mobile rules for the unwary.” Simon Judge

So to summarize ….

• An example list of things that went wrong…

Lessons learned - real world

• Timeline expectation was given even before the project started

• Development was started without having all use-cases defined

• Limitations of office-space and co-location impacts development team

• 3 Platform implementations (iOS, Android, WP8) run in parallel

• Impact on coordination, scope, QA

• Use cases and initial UE specification alone were not sufficient to detail all aspects of the product

• Too many change requests added during the project

• Mismatch between wireframes and design specs

• Feedback from local branches (internationalization) was received too late

Lessons learned - real world

• Old version of the client “evolved” while the new version was still under development

• Raising “implicit” change-requests - “of course the new client needs to do x”

• Design changes received at late stages of project

• Design of Android app did not follow Android guidelines

• UE wireframes did not document user flows fully

• UE designs were provided in different formats (PDF vs. AI) and not kept in sync

Additional links

• This presentation (2011 version) as an article - http://webmagazin.de/business-strategie-mobile-projekte-39956.html

• http://www.mobilebusiness.de/home/newsdetails/article/warum-app-projekte-scheitern.html

• http://www.itespresso.de/2013/03/01/dresdner-projekt-fur-mobile-payment-scheitert-an-formalien/

• http://qz.com/258066/this-is-why-you-dont-hire-good-developers/

Thanks for staying to the end!!

“Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better” - Samuel Beckett

matthew.langham@indiginox.com

Thanks to Stefan Kolb & Reginald Rink for input

photo on slide 1 (c) Frank Köhntopp - used with permission - http://www.flickr.com/photos/koehntopp/

photo on slide 1I http://www.flickr.com/photos/landscape_photography/9631304512/sizes/l/