PEARL XX :
Agile Methodologies are best fit for Mobile Software Development
Introduction
The adoption of increasingly advanced mobile devices has inherently changed consumer and business expectations of communication and access to information. Because of technology built into mobile devices that collects data about user behavior — data not available through traditional desktop forms of computing — the expectation of what an application can offer is also evolving and becoming more sophisticated. As behavioral input affects application development and, in turn, user expectation, the consumer and business market will continue to migrate to and ultimately depend on mobile computing,
currently a technological genesis of possibilities.
As mobile computing becomes more pervasive it is necessary for any company to explore its mobile options and determine what advantage they offer to the business and its customers, as well as the cost and potential return. This is a continually shifting landscape affected by multiple — and sometimes seemingly disparate — variables including, but not limited to:
- Development across multiple platforms, each with separate operating systems in various stages of market adoption and functioning on devices created by a number of companies, and each with their own specifications and digital functions
- The advantage of developing native applications versus less expensive mobile web applications
- Identification of who currently has — and anticipating who will have — competitive dominance in the marketplace, from device manufacturers to service providers; can be as basic as looking to trends in the market and projecting based on current consumer adoption of specific devices, or as complex as identifying who controls content such as film and television series license rights, partnership opportunities for digital, cloud-based distribution and how the limited threshold of consumer entertainment spending will affect device adoption based on content distribution investment in the right functionality, by identifying what technology is going to jump the gap from conceptual development to mainstream adoption
- Environments provided to developers to create and distribute applications. For example, Apple dominated the market when it opened the floodgates by allowing almost anyone to develop and release apps to its store, but created a restrictive approval process. Android has been even more flexible and forgiving with its development environment, which may be in part why it has surpassed Apple in the market. Conversely, Blackberry has suffered from an unfriendly environment in which to develop.
These are just some of the considerations affecting the world of mobile computing, but the common denominator to all of these is the variable of continual change. And change happens quickly. For a company to embrace the opportunity and overcome the challenges presented by mobile computing, it must consider change as an expected variable and develop applications accordingly.
One aspect of the mobile market that allows a business to manage this variable is the downloadable distribution of applications. A newer or updated version of an application can be distributed and updated frequently. In this respect a new version of the application designed around changing variables can be released to the market as often as necessary. This also allows for the opportunity to bring an application to market more quickly, by breaking down its expected functionality, prioritizing it and gradually building it into the application through various version releases over time.
Employing Agile Development Methodology during the construction phase of applications allows for an iterative approach to development; small builds of each feature can be created through short sprints that can be tested for quality assurance and then integrated or re-built.
The iterative spirit of Agile should be extended into the entire application development cycle to allow all accompanying design and technical documentation to respond and evolve from each feature build to each complete version release of the application.
This is accomplished by establishing a methodology that carries through the inception and elaboration phase of each version release, complementary to the Agile methodology used in the construction phase, that allows for evolution. Utilizing an Adaptive Methodology, each version release of the application is developed and built upon
the last version, while both capturing the design intent of the previous version and incorporating new data, stakeholder concerns, metrics, Agile construction, and QA, technical and design considerations (the change variable) into the updated version
Research Literature
One of the pioneering studies in agile approach is by Abrahamsson where it was assessed that agile development solution provides a good fit for mobile application development environment and proposed a new approach called Mobile D. A new architecture concept called Architecture Line has also been introduced that aims producing an application framework, which guides the development of future mobile applications.The Architecture Line in the methodology is a new addition to the already established agile practices. An architecture line is used to capture an organization’s knowledge of architectural solutions, from both internal and external sources, and to use these solutions when needed.
The successful development of mobile applications is challenged by several of software’s nastiest development and deployment landmines – rapidly emerging standards, volatile platforms, intermittent connections, varied devices, and inconsistent user-interface and input technology. Unfortunately, not only does the infrastructure pose a threat to successful deployment, the sheer volume of potential users and growing demand for accelerated delivery exacerbates potential risks. To the average mobile phone user, what often appears to be a simple, easy to navigate application, very likely means the company producing the application went to great lengths to deliver a reliable solution. Without such efforts, mobile users would end up with a multitude of platform-specific customization’s and one-off solutions, not to mention, a constant barrage of patches and updates. To keep development costs down and ensure high-quality software, mobile application development organizations must approach software development with a commitment to internal efficiencies. As a result, many of today’s most successful mobile application development organizations have transitioned to iterative and incremental delivery methods just to keep up with the rapid pace and constant change inherent in the industry.
Mobile-D approach is based on Rational Unified Process RUP (life-cycle coverage), eXtreme Programming XP (development practices) and Crystal methodologies (scalability).
Abrahamsson . have demonstrated the traits which reasons why agile technologies fits best in mobile software development. The various issues includes, high environment volatility, small development teams, identifiable customer, object- oriented development environment, non-safety critical software, application level software, small systems and
short development cycles.
Working software has been given a focus over comprehensive documentation; however the required documents should be identified and documented. Dooms has proposed a method called ‘RaPiD7’ (rapid production of documentation, 7 steps) that improves the documentation work without scarifying the quantity and quality of documentation . RaPiD7
describes how human interaction is planned in software projects and how documents are to be created in facilitated workshops.
Rahimian and Ramsin presents a different approach to the Mobile-D. They proposed a hybrid Agile and risk-based methodology that generates a method suitable for mobile application development designed from Methodology Engineering techniques.
This is a discipline concerned with creating methodologies suitable for different development scenarios, motivated by the belief that no single process fits all situations. It is based on a combination between agile methodologies, Adaptive Software Development (ASD) and New Product Development (NPD).
The ideal mobile software development characteristics that the hybrid engineering
methodology is based on are: agility, market consciousness, software product line support, architecture-based development, support for reusability, inclusion of review and learning sessions, early specification of physical architecture. The Hybrid Methodology Design process has been developed as a top-down, iterative-incremental process comprised of the following tasks: prioritization of requirements, selection of the design approaches to be used in the current iteration, application of the selected design approaches, revision, refinement and restructuring of the methodology built so far, defining the abstraction level for the next iteration, and finally the revision and refinement of the requirements, prioritizing them for the next iteration.
Jeong proposed the Mobile Application Software Agile Methodology (MASAM) that provides the process for developing the mobile applications swiftly using an agile approach. It is based on Extreme Programming (XP), Agile Unified Process, RUP and
the Software and Systems Process Engineering Meta- model (SPEM). It is GUI based architecture-centered that uses Agile approaches for rapid development and utilizes domain knowledge. MASAM shows a strong tie with the Mobile-D methodology and introduces slight variations, such as a project management and follow up tool coupled with Eclipse Process Framework.
Cunha proposed SLeSS; an agile approach integrates Scrum and Lean Six Sigma (LSS) that focuses on project management and process improvement respectively. The approach uses two types of product backlogs, Customization Product Backlog (for customizing development projects) and LSS Product Backlog (for process improvements).
The product backlog is an ordered list of requirements that is maintained for the product. It consists of features, bug fixes, non-functional requirements, etc.—whatever needs to be done in order to successfully deliver a viable product. The product backlog items (PBIs) are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.
Items added to a backlog are commonly written in story format. The product backlog is what will be delivered, ordered into the sequence in which it should be delivered. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the items on the backlog for the Development Team to choose.
The product backlog contains the Product Owner’s assessment of business value and the Development Team’s assessment of development effort, which are often, but not always, stated in story points using a rounded Fibonacci sequence. These estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items;
The product backlog and the business value of each backlog item is the responsibility of the Product Owner. The size (i.e. estimated complexity or effort) of each backlog item is, however, determined by the Development Team, who contributes by sizing items, either in story points or in estimated hours.
Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”. It challenges assumptions of the “traditional, sequential approach” to product development. Scrum enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members and daily face to face communication among all team members and disciplines in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
A sprint (or iteration) is the basic unit of development in Scrum. The sprint is a timeboxed effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, although two weeks is typical.
Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and-retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.
Scrum emphasizes working product at the end of the Sprint that is really “done”; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable.
The SLeSS approach has been used in real embedded software customization development projects for mobile phones. The approach was experimented in P&D&I laboratory, with a mobile phone manufacturer as a client with team of 7-12 developers, in duration from 4-6 months, with average size of 529 LOC (Line of Code) developed in ANSI C programming language.
Agile development is an umbrella term used to describe several popular, highly iterative software methodologies such as Extreme Programming (XP), Feature-driven Development (FDD), Lean Development, Adaptive Software Development, Scrum, and Crystal. Although each methodology may employ certain unique practices and principles, they all focus on business value, adaptability, high customer involvement, and the frequent delivery of production-quality software. Agile methods have gained popularity, especially in the last few years, as companies have come under increasing pressure to accelerate delivery in the face of changing requirements and rapidly evolving technology. Applicable to a broad spectrum of today’s software projects, these agile approaches have gained tremendous industry momentum due to their overall simplicity and discipline.
Companies such as Sabre, Sprint, Nortel, Symantec, Fidelity, Borland, Qwest, and hundreds of other leading technology and software organizations have begun employing agile development methods with considerable success. Many transitioned from more traditional methodologies and processes that had become too heavy and bureaucratic to remain competitive, and many others have simply transitioned from a little to no defined methodology. In the case of the latter, these companies knew they could not move to a more traditional software methodology without risking their ability to rapidly adapt and deliver.
Demands of Mobile Development
Development organizations and teams that build mobile applications are challenged with their own unique array of complexities. Unlike traditional client-server and web-based software development shops, mobile developers are faced with very strict boundaries (memory, screen size, input devices, etc.), short application lifecycles, and extreme usability requirements. These are in addition to the inherent environmental volatility previously referred to. Given such constraints and challenges, mobile application developers have had to become very quick on their feet in dealing with all of the variables in the development and deployment lifecycle. As a result, most have transitioned to an extensive use of emulators, test automation, automated deployment processes, and shorter development cycles. The use of platform enablement application development software from vendors such as AppForge (http://www.appforge.com) and Metrowerks (http://www.metrowerks.com) has also eased some of the development burden.
The Agile Advantage
Due to the demands associated with rapid delivery and volatile infrastructure, the overhead associated with many traditional development methods often cannot be tolerated within the mobile industry. Mobile developers generally don’t have the luxury of spending 60% or more of their development cycle on efforts and artifacts not associated with working software. With the constant changes in technology and requirements, they also cannot wait until the end of the development cycle to initiate the testing and verification process. Similarly, because of the extreme demands for quality across a broad spectrum of devices, platforms, and users, an ad hoc development approach does not result in very positive outcomes, at least not for long.
The practices and principles of agile development, on the other hand, align well with the requirements of mobile development teams. The commitment to simplicity, low overhead, business adaptability, rapid delivery, and customer feedback complement the needs of mobile development. Agile development techniques help maintain a strict focus on delivering the highest business value as soon as possible, while at the same time identifying and addressing technical risks as early as possible. Relatively painless to implement, agile development methods also help ensure minimal overhead and bureaucracy in the development lifecycle. Agile development methods favor lightweight, continuous planning as opposed to detailed, long-range planning simply for the fact that, especially in the world of mobile development, change occurs too frequently. Agile development’s commitment to the delivery of working, tested software at frequent intervals (generally between 1 and 4 weeks) ensures much greater reliability and opportunity to incorporate user- and technology-driven feedback.
With several of the engineering practices promoted by Extreme Programming such as refactoring, simple design, test-first development, automated unit and acceptance testing, and continuous integration, a team can begin to implement an internal infrastructure that is capable of rapidly responding to all types of change. Incorporating some or all of these well-known best practices can help teams implement highly efficient, well-tested applications across the required spectrum of platforms and devices. For mobile development teams looking to introduce a lightweight development process or scale back more bureaucratic processes, agile software development offers tremendous opportunities and value. In the face of both a rapidly changing business and technical environment, agile development’s continuous focus on ensuring alignment between business and technology is of critical importance. And not only does the value of continuous user involvement benefit the functionality and usefulness of the software, but the development rhythm of producing production-quality software every few weeks helps ensure a team’s ability to delivery more predictably, deploy more confidently, and change direction more easily in today’s unpredictable environment
Agile mobile development enables thoughtful user experiences.
Mobile apps run in limited environments, and there are restrictions placed on the size of the app that can be downloaded initially or later on, in updates. If the app takes more than a couple of minutes to download, the user may delete the ongoing download and move on. There are also restrictions on how much application data can be downloaded ahead of time and stored locally. Agile development allows developers to experiment with these options in subsequent sprints and adjust the design and features of the app in such a way that the user experience is quick, smooth and seamless.
Agile mobile development enables phased roll out of feature sets.
Click to Enlarge
Self-contained apps like single player games need to be compact, and usually do not communicate back and forth with any back-end server. However, many serious consumer-facing apps need this back-end server access periodically (weather-related apps, airline apps showing flight status, travel sites, etc.) They face the constraint of having enough meaningful features and not overloading any one app with too many features. Clever app designers spawn additional apps when one app gets too big with too many feature sets already. Agile mobile development helps organizations adjust their designs, and scale back on features, if necessary, with subsequent sprints.
Interface and Interaction Design
In the Agile Mobile Application life cycle, After analyzing the project’s business goals the team work on test scenarios of its uses, creating UI / UX wireframes for each screen of the app, conduct user-tests with target users and come up with a solid vision of the app interface and layout.
Learning Loop
When the mobile app is ready, it is only a beginning. Now is the time to monitor its uses and the use of key metrics that were selected during the design phase. All of these are filled with useful information, which will be used to improve the product and the release of the second version. The product is alive and it must live and improve all the time. And the cycle of Build-Measure-Learn should be repeated constantly.
Here are Agile stages for a mobile development project from discovery to completion:
- Discovery
- Inception
- Weekly Sprints
- Milestones
- Exec demos
- Architecture review
- Static analysis tools
- Security review
- Platform retrospective
- Feature freeze
- Design QA
- Release candidate and QA
- Ship to app store
- Project retrospective
Mobile computing growing exponentially. Gartner forecasts that by the end of 2014 over 185 billion apps will have been downloaded from mobile app stores since the launch of the first one in 2008.
Adaptive Agile Mobile Application Development
When looking to move into the mobile computing space, it is tempting to identify a quick fix or easy entry by just developing an app and posting it to a store. Though this exercise can be good from an informational or conversational standpoint, because of the quantum change affected by mobile computing, it is better to consider a longer term program which may be comprised of a number of apps, both consumer- and business-facing; in other words, a complete mobile solution. The foundation of developing an adaptive application is approaching it as part of a complete solution.
Mobile solution gives insight into a number of other factors that may affect individual application development, such as:
- How application development concerns, and is needed by, multiple stakeholders within a company, including executive level, marketing, sales, IT, distribution, manufacturing, etc.; each of these stakeholder’s needs are often accessing or sharing similar data and functionality that may need to be coordinated in both a macro and micro sense
- Different stakeholders may need to develop different applications that must work together, from brand consistency to optimizing development resources
- Integration with existing enterprise systems and enhancing those systems with new data
- Identification and gathering of metrics to determine design, function and return on investment of the application
- Maintenance and optimization of application performance from the back-end to front-end
- Security of data across the entire enterprise
- Machine-to-machine communication beyond the enterprise and mobile device market
- Coordination with external agencies and other service providers.
When a company approaches the development of an application or multiple applications it should employ a complete Mobile Solution Approach. The first step in creating the approach is capturing the types of applications proposed for development and how they relate to each other based on various factors affecting development.
Creative Design Process
A complete Mobile Solution Approach is essentially an adaptable roadmap detailing the development process from concept to delivery. Because of the dynamics of the marketplace and the varying factors that affect mobile development, every mobile solution is going to be unique to each company. A complete mobile solution needs to maintain a flexible documentation structure. In order for this documentation to remain adaptable to change, it is produced and maintained through systems typical to the Creative Design Process.
The goal of the Creative Design Process is to capture as much information and as many ideas as possible, quantify the captured information to produce documentation, and confirm the documentation through additional collaboration and research. Confirmed and finalized documentation is used to establish the next iteration of documentation. The process of establishing final design documentation for deliverables is handled in an iterative and agile manner.
Documentation is produced in steps and each step of documentation is used as a proof, or build, to qualify and establish the next step. Most documentation evolves from draft to final. Each final document exists as an editable, evolving document that is tracked through version identification. Each step of the documentation is created using the Creative Design Process.
The first step in creating a mobile solution is developing a core Understanding of Feature Catalog of a company’s needs and desires. This begins with capturing and organizing information provided by clients from the beginning of the sales process, to exist as a benchmark influencing the entire development. Once an Understanding of Feature Catalog has been established the information is used to create a Predictive Design Map that establishes development from foundational needs to aspirational desires. Typically, applications in the mobile market are updated periodically. This allows for the opportunity to define the foundational function of an application and bring it to market in a timely manner, adding functionality in later version releases. The Predictive Design Map details broad functions of each version release of the application prioritized and broken into a time line. The Predictive Design Map is incorporated into the Mobile Solution Approach that maps a phased approach to assessment, optimization, translation and functions of the mobile architecture including:
- KPIs
- Adoption
- Optimization
The Mobile Solution Approach also includes the Application Design Document, comprised of an Executive Summary, a benchmark overview of each application and a Maturity Map, a detailed account of the functions of each version release and the steps involved in bringing it from Elaboration to Release. Once a Maturity Map has been established, the initial design documentation detailing the application can be created, including flows, wire-frames and mock-ups. After the initial design specifications have been established and to maintain the application’s adaptive nature, the Predictive Design Map is open to change over time and version releases of the application. It becomes the basis of an Evolving Design Map that defines the future versions of the application.
Concurrent to creation of the Mobile Solution Approach, the development of the application begins utilizing the Agile Development Process. The Agile Process allows for the creation of usable iterations of the application, or builds that can be tested for QA. Data from QA is used to modify the next iterative build. Agile employs its own documentation, which includes User Stories, short descriptive statements captured as user functionality desires, and a Project Backlog, a functionality list that is intended to be built into a version release of the application. Each version release of an individual application detailed in the Application Design Document is developed using the Agile Process.
Agile creates an environment that allows developers to quickly turn around usable builds of an application’s functionality. This is done by breaking the application into iterations that are developed over one- to two-week sprints, a short development cycle typified by daily “Scrums,” a short meeting where developers review the progress on their current task. To determine what is going to be developed during each sprint, the team developing the application establishes a number that represents the amount of production that can be accomplished during the sprint, assesses the user stories and collaboratively prioritizes and agrees on a numerical degree of difficulty each user story represents. Numerically these considerations are weighed against the amount of work possible and negotiated among development team members to establish an individual sprint story list. Each version release of an application is collectively comprised of a few iterations.
Android Development Methodology
The Adaptive approach to application development integrates and complements the Agile Development Process. Content and information can be shared between the two, influencing and completing one another. For example, information from the Predictive or Evolving Design Map can be used to establish Initial User Stories. On the other hand, as the project progresses, the Agile Features Backlog can be used to populate the Maturity Map. Based on the Mobile Solution Approach, each application is considered a continuing and constantly evolving product, which changes through each new version release. With the release of each new version, the vision of the product needs to be assessed, and features and functions need to be re-evaluated and updated. There are a number of factors affecting this evolution between versions. Some of these factors need to be anticipated, documented and captured in the Maturity Map, as well as built into the development of the application. Metrics need to be identified to quantify user behavior, which will affect the design of the next version release.
The tools to measure these metrics need to be developed into the application. Performance of the application needs to be measured across the entire application delivery chain so it can be optimized. Security measures need to be addressed and built into the application. The measures may need to be enhanced based on the changes in user behavior. Back-end systems with which the application interfaces need to be assessed and incorporated into the development with any necessary enhancements or changes. The development and adoption of other concurrently developed applications must be detailed in the Mobile Solution Approach. Other external factors will need to be evaluated and incorporated into the design and development of each version release,
including:
- Changes or adjustments in KPIs — based on the market — the business or consumer is addressing with the application
- Opportunities to enhance functionality based on technological advancements in the hardware market business changes in the mobile market including the public adoption of one device over another
- Changes in software development practices and systems
- Changes in legal issues such as privacy maintenance
- Amendments or adjustments to development environments managed by each mobile provider and its respective digital distribution systems.
Though some of these factors can change during the development of an application and incorporated into the design dynamically, they are typically incorporated into the design during the Assessment, which encompasses the Vision, Inception, Elaboration and Support phases of version release. The Assessment of each new version release begins at the end of the previous version. Incorporating the information, metrics and influences identified during Assessment is a cornerstone of the Adaptive Methodology and its ability to create a responsive, evolving application.
University of Missouri Health Care and University of Missouri Information Experience Lab – Case Study
This case describes the agile management methods for an iPhone software development project. The overall objective was to design a smartphone solution that allowed surgeons access to dynamic Electronic Health Record (EHR) data to optimize their workflow. Three separate organizations distributed the responsibilities. Specifically, the lead organization, Cerner Corporation, collaborated with the University of Missouri Health Care and University of Missouri Information Experience Lab to create the technology. Project goals included increased surgeon satisfaction; improved task efficiency, as measured by time spent retrieving lab and vital sign data on morning rounds; dynamic data accessibility; and increased revenue from new product sales.
To accomplish these goals, agile project management was utilized, applying iterative usability methods to create deliverables within a short development cycle. Each development cycle focused on user-centered design principles. Several challenges were encountered related to the user-centered design methods, usability data extraction, academic collaborations, and interface design choices.
Pearls of Wisdom 