International development tends to be heavy on planning and documentation. There are concept notes and proposals to write, logframes and monitoring and evaluation systems to prepare, quarterly progress reports to submit, and baseline and endline surveys to measure the impact.
All this planning works well when you know how to solve the problem, and you can be sure that what you are rolling out is going to have an impact. But what about when you don’t know how to solve the problem? What about when you are solving a completely new problem? Or solving a known problem, but in a new environment where you don’t know whether it’s going to work?
In that case, taking a slow a methodical approach to planning a rolling out a program may lead to implementing something that doesn’t work. But with an endline survey typically performed years after a program starts you may not know this for quite a long time.
It’s these types of situations where international development could take some inspiration from the tech start-up community. Most tech start-ups follow a process called the agile methodology. According to Alassian, which builds tools to run agile teams:
Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a “big bang” launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.
Today there is a lot of jargon around the agile process (kanban, scrum, retro, sprints…) but at its heart are four major principles that were described in the original agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
With an agile methodology you start by implementing something small quickly, and then repeatedly iterate on it, rather than trying to plan the whole program in advance and then implement it in one go. The objective is to fail quickly rather than failing slowly. If something doesn’t work you just try another idea or iteration, rather than continuing with your plan for months or years before realising that it’s not working. Failing quickly is particularly important in settings were you have limited resources and you can’t afford to waste them on big plans that don’t work.
This is what the agile process looks like compared to the usual international development process. Each iterative cycle is referred to as a “sprint”, and usually takes 1-2 weeks.
This is an example of how an agile process could work to build out a malaria prevention program over a series of sprints:
So the next time you have a problem you don’t know how to solve, try using an agile approach to build out the program in small iterative steps. There are plenty of resources available if you want to learn more about the agile process. While many of them are software development focused, there are also some agile project management guides that are more general in nature and could be adapted for international development.
