The biggest mistake one can make when approaching mobile apps is to assume that the same rules you used to design other apps like native desktop or web apps, will be successful in mobile apps. They won’t. It’s a dramatically different paradigm.
If you’re not already convinced, think about this…
Mobile tech has been the fastest growing tech ever. Sure the advent of personal computers was big. Sure the Internet was huge. But none of them had the numbers that we’re looking at here. Billions of devices. Over 100 billion app downloads. All in just a few years.
It’s easy to get lost the first time you design a mobile app. To take a wrong path because “that always worked before”. Just remember, this is radically different than anything we’ve ever done before. It requires you to think different. To throw out the old rules, and embrace new ones.
There’s a lot to cover to do this subject the justice it deserves, and to cover all that you’ll require to be successful. But since this is just an article and not the encyclopedia of books that you’d need, I’ll focus on some principles to act as a guide. I’ll be writing about both management and technical principles over a series of articles. The management principles are essential to be successful at building great mobile apps. The technical principles are some of the fundamental architectural differences in mobile apps that can be key to a great app.
Why is mobile app design different ?
Apple created this type of software and market just 5 years ago when they opened the App Store on July 10, 2008. A whole new type of software was created with now hundreds of thousands of apps. With a whole new model of selling and distributing apps. A gigantic world wide marketplace created in just a few years. And we ain’t seen nothin’ yet…
Now look at the entire architecture of mobile – hardware, software and network. Compare that to the entire architecture of desktop or web apps. I hope you noticed it’s very different. No ? OK, think about what’s different about the mobile architecture that will impact the User eXperience (UX) of your app. Here’s some: cell networks, network speed, public WiFi, touch interface, screen sizes, less functional OSes (for now), rapid changes in hardware, new devices, constant releases of new OS versions, new competitors, etc.
Look, the mobile marketplace is way different. This isn’t your father’s software market. We’re dealing with what I like to call, a frictionless channel. The first ever in software.
What is it and what is the impact of a frictionless channel ? Well consider how software used to be sold and distributed. On media. Disks, CDs. And they were sold through resellers. Retail dealers with stores or mail order sales. And the media, product boxes and manuals had to be manufactured. Then distributed to wholesalers, who would take their cut and distribute them to retailers. Every point in that channel adds distribution costs and creates a point of friction. Resistance and delay to getting the product to the customer.
Now…. that’s all gone. Customers buy apps directly from giant online app stores or sometimes still online directly from software developers. And the app is instantly delivered via a download over the Internet. No delays, no resistance, no friction. The customer gets instant gratification. And the software developer generates revenue with no direct distribution costs.
Customer expectations are also different. Along with the expectation of instant gratification that a frictionless channel provides, this new online marketplace also brings with it instant access to data on rating, ranking, reviews and other sources of data that customers use to make buying decisions. That was never possible before.
It’s not only that your customers are just a click away from your competitors. Customers are now zero clicks away from a fully informed buying decision, because rankings and reviews are integrating directly into the buying experience. And they can directly participate in that enormous base of knowledge about your products and influence the buying decisions of your other future customers too. It’s the ultimate democracy.
 |
| Analyzes how Apple ranks apps for its Top Charts |
All of this also levels the playing fields for your competitors. With a practically zero cost distribution channel, the costs of doing business and creating a new business, are dramatically lower. This means new competitors can enter the market much faster, easier and cheaper than ever before. If you are a large and established brand and company, that more leveled playing field means you need to work much harder to stay ahead. Because small competitors can come out of no where at any time.
And with app quality becoming more important in app rankings used in App Store’s Top Charts and app analysis (chart above), quality beats quantity for marketing your app and increasing your visibility in the market.
Think Different about Design
The point of all of that, is that you have to think different about design. With all those dynamics of this entirely new marketplace, it’s even more important then ever. The UX of your mobile app is different. The expectations of your customer are much higher. Competitors can turn on a dime. And the marketplace can change significantly every quarter.
Imagine new ways
Mobile tech presents a whole new way of doing things. New capabilities that were never possible before and aren’t possible with any other kind of device. To truly take advantage of the amazing possibilities, you need to think different.
Don’t just repurpose existing desktop or web apps to mobile devices. Go beyond….
If, for example, you have a web app like e-commerce, you need to think in terms of mobile commerce now. M-commerce. That means don’t just offer the e-commerce features you already have on your web site, and put them on a mobile device. Just doing that squanders the tremendous opportunity that mobile presents to e-commerce.
You need to build things that no one has ever thought of before. Merge the awesome power of e-commerce with mobile and envision and create user experiences that blow people’s minds. That do things that simply can NOT be done with anything else. The missing link between e-commerce and the real world, IS mobile. It brings the 2 worlds together in real time, right in your face, before your very eyes.
You need to go BEYOND just e-commerce on a phone. The phone brings the power of the cloud into the palm of your hand. Don’t waste it’s incredible potential.
As a customer of e-commerce for many years, what I want when I go mobile is to gain capabilities, not lose them. And many of today’s mobile commerce apps force you to lose capabilities. I think regular consumers want that too. And further, they don’t have the patience to try something new unless it is clearly better. Everyone else is delivering compromised user experiences with less, less, less. You should focus on more, more, more.
IMAGINE…. commerce that knows where you are in the store, knows who you are and knows what you like. Now design user experiences that are breakthroughs.
…… Location aware promotions that pop up when you walk towards an aisle. Real time navigation INside the store that guides you to exactly what you’re shopping for. Augmented reality that can help a customer find things to buy and show them what those things might look like on them or in their home. Cross selling in real time – pick a item to buy, get instant recommendations on the spot.
And of course, all the commerce features you can eat, spiced with some mobile tech like payments, store locators, social networking, cameras, etc.
The possibilities are endless…… And go waaaaaaayy beyond what we’ve thought of as e-commerce up to now. Mobile is e-commerce UNLEASHED.
And to create breakthroughs, you don’t need just great leaders and UX designers…. You need artists !!! You need superheroes.
Scrum is Required
 |
