Collaborate or Lose Out: Working Together to Win the Mobile Payments Race

The role of agile development methodologies in the adoption of standards in mobile payments technology.

Mobile payments are set to be the most disruptive banking trend in 2014. Recent announcements include US transit networks gearing up for mobile payments, five UK banks signing up for mobile payments with Zapp and Indian mobile companies set to offer bank-like payment services. However, with the global roll-out of mobile payment services comes uncertainty for both banks and consumers, and this is evident in the lack of standardization in mobile payments technology. Financial institutions are facing a major dilemma. When planning mobile payment services, they need to select one of the available technologies in the hope that it will become the dominant standard, or they risk being left behind.

So how can these institutions ensure that they are not backing the wrong horse? Accepting that change is inevitable, and retaining the flexibility to change approach mid race is key to developing a winning mobile payments strategy. This is where institutions adopting agile software development will have the confidence to develop and release new payment services rapidly, without any negative impact on the quality of their service and customer’s experience.

[For More Mobile Payments Coverage, Check Out: Mobile Payments Heat Up in Canada]

1.1 Mobile Payments Need Agile Development

With any new technology, early attempts to generate revenue can involve high risk strategies. Today, there is a lack of concrete mobile payment success stories from both a technology and, perhaps more importantly, customer behaviour point of view. In these circumstances, agile methodologies protect organisations against the consequences of adopting the “wrong” technology, by supporting small lightweight releases that are ideal for testing a business case or theory with real users. After all, user feedback is invaluable in assisting with decision making.

Agile development and quality go hand in hand, and quality is essential to innovation. In the highly innovative mobile payments sector, the value of quality and testing becomes critical in ensuring trouble free service rollouts. Both developers and testers work side by side and take responsibility for project success, and testing is introduced early on in the software development lifecycle. In many institutions, this collaboration is supported by automated test frameworks, which provide code quality information that gives business stakeholders the confidence to release products to the market. It also arms development teams with the necessary confidence to make changes, even where the risk is perceived to be high.

1.2 Adapting for a Successful Mobile Payments Strategy

Developing software for the mobile market is a demanding task and vendors need to adapt as mobile devices, platforms and operating systems evolve at an unprecedented rate. Whilst some impressive banking and mobile programs have been successfully delivered using the waterfall development methodology, this approach is best suited to predictive projects. If the work involved in a project can be defined up-front and nothing much is likely to change, then this step-wise and plan-driven process has its place. An alternative to a waterfall approach is more appropriate in the mobile payments space to decrease development costs, increase deployment frequency and to continually drive-up quality. Where projects are more innovative and contain elements of team exploration to satisfy customer requirements, specifications are likely to change frequently, a more iterative approach to development has a greater likelihood of success.

1.3 Agile vs. Waterfall Development for Mobile Payments

A 2012 report by industry analyst Voke – Market Snapshot: Agile Realities - provides details on the types of software projects that are more likely to succeed with agile. They include smaller projects, custom-development projects and Web applications. Today, these are exactly the types of project that financial institutions are undertaking in mobile payments. To illustrate how agile development benefits mobile payments, we consider how four major financial institutions have locked horns in the battle to provide the universal standard for mobile payments worldwide:

Bank A: Uses agile development methodology (Scrum) and has well-established agile practices, including test-driven development, specification by example, test automation, exploratory testing, impact mapping and more. It also benefits from a first-to-market advantage, a customer base that understands the value proposition, and marketing that accurately matches the delivered product. The product gains traction and exceeds ROI expectations thanks to meeting quality and customer expectations. While competitors struggle to launch products, regulatory discussions begin. The product is well represented by high quality ‘living’ documentation. The underlying software becomes the template for standards worldwide, and other financial institutions have the option to either pay Bank A for its technology, or innovate to meet standards without infringing its patents.

Bank B: Also agile, with similar processes and practices to Bank A, essentially, Bank B was slower to enter the race, and narrowly lost the battle to hold the standard. However, its strong agile processes and practices enable the bank to react rapidly when the standards are defined. Bank B quickly finds innovative ways to adhere to standards without infringing Banks A’s patents. It quickly releases a strong rival offering, without impacting quality, and so maintains a healthy market share across the world. In countries where Bank A is less active, Bank B’s product is the outright winner.

Bank C: This bank uses waterfall methodology and has strong processes. This bank defined a positive product offering 12 months ago, but released it two months later than planned due to issues with project timescales and quality. Unfortunately, this left Bank C with a product that was heavily invested in, didn’t meet the needs at the point of release, and failed to win consumer support. Regulators quickly dismissed this product - unfortunately, documentation failed to accurately describe the final release, and how it would meet critical security and communications expectations. Bank C finds itself in the position where it must either undergo another significant waterfall project to develop another product; pay Bank A for its technology; or invest heavily in changing its development model. 14 months+ of investment and development are effectively written off.

Bank D: This bank has poorly defined processes. It claims to be agile, but in essence uses Agile as an excuse to minimize documentation and planning. Bank D manages to deliver a promising product at the same time as Bank A, but as it is not well understood, is plagued with defects and documentation is essentially non-existent, this product fails to deliver sustainable value to consumers. Bank D reacts quickly when regulation is defined, but uses the same delivery approach as before and suffers the same problems. Ultimately, Bank D has to pay Bank A or Bank B to use their technology.

1.4 Conclusion

In a chaotic and quickly evolving mobile payments market space, requirements for customer applications are changing minute by minute. This is driven by technology advances, end user expectation and by vendors seeking niche USPs. Only as the market starts to mature, will it be possible to establish where the highest value propositions will be found, and so the pioneers in this field must build solutions in a way that enables them to gain rapid feedback from the market and to respond quickly when trends start to appear. Without a development methodology designed to embrace – even welcome – those evolving trends, whilst still maintaining industry leading quality, there is a very real risk that the wrong product will be delivered late and to a market that is no longer there. Organizations that are embracing agile wholeheartedly, and this usually includes a significant culture change program, are better able to deliver the right product at the right time. Experience shows us that the key goals for these organizations should be; executable specifications; flexible automation frameworks providing the most appropriate coverage at the most appropriate levels; and fully integrated development and test processes with continuous delivery, continuous improvement and defect prevention concepts at their core.

Jerry Stubbs is an associate director, and Paul Wilford is a principal consultant, at SQS Group Ltd., a software quality specialist.