Global consumer demand for mobile applications dramatically increased from 400 million to 1.8 billion in just a matter of eight years. The landscape has radically changed since the first smart phone, equipped with only a calculator, world clock, calendar, and contact book, was introduced by IBM in 1993. Now, customers spend 90 percent of their digital time using mobile apps and only 10 percent browsing websites. An average user also downloads about nine applications per month and are satisfied with them only 55 percent of the time.
The relatively low mobile app satisfaction rating communicates the gap between what developers see as valuable and what customers actually find useful. This reality is also reflected by the state of overall software development landscape wherein only 10-20 percent of software projects are considered successful and over 50 percent of an app’s features are never used.
The definition of project success has been primarily centered on the perspective of IT project management – delivering on time, in scope, and within budget; rather than on the overall business value brought upon launch. This pressing concern has been repeatedly stressed because the fact is – requirements do change during development. And if the development team refuses to adapt and accept this pivot, chances are the finished product will not be as valuable as sponsors expect it to be once it hits the app store.
Worry Driven Mobile App Development
The problem with a traditional mobile development approach rests on a dominant industrial model known as the Taylorist-conviction. This states that “workers can’t be trusted to undertake intelligent and creative work. They are expected to only carry out executable tasks. Therefore, their work must be planned by more senior staff.”
In effect, a so-called worry driven development permeates management wherein all requirements of a mobile application project are defined upfront, accepted, and locked-in. Primarily an anti-pattern, death by planning is a state where experts gather to design everything in isolation with the assumption that nothing will change throughout the development process. In effect, when faced with changes, project managers invoke a strenuous change request process in which its primary goal is to resist, rather than adapt to produce an application that’s aligned with the most recent business strategy in mind.
So, What Exactly is Scrum?
Scrum is a framework that promotes adaptation to change. It’s designed to allow teams to create and sustain complex software products through self-organization following Agile values such as transparency, inspection, and adaption. Created by Jeff Sutherland and Ken Schwaber in the early 90s, Scrum was publicly introduced during the 1995 Oopsla conference in Austin. The concept was adopted from a 1986 paper entitled “The New Product Development Game.”
How Is Scrum Different?
Unlike the Waterfall methodology, which assumes that everything can be identified and planned at the beginning of the project, Scrum acknowledges that software can be unpredictable.
In 2009, Agile frameworks such as Scrum crossed what Geoffrey Moore called the “chasm” – or a period wherein after a technology has undergone a period of stagnation, it eventually dominates the market and is very difficult to overthrow.
Since then, Scrum has become the most widely adopted Agile framework followed by Dynamic Systems Development Method (DSDM) and Extreme Programming (XP).
According to Gunther Verheyen, Scrum’s goal is to “optimize and control the creation of valuable software in turbulent enterprise, organizational, business and market circumstances.” It operates based on principles of transparency, inspection, and adaptability allowing the creation of complex software products in a very short span of time. The ultimate goal is to deliver a minimum viable product (MVP) through creating a potentially shippable working increment every 20 days (otherwise known as the Sprint).
How Do You Start with Scrum for Mobile Development?
When developing mobile applications using Scrum, a team must be staffed with three roles – Scrum Master, Product Owner, and Development Team.
Figure 2: The Scrum Game Board (Verheyen, 2013)
The Scrum Master teaches, coaches, and mentors the Scrum Team together with the organization in understanding, respecting, and learning how to manage using the Scrum methodology. This person makes sure that any elements hindering or blocking the development team are removed.
The Product Owner, on the other hand, is a representative from business that effectively communicates the product vision of all its stakeholders, both internal and external, to the development team. This person creates and prioritizes a Product Backlog according to the business’ values. The Product Backlog may contain both functional and non-functional requirements, enhancements, fixes, patches, ideas, updates, and other requirements.
The last role is the Development Team, which is composed of six to nine team members who are cross-functional and self-organizing. In a mobile development project, this could be your Java or C# developers, quality control analysts, business analysts, solution architects, infrastructure network specialists, etc. This team creates a potentially shippable working increment every 20 days with regular guidance from the Product Owner.
How Do You Effectively Execute Scrum?
Every event in Scrum is in a time-box. The fixed time and duration minimizes risks and allow early feedback from the customer, ensuring that the product increment is still in line with the business strategy, hence maximizing overall value. The entire Sprint should not take more than four weeks.
Scrum starts with Sprint Planning. It is a time-boxed event of four hours for every one-month Sprint. This is a venue where the Product Owner shows and explains a prioritized Product Backlog to the Development Team. Consequently, the team pulls Stories from the backlog and breaks them down to smaller tasks, creating a Sprint Backlog. In four weeks, the team will spend time developing an increment following its agreed upon definition of “Done,”
During this four weeks, the team conducts a Daily Stand-up Meeting. This is time-boxed to 15-minutes, and is a venue for the team to plan their daily work, clarify requirements to the Product Owner, raise impediments to the Scrum Master, identify integration concerns (for multiple Scrum teams), and give a quick status of what they completed the previous day.
Figure 3: Overview of a Scrum Sprint (Verheyen, 2013)
Before the time-box expires, the Development Team conducts a Sprint Review and asks the Scrum Team to demonstrate to the Product Owner and other stakeholders the current build before figuring out what to do next. The review takes no more than four hours for a one-month Sprint. The last Scrum event is called the Sprint Retrospective. It doesn’t last more than three hours and aims to inspect the current process. During this time, the team reflects on what they did right, what they did wrong, and identifies how to change and improve.
Maximize Business Value with Scrum
Demand for mobile applications is steadily rising. Despite the multitude of products in the market today, only a few of them are actually useful. In fact, 25 percent of installed apps are never used and 26 percent of them are abandoned after customers’ first try. Scrum is a framework created from the principles of agility. It allows mobile developers to create a product that maximizes business value through close coordination with stakeholders. By shifting the development approach from Waterfall to Agile, you can pave way towards leaner and more useful mobile apps that customers will find valuable.