Most government funded international development programs start with a Request for Proposal (RFP) that has to follow strict government procurement processes. These systems are designed to protect taxpayer money from waste and fraud and generate very detailed proposals.
However, this very focus on risk aversion could actually be increasing the risk that humanitarian relief programing, based on those detailed proposals, isn’t flexible enough to achieve desired outcomes in the challenging and variable environments where we work.
At the recent Technology Salon that asked, “Can Agile Principles Improve Development Programs?” we heard from five thought leaders on how we might change this strict paradigm and make it more… well, agile:
- Piers Bocock, Co-Founder, Acute Incite
- David Kershaw, Affiliate Consultant, Public Digital
- Rebecca White, Senior Project Analyst, USAID
- Jessica Oyugi, Community Health Specialist, UNICEF
- Kerry Bruce, Vice President for Measurement and Impact, Bixal
Over 80 digital development practitioners joined in a lively debate around what we mean by “agile” and how it and related methodologies could be applied in the foreign assistance context.
What is Agile in Development?
Most government procurements are designed to generate a very prescriptive proposal that details every action, result, and expense over a 3-5 year period. In some of the most chaotic and challenging operating environments on earth. Yet any significant deviation from that initial design, often written in a jet-lagged rush, can be considered a failure.
In the technology world, this is the classic “waterfall” approach, now discredited in favor of “agile” approaches, especially in the field of software development. There is a growing trend to adopt agile processes in international aid programs to give greater flexibility and support better outcomes and ensure continued relevance to program and client priorities.
Agile software development focuses on speeding up solution delivery and enabling earlier decision-making with incremental, iterative planning and execution, led by small teams that collaborate closely with stakeholders to respond rapidly to change.
In agile development, the logframe is flexible, the intermediate results can change, and the final program outcomes may look very different from the original proposal. Core to the agile approach is the ability to pivot. To radically change the intervention (as needed), based on end-user feedback to achieve the overall program goals.
A sailboat vs. train analogy can be very instructive. In most programs, we need to be flexible and flow with the wind, like a sailboat, as we aim for social and economic development goals. However, many RFPs are written to expect we are going to build very linear railroad tracks towards our goals, which isn’t that realistic in many developing countries (and even our own countries).
The USAID Framework for Collaborating, Learning, and Adapting is one way that one donor is incorporating agile approaches into foregin assistance. This data-driven approach expects programs to proactively measure their outputs, share good and bad results with donors, and make quick pivots to always be increasing outcomes.
While it is a formal USAID framework, it is not universally adopted or implemented. As with agile itself, there is resistance to change
The Agile Challenge in Development
The flexible agile approach poses a major challenge to the 4,600+ contracting officers and contracting officer’s representatives in USAID and the thousands of evaluation specialists, and program auditors that work with USAID and other donor organizations.
Agile processes can be seen as taking more effort than traditional contracting methodologies. All the meetings and communicating to keep teams on track and assess changes could look like wasteful make-work. Also, with many small deliverables, agile could give the impression that it only delivers “small” results. Finally there are the strict contract constraints and Federal Acquisition Regulations that span the entire Federal government procurement processes.
For example, if a contract lists specific deliverables, then there is little to no leeway to modify those deliverables once the program starts, even if it turns out they aren’t needed, or need to be different to achieve needed results. Yet, if the contract lists a statement of objectives, then there is much greater flexibility during implementation. Cooperative agreements and grants are more flexible than contracts.
Agile in Development Progress
Agile still can play a major role in humanitarian contexts. It just takes time to educate contracting officers and get them bought into the idea of being flexible. Getting government buy-in can certainly help, Most of all, we need to build trust with all our stakeholders. Trust in us, and in this new way of working.
One way to do this is to be present in the lives of procurement professionals. For example, talking with them often before the RFP process starts to educate them on agile ideas. Another way USAID has tried to do this is through the co-creation process. One result from these approaches could be a dramatically easier procurement process.
Another approach discussed was the need for constant communication. That might mean meeting with the government twice a week, every week to share processes and hear feedback. The meetings need not be onerous but an opportunity to provide regular touchpoints and remain visible and engaged.
How to Measure Agile Impact?
The role of knowledge management systems and the ability to be radically transparent with data will be key to measuring agile processes over the life of a project. And while agile approaches emphasize a “working product” over documentation – some form of documentation of the pivots, adaptations and the results still needs to be made.
This documentation can help to overcome problems with institutional memory, frequent staff turnover, and after-action reviews and official audits. Rapid feedback MERL and developmental evaluation can be good evaluation approaches for agile programs.
The Agile Alliance states that: “Ultimately, Agile is a mindset informed by the Agile Manifesto’s values and principles. Those values and principles provide guidance on how to create and respond to change and how to deal with uncertainty.”
The reality of addressing issues in the international development context is that by the time a problem has been diagnosed, a theory of change developed, the procurement process achieved, and a contract awarded, the problem would have shifted. There are too many variables to account for throughout the process I just mentioned to expect that a typical project management approach (waterfall) will adequately address the problem originally identified. In agile development the log frame, program logic or whatever representation of the theory of change should be “adaptive” not flexible.
Adaptability allows the core implementing group (including donor, implementers, beneficiaries/recipient government) to acknowledge the changing reality while keeping they end goal in sight. This approach is more cognizant of the risks inherent in the activity, and it moves along with the existent instead of trying to address an issue that was capture at an instant in time – long gone. Whereas co-creation allows the experienced implementer the flexibility to shape the solution while acknowledging the constraints under which the donor system functions, it does not provide for adaptability – at least not the one necessary to advance the solutions to the problem nor does it acknowledge the continuing evolving environment or the unexpected issues that certainly will arise.
The adaptability also needs to be baked in the implementation itself, meaning that implementers group (again donor, implementor and stakeholders) need to formulate processes that acknowledge information acquired to update the solutions (on a regular basis) as well as the log frame/program logic. Such an approach is built on three pillars:
• Participation of all the parties throughout the project development process; in order to have a complete picture of the environment as well as understanding of the underlying (and sometime hidden) causes to the problems identified.
• Collaboration between the donor, implementor and stakeholder; real engagement, exchanges, and ownership of the different parties through commitment of staff and resources; Also, agile scrums are not just meetings, they are work sessions and can (should) be brief and efficient.
• Trust in the ability and good faith of the different partners. The donors need to acknowledge and integrate this new way of working so that the other partners can as well, the approach should be less prescriptive and more collaborative, and recipients should be better integrated and invested in the solution (through stronger representation or else).
In the Agile approach in software development, the customer at the center of the process. We should also ask ourselves why, during the Salon, little mention was made of the customer (population, recipient government, etc.) whereas we spoke a lot about the donor, its procurement system, and its inability to flex. There is a need to reframe the approach and Agile might be the solution, however it also requires that we change the way we look at problem solving in the development context; it requires a change in mindset that acknowledge the recipient as the most important element in the system. I don’t know if we are there yet.