Agile, meet adaptive: How global development assistance and software engineering both thrive on an iterative approach

Over the last 20 or so years, agile software development has become all the rage in the software industry. An agile approach relies on breaking down the engineering process into lots of small cycles known as ‘iterations’.

Engineering projects were traditionally treated as a linear process that starts with planning, then moves through each stage one by one: design, engineering, testing, and maintenance. This process is sometimes called the waterfall model since it is based on the assumption that progress should flow downwards like a waterfall.

In agile development, all these stages are involved in a single cycle and are then repeated again, and again, until product development finishes. In this approach, software engineering teams re-think a product as they go, starting with the essentials, and adding features along the way.

An iterative approach to projects is slowly gaining popularity in the global development world too, though it is known by a different name: adaptive programming. Those who practice adaptive program management seek to always be learning and, you guessed it, adapting based on analysis of the changing context in which they are working.

While many organisations try to follow these principles to an extent, the vast majority of aid programs lack the budget, appetite for risk, and flexibility in timelines and contracting that makes this possible.

Additionally, the proposal process organisations must follow to receive funding is based on the assumption that they already know enough about a certain issue upfront to make a plan for solving it.

Change is coming

However, the field is changing, and many are pushing for organisations to be more accountable to people affected by their programs, not just to donors. As part of this push, iterative approaches are slowly gaining some attention.

So, what does that mean for development programs? In theory, thoroughly planning a program at the outset and proceeding according to that plan, as in the waterfall model of software engineering, is the easiest approach to development programs. It should reduce surprises and ensure that the appropriate resources and plans are set in stone before implementation starts.

But things rarely happen according to plan in development contexts. People in power change, priorities shift, and disasters happen, both natural and otherwise.

Similarly, estimating the complexity of an engineering project is famously hard to do since unknown unknowns exist which are discovered during implementation.

According to the ninety-ninety rule, an inside joke between software engineers, “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.”

Why the global development sector should welcome change

When it comes to global development, getting a good grasp of the context surrounding the problem you are trying to address can take years, even in a stable environment.

Over the course of a program, relationships are nurtured and the trust built in the process opens the pathway for more honesty from stakeholders, who themselves also get a better sense of what is feasible. Hindsight shapes future direction.

Adopting an iterative approach that can quickly demonstrate initial results, and build on its own successes, makes it easier to engage stakeholders and maintain their commitment to the program. Similarly, the power of small wins keeps engineering teams engaged and enthusiastic about their progress.

Iteration also enables development assistance to be more context-specific. It comes from the humble realisation that outsiders are often poorly placed to propose solutions, and that generally the best thing to do is to listen.

Local situations trump generic approaches that were designed abroad. Strong, sustainable solutions that will be supported by communities emerge over time, and in close collaboration with those impacted.

Dealing with resistance to change

Proposing to set up an iterative program can be unsettling to stakeholders. The lack of clearly defined deliverables and work plans can raise eyebrows. But paradoxically, iteration lowers uncertainty in the long run, because progressing in feedback cycles creates a shared understanding of what works or not, and makes it possible to focus on what works. Assumptions are tested and replaced with actual data that the next iteration can be built upon.

In the software world, this was theorised in the cone of uncertainty, which shows how uncertainty about the scope of a project reduces after each iteration, meaning that any plan you make at the beginning of a project is going to be the least likely to pan out.

In the following diagram, the red line represents iterations of the product included in an agile approach and MVP stands for ‘Minimum Viable Product’ which is an important iteration of a product where just enough basic features exist to get early feedback from users:

Similarly, adopting an iterative approach minimises mistakes in the long run, because taking small steps means more frequent opportunities for constructive criticism from clients and stakeholders.

In the software world, the waterfall model was largely abandoned because it resulted in bad surprises upon product delivery. Had clients been engaged throughout the process, they would have had a chance to correct course before more resources were put into development.

Iteration means putting a lot of trust in people. You need the right set of employees, partners, and stakeholders to progress without a work plan that was set in stone. That is true for all complex programs, but it’s even more important when you have empowered these people to learn and adapt together.

We believe that anyone working in the field of global development, who can have a direct or indirect impact on the livelihoods of others, must be humble about the work they do. We invite the communities and partners we work with to teach us. We encourage our donors to learn with us. We challenge ourselves, and each other, to always be learning. Iteration, regardless of what buzzword is used to describe it, is simply how we embody this.

This article was written by Raphael Merx, our Head of Governance and Transparency. To learn more about Catalpa, follow us on Facebook, LinkedIn, and Twitter.