Building Open APIs for Digital Finance? Think Sprints, Not Marathon

As more digital financial services (DFS) providers start experimenting with open APIs to grow their businesses, many are finding that traditional approaches to software development are simply too cumbersome for the fast-evolving world of digital finance. CGAP has been monitoring open APIs in DFS for a few years now. We see that a growing number of providers are turning to “Agile,” a nimbler approach to software development that can be likened to running a series of sprints, as opposed to a marathon. The Agile approach offers many advantages, and enough DFS providers have adopted it to date that we see some practical lessons emerging on how other providers can successfully integrate Agile into their open API business.

Why DFS providers should consider the Agile approach for open APIs

The traditional software development process was developed by large enterprises with big projects. Typically, an entire set of requirements is given in the initial phase and cannot be modified after product development has started. The product development is completed in full and followed by a pilot phase to test the product with the customer. The time and investment required to go from start to finish can be considerable, so management often focuses on setting and hitting project milestones along the way.

While this approach may work in some contexts, its slow pace and limited engagement with customers in the development cycle to test value propositions can hinder DFS providers that are trying to meet the fast-evolving open API demands in their markets. The digital services companies that consume open APIs for payments are often in the process of defining and redefining their own products and payment service requirements. This can be especially true when they are targeting end-customers at the bottom of the pyramid. Often, these end-customers are not frequent users of DFS, and they may live in remote locations and be unserved through traditional infrastructure. Only through a great deal of research and a test-and-learn approach can digital service companies target these end-customers and understand what they want. And as they define their product market fit, these companies’ requirements for open API payments services evolve. DFS providers who offer open APIs must be flexible enough to evolve along with demand.

The Agile approach is meant for a changing environment and when the scope of a software project is not — or cannot — be known in advance. It differs markedly from traditional software development in that customers are involved throughout the development cycle, not just at key milestones. Due to its flexible nature, Agile works with a time-and-materials funding mechanism, whereas traditional methods are tied to fixed contracts. The hallmark of the Agile approach is that features are built in short sprints in the order of the value they are expected to bring to the offering, starting with the highest-value features. This means that even if money runs out, there is a good chance that something useful has been built. This is in stark contrast to the all-or-nothing approach of traditional software development. Another distinguishing feature is that teams are kept small and dedicated to discrete deliverables, and there is an emphasis on synchronizing teams.

How DFS providers can adopt the Agile approach

While there are many advantages of the Agile approach for open API product development, CGAP’s work with several DFS providers shows that providers can expect some growing pains. Here are some insights that may help your DFS company smooth the transition to an Agile approach.

1. Don’t let the flexibility of the Agile approach distract you from your long-term strategy. One of the main advantages of the Agile approach is that it enables DFS providers to iterate based on a feedback loop with open API consumers. This allows core functionality to be built quickly. Two- to four-week development sprints based on consumer feedback means providers can improve designs and deliver results quickly. However, it is important that these short-term, incremental improvements are aligned with your business’ longer-term strategic objectives. While development teams are working toward short-term objectives, senior leadership should always be thinking about the long-term strategy.
    
2. Help your finance team control the budget. Agile shifts away from detailed product design and resource-cost planning. The advantage of Agile’s iterative approach is that design changes are identified and addressed early, avoiding potentially large and expensive changes later in the product development process. However, this approach can also make it harder for finance teams to budget and manage product development expenses, especially when vendors are paid on a time-and-materials basis rather than through a fixed contract.
   
   Finance and product teams can consider a few things to support budget control. They can define medium-level product design and more granular costing of sprints. Negotiating vendor contracts that are fixed price per sprint can also be helpful. Finally, it is important to regularly update management on changes in sprint planning and costs.
    
3. Prioritize resources. As with budget control, the iterative nature of the Agile approach can make it difficult to plan for resources. As product design and sprint plans evolve, there is short-term demand for specific resources. Often, there is competition for these resources across a business. Without a method for allocating resources, your open API product team might encounter delays in implementing their product sprints.
   
   DFS providers who have implemented Agile have found it helpful to create a resource prioritization committee. Ideally, the committee includes decision-makers from the business/channel, product, IT and finance departments. It focuses on confirming budget and resource allocation to build momentum in product development. Strategic alignment and budget control factors mentioned above should factor into the committee’s decisions. In this way, the committee helps ensure that open API sprints align with your company’s overall strategy.
    
4. Start by developing a minimum viable product (MVP). An MVP is an initial version of a product that includes only its core services rather than a full feature set. Starting with an MVP open API offering and iterating over time with the Agile approach is often an effective way to validate value propositions and test your assumptions about open API consumers.
   
   In the digital age, there is a tendency for products to be tech-first and to avoid processes that rely on human intervention. The purpose of an MVP is to get something up and running quickly. For this reason, providers may want to use manual processes to develop an MVP rather than developing a fully technical solution at the start. While this may not be a scalable solution, it can allow customer value propositions to be tested and reveal whether it makes sense to invest in building a scalable, tech-based solution. In designing MVPs, product teams should explore whether manual workarounds are possible and operational team resources can be used as an alternative.

As established providers shift their strategies toward integrating into a new and diverse ecosystem of providers, they are increasingly adopting Agile to deliver an open API product roadmap. While not a panacea, the Agile approach does offer DFS providers much-needed flexibility to stay on the cutting edge of the open API space. Providers who adopt Agile will be better positioned to work with major digital disruptors as they enter the market. Yet to use Agile effectively, it is important to align it with a long-term strategy and take steps to ensure development teams have the budget and resources they need.