| Scrum Framework Diagram |
And go pure Scrum. Don’t do it half way, or some bazaar hybrid of old school waterfall and Scrum. Going truly Agile has some enormous benefits and beats waterfall hands down.
One widely cited set of surveys used to show that Agile beats waterfall is published by the Standish Group CHAOS Manifesto (link to a Google search). You’ll find tons of references to data from these reports and lots of copies of the report out there too. In the Standish Group CHAOS Manifesto published in 2011 (link to a full copy) it shows waterfall projects have 3 times the failure rate – 29% vs 9%. And a third the success rate – 14% vs 42%. The graph below shows the details.
 |
| Project Success Rates: Agile vs Waterfall |
The Standish Group measured CHAOS resolution results of waterfall and agile projests from 2002 to 2010.
Definitions used on the Standish reports:
- Successful = Delivered on time, on budget, with required features and functions.
- Challenged = Late, over budget, and/or with less than the required features and functions.
- Failed = Cancelled prior to completion or delivered and never used.
 |
| Project Success Rates by Year |
The Standish Group has been doing this kind of research and reports for many years. This graph shows project success rates going back as far as I could find them – from 1994 to 2012. The rates are fairly consistent for nearly a decade. Success rates only average just under 29.9%, while failed and challenged projects make up the remaining 70%. Success rates are slowly improving over the years, due at least in part to the gradual adoption of Agile principles and the move away from failing waterfall and other management methods.
The survey results from the Standish Group CHAOS Manifesto reports include all types of projects, and so it is heavily weighted towards projects managed using waterfall methods. In their 2011 CHAOS Manifesto, they noted this regarding the increase in projects managed using Agile methods:
“In 2002, Agile projects made up less than 2% of overall projects and less than 5% of new application development projects . Today, Agile projects account for almost 9% of all projects and 29% of new application development projects, for a 22% CAGR . The increase in project success rates can directly tie back to projects resolved through the Agile process.“ – Standish Group’s 2011 CHAOS Manifesto, page 1
Additionally, they also noted this about the much higher quality that Agile projects produce.
“The Agile process is delivering not only a higher percentage of features driving up the average, but also a higher percentage of higher usage of those features . Still, there is much need for improvement.” – Standish Group’s 2011 CHAOS Manifesto, page 2
 |
| 3 Agile Scrum Books You Must Own |
To learn more about Scrum, see the following references. I’ve listed them in order from basic to more sophisticated:
- Scrum at Wikipedia.
- Why Scrum ? at ScrumAlliance.
- The Scrum Papers by the co-creators of Scrum and other Scrum Resources at ScrumAlliance.
- Check the book review article I wrote on 3 Agile Scrum Books You Must Own.
Scrum is a Competitive Advantage
Because Scrum is such a well defined and mature process, there is an enormous amount of support to be found and advantages to be gained. This standardization in method, training, knowledge, creates a huge competitive advantage for anyone who embraces a standard Scrum approach.
By contrast, waterfall and other methods are much much less standardized and although they share some commonalities, every waterfall organization has their own non-standard spin on it. This proprietary nature costs huge amounts of money in learning curves, training, speed, and handicaps your ability to compete.
Standard training available everywhere
Scrum training is almost literally everywhere. Because it is standardized by the ScrumAlliance you know what you’re getting. They have Certified Scrum Trainers all over the place and you can find and schedule training online in a snap.
Extensive Certifications
The ScrumAlliance manages a number of certifications that you can use to ensure consistent skill sets for all levels of Scrum professionals. From team managers, to product managers, to developers and more.
Recruiting talent gets easier
Because training and certifications are completely standardized you can rely on those standards for screening new talent. As with all things, experience matters most. But the training and certifications ensure that your new talent knows the real Scrum.
But there’s more… it shows that your new candidate has made an investment in something critical to your success. And chances are that they might have some painful ScrumBut experience that can help you. And if you are for real and serious about Scrum and Agile, that will make your company more attractive to the best of the best. And competition for talent in mobile is fierce so you need every advantage you can get.
Scaling Scrum UP
Got a big product with big programs and big problems ? Then you need to scale your Agile Scrum implementation to many teams and locations. The school of thought and knowledge to turn to, to scale Agile is the Scaled Agile Framework (SAFe).
SAFe provides a large framework for scaling the Scrum process and Agile principles to a much much larger environment. All the way up to the largest enterprise. And in the last few years there have been noticeably more leading companies, in and out of Silicon Valley, not only fully embracing Scrum, but adopting SAFe to scale their Agile implementation throughout their enterprises.
The Scaled Agile Framework web site contains a break down of the framework covering team, program and portfolio levels. The SAFe framework is presented on the web site as a diagram called the Big Picture (pictured below).
 |
