Be agile or lose out if you want to win the mobile payments race. Discover the role of agile development methodologies in the adoption of effective and risk free mobile payments technology.

The banking industry is rushing to implement systems for mobile payments – recent announcements include the UK nationwide launch of Paym, five UK banks signing up for Zapp’s mobile technology, US rapid transit networks gearing up for contactless card payments and Indian mobile companies set to offer bank-like payment services.

The mobile payments space is disruptive – and one of the major upheavals in banking for 2014. There is uncertainty for both banks and consumers, evident in the lack of standards for mobile payment platforms.

Financial institutions are facing a major dilemma. They need to select one of the available mobile payment technologies in the hope that it will become the dominant standard, or risk being left behind.

Doing so quickly to minimise that risk is essential – and it is a clear opening for agile development. Agile methodologies protect against the consequences of adopting the “wrong” technology, by supporting small, lightweight releases that are ideal for quickly testing a business case with users. 

Agile development and quality go hand in hand: developers and testers work side by side and take responsibility for project success, and testing is introduced early on in the software development lifecycle. This collaboration can be supported by automated test frameworks, which provide information on quality that gives business stakeholders the confidence to release products to the market. It also arms development teams with the confidence to make changes, even where the risk is perceived to be high. 

An alternative to agile is waterfall development, which has delivered some impressive banking and mobile systems, but mostly when a project can be defined upfront and nothing major is likely to change.

Agile is likely to be more appropriate in mobile payments precisely because specifications are likely to change frequently – and a more iterative approach to development has a much greater likelihood of success.

The proof lies in these scenarios:

Bank A uses an agile development methodology (namely, Scrum) and benefits from a first-to-market advantage, a customer base that understands the value proposition, and marketing that accurately matches the delivered product. Its product gains traction and exceeds return on investment expectations thanks to meeting quality and customer needs. While competitors struggle to launch products, regulatory discussions begin. 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 has agile development, but was slower to enter the race, and narrowly lost the battle to hold the standard. But it quickly finds innovative ways to adhere to standards without infringing Banks A’s patents. It released a strong rival offering, without impacting quality, and so maintains a healthy market share.

Bank C uses a waterfall methodology and released a product two months later than planned that failed to win consumer support. Regulators quickly dismissed this product – the documentation failed to accurately describe the final release, and how it would meet critical security and communications expectations. Bank C has a choice: undertake another significant waterfall project, pay Bank A for its technology, or change its development model – after writing off more than a year of investment.

Bank D claims to be agile, but it uses the term as an excuse to minimise documentation and planning. It delivered a promising product at the same time as Bank A, but it is not well understood, is plagued with defects and documentation is scarce, and so fails to deliver 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 B to use their technology.

A recent report by industry analyst Voke confirms the types of software projects that are more likely to succeed with agile include smaller, custom projects and web applications. These are just the types of project that financial institutions are undertaking in mobile payments, but for many the main experience has been with large ‘legacy’ waterfall systems.