Should ICT4D Be More Agile?

Some software developers swear by Agile methodologies. Agile is a group of techniques for developing software that pro-actively involves a team of intended users and staff from the commissioning organisation in a collaborative design process, which  is able to accommodate people's changing requirements. Agile recognises that operating environments are dynamic (and that shit happens!) so uses a participatory development process with short iterative development cycles to ensure that the project can adapt to reflect changing realities.

Agile software development shares some features in common with participatory development practices that are commonly used in international development projects including participatory rural appraisal (PRA) and participatory action research (PAR). Like Agile, PRA involves groups of 'intended beneficiaries' and other stakeholders in collaborative team discussions to inform the unfolding design and management of development projects. PAR involves participants as co-researchers in a collaborative process in which they have co-ownership of the research process and its findings.

Several people have independently seen the logic in bringing these approaches together in the field of ICT4D. Last year Alan Jackson from Aptivate had the inspired idea of inviting Agile guru Alistair Cockburn & participatory development champion Robert Chambers for a fireside chat at Cambridge University. Participatory development is rooted in the theory of Paulo Freire and in the innovative practice of popular social movements in Latin America, India and elsewhere, but it was Robert Chambers that popularised them in the English-speaking world.

The Cambridge event was an enthralling discussion between two leaders in their fields who knew nothing of each others' work, a fact which only went to make the similarities in their approaches all the more remarkable.

However this event was by no means the first attempt to explore whether Agile techniques would lend themselves to ICT4D. Field research was conducted at least as early as 2006, and tentative research was published by Andy Dearden and Haider Rizvi in 2008.

Much more recently Anahi Ayala Iacucci has been blogging on the subject. In the first post she assesses the utility of The Agile Manifesto for guiding the work of ICT4D practitioners. I certainly agree with her that involving 'end-users' from the outset in determining the objectives and specifications of ICT4D initiatives would be a significant advance on current practice. Imagine a world in which the development 'customer' was King, and where development agencies were in humble supplier roles as co-producers of development outcomes determined by their users!

Agile methodologies also have the potential - by virtue of the process of keeping the project plans/design/budget on the table and under constant collaborative review - to make the process of control and decision-making in development significantly more open and transparent.

Prince2 & LogFrames are not Agile!

In her second post Anahi moves on to consider the utilty of Agile methodologies for ICT4D project management. As all development actors know the blueprint approach of LogFrames and Prince2 is entirely inadequate for representing the dynamic social realities and constantly changing operating environment of medium-to-long term projects. For this reason funders and NGOs engage in an elaborate charade where everyone pretends that the project is going exactly as it was planned several years ago, whilst in reality everyone actually knows that this could not possibly be the case.

Anahi convincingly argues that moving to Agile development methodologies would make it possible for teams to frequently-update plans to reflect the unfolding reality. Online collaborative tools could be used to make the whole process open and transparent to the 'intended beneficiaries', ICT4D agencies and funders alike.

My only point of departure with Anahi (and I may be misreading her intent?) is where she argues for 'real and independent M&E not quarterly reports'. I agreed entirely with ending the charade of existing quarterly reports, but neither would I support handed over effective control of monitoring and evaluation to ex-pat M&E consultants (if that is what Anahi means?).

To stay true to the philosophy of Agile software development - as well as to that of principled participatory development - the logical approach is participatory M&E where the 'intended beneficiaries', who originally co-developed the project objectives and specifications, provide their evaluation as to whether their hopes and aspirations for their own development have been fulfilled, and the job well done.

If you commission Agile software development for your business you don't need external consultants to come in at the end to tell you whether your expectations have been met. Neither do community members participating in ICT4D projects.

As Linda Raftree has recently written there are an increasing number of ways that ICT can facilitate M&E so that funders and their 'expert' advisers can monitor and evaluate remotely should they feel unable to rely on the community feedback. Neatly, for our purposes, Linda concludes her post by saying that 'donors need to support adaptive [project] design' processes.

It looks like we are all singing from the same hymn-sheet here. It seems that Agile deserves further consideration from others in the ICT4D community. It may be that by talking Agile, ICT4D geeks and developmentistas can forge a common language with which to transform ICT4D theory-practice. Guaranteeing 'intended beneficiaries' voice as co-creators of ICT4D initiatives, from initial concept design to implementation and evaluation - would be certain to improve the success rate of ICT4D projects.

As Anahi says, Agile could be a game changer; it could be used to give 'intended beneficiaries' a genuine stake in ICT4D project development and could make ICT4D implementing agencies and funders genuinely accountable to the communities that they exist to serve. Such a sharing of power would be more just.

If used consciously to put the 'intended beneficiaries' in positions of power and influence in the design and implementation of ICT4D then Agile could be transformational. If, following Paulo Freire's original intent for participatory process, the objective of Agile ICT4D was that, the 'intended beneficiaries' of development become, at the same time, the authors and lead implementers of that development; if ICT4D process was assessed by the extent to which it enhanced the agency and capabilities of all participants then Agile could contribute to a radical transformation of the theory-practice of ICT4D.

What do you think?