| Scaled Agile Framework Diagram |
All of the elements of the Big Picture diagram on the SAFe web site, the roles, teams, activities and artifacts, are all clickable so you can drill down into a description of each. It’s an excellent way to begin learning SAFe.
It’s creator, Dean Leffingwell, has elaborated into even more detail in his books. Dean’s most recent book is Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. This is 1 of the 3 books I highly recommend in my book review article 3 Agile Scrum Books You Must Own. While the web site is very useful, if you are going to be serious about attempting to scale Agile, then you need to buy at least this book.
SAFe has a community that’s developed around it and is becoming more and more visible in the job market. There is formal training and even certifications available.
Stay Close to your Customer and your Team Members
Product management, project management and UX design need to be close together. Like…. in the same office. Scrum and Agile principles state a need to have team members in the same location. So collocation must be part of your strategy. That’s because teams are dramatically more productive and effective that way.
But, we also know that distributed teams are often a fact of life these days. And we can make it work much better with a scaled Agile strategy. But first you need to admit and recognize that it is not the best way to manage software development.
When teams work closely together, co-located in the same office space, it dramatically improves communication quality and frequency, greatly accelerates response time and issue resolution and completely collapses cycles of all kinds. Agile principles in general, and the Scrum process specifically are about fast communication, continuous delivery and simplicity – to name just a few. Distance between team members gets in the way of this. What’s faster and easier ? Writing an email or an issue in an online issue tracking tool and waiting a day for a response. Or walking across the room and getting an answer right now.
 |
| Project Success by Team Distribution |
Ambysoft publishes a number of useful survey results on various Agile topics, among other things. One of their surveys that was included in the official Scrum training courses that I attended and is referred to often in Agile circles, shows that the success rates of co-located teams are significantly higher than those of distributed teams.
Here are the definitions of the team distribution types used in the survey:
- Co-Located Team – In the same physical room.
- Near Located – In different cubicles/offices, on different floors, or in different buildings, but could still get together easily if required.
- Far Located – Where some team members are at a different location which would require significant travel to get to.
Source: Ambysoft’s Agile Adoption Rate Survey Results: February 2008
You get better quality software, much faster, if the team is all in the same location. If you can’t do that, then you’ve got a problem you need to solve. Admitting a problem exists, is the first step to fixing it. If you continue to fool yourself into believing that distributed teams are better and cheaper, and deny the fundamental truths about human nature and Agile/Scrum, then you will suffer from all the downsides that distributed teams brings. If you admit and face the truth, then you can make it better. You’ll never make it as good as co-located teams, but you can make it work.
So how can you make it better ? Here are some principles to follow.
Outsource your Tech Projects
If you are not in the software business, then give the entire tech project to a vendor. In other words, if your expertise is in retail or manufacturing or hotel management or whatever, and not technology…. then outsource your technology projects to the experts. Don’t split a project across vendors and especially do not split teams across vendors.
Small Scrum Teams
Organize your teams in to Scrum teams. Small, focused and manageable units. Following Scrum guidelines, that means ideally 5 to 9 people.
Complete Skill Sets
Design the Scrum teams to contain all of the skills that are required to complete major units of work. Use the definition of done as a guide to what a complete unit of work is.
Scale Agile
Use Agile scalability concepts like Scrum of Scrums, integration Scrums, etc. See the Scaling Scrum UP section above for more.
Keep the Team Together
Don’t split a Scrum team across offices or geographies or organizations. All Scrum team members should be co-located in the same office room or area.
Self Sufficient Teams
Scrum teams should be self sufficient and self contained, not depending on anyone outside the team to complete work. IE. Each Scrum team should have a ScrumMaster, a Scrum Product Owner and have all the tech skills needed to get to done. The team should have all the skills needed to deliver a working product every Sprint.
Redundancy
Design in redundancy to capture back some of the value lost when using distributed teams. IE. Have 2 complete Scrum teams in 2 different locations with the same skill sets. By doing this, you can still take advantage of differing costs in different markets, while scaling up your capabilities faster, and lowering your risks by not putting all your eggs in one basket – or job market.
Work Life Balance
Preach and practice a healthy work life balance. Many companies just talk about this, but do little to put it into real practice. Providing a healthy work life balance will make your employees happier, work more productive and as a result lower turnover and increase sustainability.
Some articles and sites worth reading:
- The Agile Manifesto – The 12 Agile Principles – The sixth principle is: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- The Scaled Agile Framework (SAFe) web site represents the school of thought and knowledge on how to scale Agile.