Publishers: Innocent Ephraim, FSDT / Daryl Collins, BFA
In 2001, a group of 17 software development thought leaders came together at a ski lodge in Utah and wrote the Agile Manifesto and the Twelve Principles of Agile Software. Born of frustration, developers were thwarted by time lags between the development of customer requirements and the delivery of technology. This problem often led to building software products that critically failed to meet customer needs.
The Agile Manifesto and Twelve Principles created a revolutionary approach to develop technology with its focus on collaboration, testing with clients early, and working in close communication.
Yet, in the developing world (and even in the developed one) it is not always possible to work in a strictly agile way. This is particularly true when, as so often happens when designing poverty alleviation interventions, the solution is not driven by a “single source”. What if the development is happening between a technology developer and a financial services institution? Or a service provider and a consumer informant?
The answer is: it gets messy.
Very often, in the world of financial inclusion, the technology developers are far removed from the perspective of the low income user. On the flip side, NGOs (non-governmental organizations), MFIs (microfinance institutions) and other grassroots institutions that have been serving low income clients for decades, know their customers’ daily realities closely. In these situations, the agile principles require flexibility.
The Story: Developing a Digital Savings Group Product
In 2015, we, FSDT, supported a team to get messy. Below we tell a story of our grant for the design and build of a software application that required equal parts from two very different financial institutions – an NGO and a payment aggregator – in Tanzania.
By 2015 Aga Khan Foundation (AKF) in partnership with FSDT, had successfully established more than 9,200 cash-based savings groups with 180,000 savers in rural South East Tanzania – two-thirds of whom were women. These groups saved over USD $60 million (TZS 120 billion) from their inception, and maintained an 83% annual continuation rate.
AKF’s savings groups provided unprecedented access to finance for excluded populations in rural Tanzania. Yet members were concerned with safety: they were storing millions of shillings in their cash boxes and bookkeeping got complicated (and tedious). At the same time, mobile money was also growing at an accelerated rate in Tanzania.
The opportunity was clear: mobilize new mobile money users including rural women and the poorest, through digital savings groups (DSG’s). The right payment partner also materialized: Selcom, Tanzania’s leading payment and mobile money platform.
AKF’s savings groups provided unprecedented access to finance for excluded populations in rural Tanzania. Yet members were concerned with safety: they were storing millions of shillings in their cash boxes and bookkeeping got complicated (and tedious). At the same time, mobile money was also growing at an accelerated rate in Tanzania.
The opportunity was clear: mobilize new mobile money users including rural women and the poorest, through digital savings groups (DSG’s). The right payment partner also materialized: Selcom, Tanzania’s leading payment and mobile money platform.
The Path: Agile in an Analogue Environment
Agile Value 1: Collaboration Over Contract Negotiation
The DSG design process began in 2015 with the objective of eliminating cash and bookkeeping without undermining the cohesiveness of savings groups. The team brought their best game to the table: AKF led the innovation process, putting their deep knowledge of client needs and pain-points to the center as they led the design process. Selcom brought its payments backbone and the developers who could write the underlying code for the product. BFA, a consulting practice specializing in digital financial inclusion, served as facilitator of the process, writing technical requirements to AKF’s design for the developers at Selcom. The first decision came along without a glitch: the application would be built on an intuitive and smart USSD menu.
Agile in Action: Motivated Individuals
Both AKF and Selcom shared values: wanting to serve the low-income people of Tanzania. AKF had intimate knowledge of savings group members and how they reacted to these tools; and they had earned their trust. AKF felt strongly to “do no harm.” Selcom did not have the same intimate knowledge of this population, but were passionate about knowing how to appropriately serve a mass market client base. A key element that tied these two disparate institutions together was a commitment to serve the customer well.
Agile Value 2: Individuals & Interactions Over Processes & Tools
The actual design of the product hit rockier terrain; here is where messy agility was the right way to go.
AKF, with the assistance of BFA, tested small iterations of change along the way, developing clear ideas about what groups could and could not manage. AKF converted their depth of knowledge into customer-centric digitization. Understanding the customer journey was central. The team tackled the most crucial and well-used use cases, giving each stage time for consideration.
Here, agility was slowed down, yet easing off time constraints allowed the team to carefully consider the customer at every single stage.
Agile in Action: Simplicity
Savings groups originated to enhance democracy and transparency. Regular voting determines leadership positions. Money is counted out loud in front of everyone. As such, one of the key design objectives of the process was to ensure greater democracy and transparency within the DSG. Messaging needed to ensure that participants received timely information about their savings and loan balance, upcoming steps and who to approach with questions.
The most important observation the team kept in mind when designing the platform, was that it was intended to be a tool to support all operations of the group, not meant to dictate how to proceed or become more important than the group of people using it. As such, the key design principle became simplicity. The product would allow the group to simply get the cash out, and leave all other processes unchanged.
Agile Value 3: Responding to Change Over Following a Plan
An agile development process includes iterative and frequent testing with end clients. The team’s hybrid process was certainly messy agile, as a number of the pieces were tested after significant development and checked for “bugs”. The messiness allowed for the product to be tested iteratively, but less often than an agile process would typically demand. Instead of following a clear-cut plan between the development and testing phases, AKF and BFA formed a SWAT team to make progress in quality assurance while Selcom’s developers completed the more elaborate components of the platform.
The scenario the team found themselves in was not unlike other scenarios in international development solutions: the developers were based in the city, the users in rural areas. Yet this allowed the team to become resourceful and creative. At an early stage of design, the team tested the navigation of menus for critical use cases with end users in group settings to make sure that interaction with the platform was intuitive enough. With BFA’s support, AKF trained the field team in and used comprehensive testing protocols forming pseudo-groups to verify that the platform behaved as expected with typical and atypical test cases.
AKF’s regular interaction with users confirmed a key design element: groups would continue to meet in person. Even though the product allowed for virtual meetings, the face-to-face element was irreplaceable. It was an important decision that would help users become more comfortable with digital financial services, by not trying to become too virtual too quickly.
Agile Value 4: Working Software Over Comprehensive Documentation
There were moments when it was not clear if scope was creeping or if the original design elements were misunderstood by the developers. We, FSDT, as the funder, in particular pushed for structured user requirement documentation and, as it turns out, this was what pushed the development through to a testable design. Agile processes tend to downplay the role of documentation, but in this case, because the developers were sitting in Dar es Salaam, well away from where AKF was testing the product, documentation was exactly what was needed.
AKF, the key innovator in charge of design, made the ultimate decision at each step of the design process, which enabled the team to complete the specifications in reasonable time. The cost, however, was the disconnection of Selcom’s development engineers from the bulk of the design stage. BFA then found itself as a design translator: BFA compiled documentation materials so the developers had exhaustive information to base their code on. AKF’s testing platform became the “bug fixer.” Ultimately, it required 8 iterations to be sure that the platform was an accurate prototype of the design. Only then, did the team begin testing the functionality of the platform as per a proper testing plan.
Where did “messy agile” lead us?
Agility, in many ways, lived at the center of the process. The principles of simplicity, and testing early and often with customers was critical to discovering how clients would react to the digitalization of their groups. The messiness led to determine the right balance of digitization and human-connection. The deceleration led to having a full set of user requirements coming out of the customer journey discussion, and ensured effective communication between partners.
The messiness allowed for creativity, flexibility and improved communication. Even when we hit a rough patch, the bending of the principles was what allowed for a smarter and tailored results.
There is no way that agile principles in their idealistic purity would have allowed for the kinds of pivots that this work required. But solution creation is exactly that, allowing for movement instead of rigidity, responsiveness when there is a challenge and resourcefulness when options are scarce. There were two key outcomes from this process (regardless of product viability): (1) 3 very distinct organizations learned to lean on and trust each other under a complex and unusual scenario with a common objective and (2) the customer always remained at the heart of the entire process and it is what we ultimately see as our biggest success.
