My talk around the reasons mobile projects fail and what you can do to prevent some of the pitfalls. This talk doesn't talk about code or deep dive technical development - but about the "other" problems that can befall a mobile project - especially in large organizations.
This document describes a "fad-free architecture" approach for developing mobile apps. It advocates separating user interface code from non-UI code and relying primarily on first-party Apple frameworks rather than third-party libraries. The key aspects are a DataController class that coordinates other controllers like NetworkController and PersistenceController, and view controllers that receive the DataController through dependency injection to access non-UI functionality. This architecture aims to produce stable, maintainable apps by avoiding transient technical trends in favor of tried-and-tested techniques.
Lean Engineering: How to make Engineering a full Lean UX partnerBill Scott
In 1999, PayPal's name was synonymous with innovation. In fact, the so called PayPal Mafia (original founders) went on to establish Tesla, SpaceX, YouTube, Skype and other startups. They also provided the early investments of many of the most innovative companies on the internet today. But over time that innovation slowed to a crawl.
In 2011 a number of things begin to come together for PayPal that started its journey back to innovation. This is the story of that reboot and how engineering has played a key role in partnering directly with product and design to move from a culture of products having a long shelf life, to one of rapid experimentation.
In this talk, Bill will outline the principles of Lean Engineering; principles for engineering that enable learning. Drawing from his experience leading User Interface Engineering at both Netflix & PayPal, Bill will walk you through the key principles your engineering team will need to adopt to be that enabler for product and design in your organization. This talk will not just inspire you, but it will also give you some hard earned advice on making this a reality in your organization.
What I learned from 5 years of sciencing the crap out of DevOpsDevOpsDays DFW
For years we laboured under the misapprehension that going faster meant breaking things. After several years of science-ing, Jez and Dr Nicole Forsgren have identified the key elements that enable not just higher throughput but also higher stability, availability and quality, lower cost, and happier teams. Discover how continuous delivery, cloud infrastructure, and effective management and leadership practices produce higher software delivery performance (and indeed what we might mean by performance), along with how to measure culture and its impact on IT and organizational culture. Find out how we actually ensure our results are reliable and meaningful. Learn the patterns and practices used by high performing organizations to outcompete their peers.
This document discusses lean software development principles. It introduces agile software development processes and the agile manifesto. Lean software development is then discussed, which comes from the Toyota Production System and uses a set of principles and tools to achieve quality, speed and customer alignment. The 7 principles of lean thinking are outlined: 1) eliminate waste, 2) amplify learning, 3) decide as late as possible, 4) deliver as fast as possible, 5) empower the team, 6) build integrity in, and 7) see the whole. Each principle is then explained in more detail with examples related to software development.
From LazyCoffee to Appstore - The Key stages of app developmentScott Roberts
The document outlines the key stages of app development from idea to shipping, including funding, team building, design, development and marketing. It discusses coming up with an idea and validating it, designing wireframes and prototypes, choosing a development platform like iOS or Android, and important marketing activities prior to and after launching an app in the App Store. The goal is to guide readers through the full process of taking an app from concept to finished product.
Mobile App Design Best Practices - Usable Interfaces for Tiny PlacesApigee | Google Cloud
The document discusses best practices for mobile app design, focusing on creating usable interfaces for small screens. It emphasizes the importance of wireframing and prototyping before design to simplify interfaces. Great design takes away complexity by removing unnecessary elements and using white space effectively. The document also stresses the need to follow platform guidelines and provide feedback to users to give the perception of high performance, even when factors like network conditions are outside the designer's control.
The document discusses POP, a development company that builds apps using an agile development process. It emphasizes quick prototyping, getting early and frequent user feedback, and making changes before extensive coding begins. This allows POP to rapidly iterate their ideas and ensure they are building something users want. Their process involves brainstorming, research, prototyping, testing, coding, more testing, and then release.
Successful writing at work copyright 2017 cengage learnssusere73ce3
This document is the table of contents for a book about successful writing at work. It outlines the contents of the book, which covers topics such as identifying audiences, establishing purpose, adapting style and tone for different audiences, characteristics of job-related writing, writing ethically, the writing process of researching, planning, drafting, revising and editing, collaborative writing, and conducting effective meetings. The table of contents provides an overview of what is covered in each chapter to help readers understand what content is included in the book.
The document describes different design orientations that software developers can have: simple, powerful, abstract, pragmatic, robust, concrete, idealistic, and technological. It tells a story of two developers, Bob and Sally, who struggle with their different orientations of powerful and simple, respectively, in designing a software project. Their project fails due to a lack of robustness. Two other developers, Jack and Sam, who have abstract and pragmatic orientations, are able to help stabilize the project by refactoring the architecture and focusing on quick implementation. The document concludes by explaining each of the design orientations and how understanding them can help teams work together more effectively.
How large companies can be as fast and agile as the successful startups? And what is MVP and Dual-track Agile, anyway? We are to discuss a real case of implementation of some methods of Lean Startup and Customer Development in Kaspersky Lab.
This document summarizes a presentation on pair programming and test-driven development (TDD). It discusses common misconceptions about pair programming, such as the idea that it wastes resources or is only useful in specific situations. The document advocates for regular pair programming, noting benefits like improved collaboration, knowledge sharing, and code quality. It provides an overview of TDD and ping pong pairing. The audience is then instructed to split into pairs to work on sample development tasks in a shared repository, with the goal of practicing pair programming and TDD techniques.
This document discusses common myths held by software managers, developers, and customers. It describes myths such as believing formal standards and procedures are sufficient, thinking new hardware means high quality development, adding people to late projects will help catch up, and outsourcing means relaxing oversight. Realities discussed include standards not being used effectively, tools being more important than hardware, adding people making projects later, and needing management and control of outsourced projects. Developer myths like thinking the job is done once code runs and quality can't be assessed until code runs are addressed. The document emphasizes the importance of requirements, documentation, quality processes, and addressing change impacts.
ETDP 2015 D2 Do it-yourself dynamics – vibration assessment using smartphones...Comit Projects Ltd
Pete Winslow and James Parker, Expedition Engineering
In past years much progress has been made to demystify the issue of ‘vibrations and dynamics’. Well established methods of advanced analysis and testing are now available to practicing engineers to assess and verify performance – for both construction vibrations and for performance of the as-built structure itself. However, physical testing of vibrations still remains an area reserved for specialists, and it is generally only undertaken if an obvious problem has arisen. Traditional instrumentation/measurement approaches can have long lead times, are time-consuming and costly. During the presentation we will live-demonstrate the “Vibrate-it” testing app for floor vibrations, which has been developed by Expedition and is free-to-download. A discussion of potential future uses will follow, including benefits, pitfalls and hints for others that may be interested in this emerging field.
The document discusses the Lean Startup methodology. Some key points:
1. Lean Startup advocates rapid prototyping and customer feedback to quickly test assumptions and evolve products faster than traditional methods.
2. It encourages frequent releases, often multiple times per day, to incorporate customer input through practices like continuous deployment.
3. A central tenet is reducing waste by increasing customer contact to test assumptions early and avoid incorrect directions. This aims to decrease the time to find product-market fit.
4. The document then provides an example story of a company applying Lean Startup tactics like prototyping ideas, using metrics to analyze customer behavior and decisions, and remaining flexible to change based on learning.
The document discusses how to prevent agile from becoming fragile. It identifies some common reasons why agile can become fragile such as lack of effective risk management and not extending agile practices to testing and deployment phases. It recommends using risk burn down charts throughout the project lifecycle, adopting automation best practices during testing and deployment, and maintaining interrupts in a separate "ops backlog" to prevent agile from becoming fragile.
Once you get done with an innovative app building idea, don’t delay further and get it developed at the earliest from iPhone app developers Washington.
I Love APIs 2015: MasterClass Developer Programs and Marketing WorkshopApigee | Google Cloud
The document outlines highlights from a masterclass on building successful developer programs. It includes estimated agenda items covering market trends, success stories, secrets of partner outreach, understanding developers, best practices for developer programs and marketing essentials. There are also exercises proposed for attendees to apply concepts to their own products and outreach efforts. The goal is to provide insights and frameworks to articulate value, engage with developers, and build strong programs and marketing strategies.
Andy Rachleff, Wealthfront Presentation at Lean Startup SXSW500 Startups
The document outlines 4 lessons learned from a company's first version of customer development. The lessons are: 1) Start simply with paper prototypes before building software; 2) Understand your product's most important attribute, which for them was simplicity; 3) Customer development does not require a designer, a "UX developer" is sufficient; and 4) It is okay if not everyone likes your idea, and you should be willing to take risks. The overarching lesson is that the discovery phase should focus on learning from customers and iterating the product, rather than perfect execution.
The document describes a network marketing company called Skinny Body Care that sells weight loss products. It states that everyone wants to lose weight and make money, and Skinny Body Care solves both problems. It then outlines the company's products including Skinny Fiber, Caralluma Fimbriata, and Garcinia Cambogia and describes the multi-level marketing compensation plan which includes fast start bonuses, residual income from a matrix, matching bonuses, and leadership pools.
This document provides an analysis of various file formats. It discusses how file formats can be structured, compressed, encrypted or a combination. File formats are also categorized as being open, proprietary, or generalized container formats. The document outlines why analyzing file formats is important for anti-virus protection, computer forensics, software development and more. It describes how to analyze file formats through specifications, reverse engineering, and observation. Tips are provided for coding unpackers and validators including security risks, practical problems, and using core libraries.
This document provides guidance on building a mobile app. It discusses prioritizing functionality, designing for mobile, engineering options like native vs HTML and cloud services, using tools like Asana for project management, and releasing iteratively using TestFlight for user testing before full launch. Contact information is provided for the author, Yossi, an experienced product manager and mobile app consultant.
This document provides guidance on building a mobile app. It discusses prioritizing functionality, designing for mobile, engineering options like native vs HTML and cloud services, using tools like Asana for project management, and releasing iteratively using TestFlight for user testing before full launch. Contact information is provided for the author, Yossi, an experienced product manager and mobile app consultant.
Slides from the "Much ado about Agile", Agile Vancouver Conference 2015. This talk is around examples of MVP on small startups and Enterprise level. What's the ultimate MVP?
Building a better User Experience for Windows Phone UsersSandra González
The document provides tips for improving the user experience of Windows Phone apps. It discusses focusing on metro design principles, ensuring ease of use by following platform conventions, making sure the app delivers on what is promised in its description, and specializing so the app excels at one thing. The author advocates testing apps through usability studies and advises developers to think about visual design, navigation, and how their app compares to similar options in the store.
Creating mLearning With Your Existing ToolkitChad Udell
People often think mobile applications only consist of dedicated software development tools and techniques used by traditional computer scientists that can often be arcane or require very specific tools and platform-specific APIs. And sometimes we must redevelop applications several times to hit all target platforms, which can be very time consuming and expensive. But most modern platforms are quite capable of providing very powerful and engaging experiences using Web based APIs and manipulating the DOM via Javascript. This may be a far more accessible toolkit for your development team and it could accelerate your development efforts.
This document discusses best practices for managing product releases and software engineering teams. It provides the following recommendations:
1) Establish clear processes for releases, including regular intervals, versioning, distribution, and metrics to measure success. Ensure everyone understands their role in the release cycle.
2) Use the Dreyfus model of skill acquisition to balance team skills and experience levels. Recruit for "smart and get things done" attitudes. Apply practices according to where the team stands.
3) Automate aspects like releases, reporting, and testing when possible, but also retain some manual processes to aid understanding of what to automate. Team learning takes time.
Kevinjohn Gallagher's: Emperors new clothes (WordUp Glasgow 2012)kevinjohngallagher
The document discusses responsive design and some of its limitations. It argues that responsive design is really about adapting to mobile rather than different contexts. While the goals of responsive design are good, it cannot truly account for all contexts and instead relies on screen size as a proxy. This leads to problems with things like images. The document concludes that responsive design alone is not enough and that information architecture must also be considered to properly adapt a site for different contexts beyond just screen size.
Trevor Perrry presented Implementing Modernization during the 2015 iBelieve tour. This presentation helps you analyse your modernization needs, strategies and suggests successful approaches for planning and implementing GUI, web, mobile and beyond.
Neil Perlin - We're Going Mobile! Great! Are We Ready?LavaConConference
In this session attendees will learn:
Technical options for going mobile, including responsive design, converting traditional online help to an app, and creating a “true” app using RMAD (Rapid Mobile App Development) tools. The pros and cons of each approach and some of the tools available for creating each option.
Anticipated changes in content creation practices and workflows including the elimination of local formatting, adoption of a “mobile first” philosophy, rethinking the role of tables, and more.
How company issues like terminology standardization, strategic benefit, politics, and the development of metrics and standards can help or hinder a move to mobile.
6 ways DevOps helped PrepSportswear move from monolith to microservicesDynatrace
Like a lot of online businesses today, PrepSportswear’s success is 100% dependent on the availability, scalability and performance of their digital online services. If the website is down, the business stops. They knew they had to transform their business from that of a retailer with a website to a high caliber IT company that sells products online.
In these webinar slides, Richard Dominguez, PrepSportswear’s Developer in Operations, shares their journey. They transformed from a team operating a monolithic app using waterfall development methodology on an old, hard to maintain code base, to a modern IT organization applying new practices from Agile development, DevOps and a Service-Oriented Architectural approach.
The Impact? PrepSportswear’s Most Successful Online Holiday Shopping Season in Company History! Join us to:
Learn how to identify if you are running a monolithic application that is dragging you down.
Get tips on hiring the right people to inject a DevOps cultural mindset into your organization.
Understand how to break the monolith into smaller pieces that support key lines of business.
Discover where to automate monitoring into your pipeline and platform.
Identify metrics for individual stakeholders (dev vs. test vs. business).
Go forward, celebrate, learn from, and repeat success!
Richard will be joined by Andreas Grabner, Performance Advocate at Dynatrace who will support why monitoring, application and end user metrics have to be a key part of your own transformation!
Richard Dominguez has 9+ years’ experience as both a System Analyst and Software Developer in Test. He has worked on many high profile projects in Microsoft such as Hyper-V, Windows 7 Client Performance, and Windows Phone Services. Richard now works at PrepSportswear as the company’s DevOps engineer. His responsibilities include site reliability, external synthetic testing, release management and overall site performance.
Andreas Grabner has 15+ years’ experience as an architect and developer in the Java and .NET space. In his current role, Andi works as an advocate for high performing applications in both the development and operations areas. He is a regular expert and contributor to large performance communities, a frequent speaker at technology conferences and regularly publishes articles blogs on blog.dynatrace.com
Basic overview of software test types, methodologies.
Explaining and reasons to test and common pitfalls with various testing methodologies.
Example scenarios for the viewer to think about test strategies.
Tips to avoid having to write tests in the first place.
Content created and presented by Nico Heidtke at the "Die Programmierer" meetup organized by Binary-Gears in Darmstadt, Germany at 02.07.2019.
Developing for Windows 8 based devicesAneeb_Khawar
This document provides an overview of developing applications for Windows 8 devices. It discusses the redesigned user interface in Windows 8 and modern applications. It outlines reasons for developers to create apps for Windows 8, including an emerging market, the Windows Store, revenue sharing terms, and Microsoft initiatives like DreamSpark and BizSpark that support students and startups. The learning curve is described as not too steep, especially for experienced developers, and Visual Studio is highlighted as a powerful development tool. Technical aspects like the application lifecycle and MVVM pattern are also briefly covered.
This document provides an introduction to C# programming, including why it is an important and versatile language, job prospects for C# developers, and an overview of the software development process. Key points include:
- C# can be used to build a wide range of applications and is in high demand with over 100,000 job openings and a projected growth rate of 22% by 2029.
- The software development process involves analysis, design, implementation, testing, and deployment of applications in an iterative manner using approaches like Waterfall or Agile.
- Becoming proficient in C# provides opportunities for well-paying jobs at many companies in roles like software engineer, developer, and more. Understanding programming fundamentals
The document provides advice for new developers on how to get started building mobile apps. It recommends starting small by building a mobile web app prototype instead of a fully native app, as mobile web apps are easier to develop, can access many native features, and allow developers to test ideas and tweak the app more easily. Once the prototype is complete, it can be expanded into a larger project, turned into a full native or hybrid mobile app, or used as a sample for testing. The document stresses answering questions about the app's purpose and users before designing, and offers tips for user interface and experience design.
Mobile media module part 6 - app development rev-mfMichelle Ferrier
The Mobile Media Module is designed as a two-week, broad-based study on the mobile landscape that can be applied in many courses.
The program was implemented at Ohio University’s Scripps College of Communication to support our Scripps Innovation Challenge and to build knowledge of the mobile landscape across our communication curricula.
For implementation, we brought in an expert in mobile development to teach in four existing classes over two weeks in Spring 2013. Faculty teaching those classes became the students and built their capacity to teach the material in subsequent semesters.
By “hacking the curriculum” using the “module method,” we were able to reach more than 500 students in one semester with new material.
For more information, contact Dr. Michelle Ferrier, associate dean for innovation, Scripps College of Communication, ferrierm@ohio.edu.
Nitobi was moving from products to services in 2007-2008 and faced a choice between specializing or remaining agnostic in their technology stack. They chose to remain agnostic and focused on being web-based. As mobile trends emerged, they began experimenting with mobile development which led to the creation of PhoneGap in 2008 to build mobile apps using web technologies. Since then, PhoneGap has grown significantly and Nitobi's business has evolved to focus more on services related to mobile development.
Fuel Good 2018: Upgrades Made Easy: The Canadian Museum of HistorySparkrock
The Canadian Museum of History upgraded their NAV and SharePoint systems without major issues by carefully planning and testing the project. They designed a new technical infrastructure, trained users, and conducted multiple cycles of user acceptance testing and remediation over several months. While there were inevitable bugs found during testing, taking the time for thorough preparation and testing helped ensure the upgrades went live smoothly without significant problems.
Developers should invest in 10 key skills in 2014:
1. Know a native mobile platform like iOS, Android or Windows Phone.
2. Know an agile development process and tools like Scrum, Kanban, or Extreme Programming using tools like JIRA, PivotalTracker or Trello.
3. Know how to effectively estimate tasks and leverage team techniques like story point estimation and velocity.
Specialmoves is a development agency that focuses on interactive experiences for web, mobile, and installations. They believe beautiful, user-focused designs make people happier and more productive. Working with developers better, faster, and cheaper requires having a clear vision and understanding user needs up front. The document outlines an Agile process for collaborating with developers, including defining user personas, prioritizing high-level user stories, acceptance criteria, and global standards to build the right features on time and on budget. Even Agile cannot fix problems like an absent or indecisive client.
Similar to Why do mobile projects (still) fail - September 2014 edition (20)
Choosing the Best Platform and Development Strategy for Your AppISH Technologies
Choosing the right platform and development strategy is crucial for the success of your app. By gaining insights into your target audience, including their demographics, device preferences, and engagement patterns, you can tailor your app to better meet their needs. Conduct thorough market research to analyze competitor platforms, gather user feedback, and stay ahead of industry trends.
Deciding between iOS and Android involves considering factors like market share, monetization options, and development complexity. iOS offers benefits such as higher average revenue per user and stringent quality control, while Android provides a larger global market share and extensive customization options. For many businesses, exploring cross-platform development solutions like React Native, Flutter, and Xamarin can offer the best of both worlds, ensuring efficiency and a native look and feel across devices.
To make these complex decisions with confidence, consult ISH Technologies, your trusted app developers in Brisbane. Our expert team will help you navigate the intricacies of app development, ensuring your app is optimized for performance, user experience, and cost-efficiency. Transform your app idea into reality with tailored solutions that meet your unique needs. Contact us today and let's bring your vision to life!
6. !
!
!
http://www.flickr.com/photos/cameronparkins/3220496811/
Thanks and enjoy the beers coffee!
7. 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
8. 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
9. 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
10. But often ..
“No matter what they tell you, it's always
a people problem.”
Gerald Weinberg (The secrets of consulting)
11. Why mobile projects don’t usually
fail
Because of bugs in the app
These have been identified and can be fixed
12. Additional challenges
• Challenges affect the different phases of
a mobile project
• Conception
• Finding resources
• Implementation & Testing
• Deployment
• Business
16. 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”
17. 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?
18. 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
19. 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!”
20. 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
21. Pro-Tip: Never trust someone who wants
to dictate a project’s deadline and scope
at the same time
22. 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
23. 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
24. 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
25. 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!
26. The challenge
How can we educate all project stakeholders
so that they know enough about the mobile
technology to make informed decisions?
28. 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“
29. 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“
30. Communication
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
31. 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
32. 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
33. 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
34. 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
37. 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”
40. 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 (!)
41. 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?
42. 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)
43. Pro-Tip
Stay ahead of any incoming technological
changes (new OS etc.)
Even if you have to “wing it”
44. 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
45. 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)
46. 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
47. Choosing resources
• You’re looking for a Web developer
• Pretty straight-forward
• Frontend: HTML, JavaScript, Responsive
Design
• Backend: PHP, Node.js, Ruby on Rails
48. Choosing resources
• You’re looking for a “mobile
developer”
• Say what?
• Do you mean Android? iOS? Windows
Phone? HTML 5? Or all of those?
49. 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
50. 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
52. 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/
53. 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)
54. 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”
55. 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
57. 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/
58. 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!
60. 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?
61. 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
62. 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!
63. 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
!
!
!
65. 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”
66. 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
67. 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?
68. 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)
70. Mobile browser usage
source: http://www.quirksmode.org/blog/archives/2014/01/browser_stats_f_7.html
71. 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?
72. 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
73. 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
74. 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?”
75. 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/
76. 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
77. Testing
Pro-Tip: Make sure you know which
device your boss / customer is using -
and test first on that one
78. 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
79. 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?”
81. 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)
82. 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.
83. 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
84. 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?”
86. “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)
87. 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
88. 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
89. 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/
90. 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?
91. 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
92. 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
93. Before you get too excited
!
!
!
!
!
!
• http://www.phonearena.com/news/The-average-global-smartphone-user-has-downloaded-26-apps_id47160
(Sept 2013)
95. Auch in Deutschland
http://netzoekonom.de/2014/08/31/zwei-drittel-der-deutschen-laden-keine-apps-mehr-herunter/
96. 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
97. 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
98. 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)
99. 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
100. So to summarize ….
• An example list of things that went
wrong…
101. 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
102. 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
103. 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/
104. 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/