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?

About Tony Roberts

Founder & ex-CEO of co-founder & ex-Executive Director of co-founding Trustee co-Founder & Director of currently PhD student of ICT4D at University of London Gooner
This entry was posted in Uncategorized. Bookmark the permalink.

8 Responses to Should ICT4D Be More Agile?

  1. giantpanda says:

    I was just thinking/writing about what people-centred design – service design tools – can offer ICT4D projects. What you are describing above, an “agile” approach to international development programming is all rather idealised – and having gotten to know service designers, they face similar challenges, even when in the same city as their clients/users. The question for me is how to actually make these concepts work in the big bad world… Still struggling with this…

    • Tony Roberts says:

      You are right GiantPanda. There have been substantive positive changes achieved in people-centred service-delivery in other fields: client-centred counselling, student-centred learning, agile software development etc. In each field the challenge begins in building an ideal and then, as you say, the rub is in the implementation.

  2. Andy Dearden says:

    Certainly there is a lot to learn from agile approaches specifically for ICTD but more generally (as Anahi writes) for the design of funding programmes. However, I think these two situations are a bit different, so I will respond to them separately.

    It is important to remember that in IT procurement, there is a serious problem of information asymmetry. IT providers know a lot more about what they are selling than customers know about what they are buying.

    In a commercial agile project, the customer usually has very clear objectives in their own mind (business objectives rather than IT objectives) and is a powerful agent in the transactions with the ICT provider (they can pull the plug on the money). BUT there are problems, such as: provider lock-in (anyone adopting the alternatives to from Microsoft Office probably knows what this means), uncertainty in estimating both costs & benefits; unpredictable evolution of projects (which mean that what IT is useful may change); real technical changes (e.g. changing availability of mobile networks) and the distractions of the ‘hype cycle’ for new technologies to name just a few. IT involves a lot of very complicated decisions and customers need to get high quality advice to ensure they get good value for their money. Unfortunately, most development actors don’t have these skills, expert advice is hard to come by, and how do you know that your advisor really has your interests at heart?

    The challenge in effective ICTD (whether an agile approach is adopted or not) is enabling customers to win at the procurement game. This might be a little easier to do with an agile model, but it’s never simple. Based on my experience (and on a paper that Joerg Doerflinger & I have under review at present) I would recommend that ICTD projects adopt an agile model WITH a partner on the ground who acts as technical advocate & business development advisor to the field project. The key is to ensure that the development project dog wags the IT development tail (not the other way around).

    I’m now going to draft a response to Anahi’s article.

    • Tony Roberts says:

      Andy thanks for the comment. There is no silver bullet for the power relationships tied to funding, but giving ‘intended beneficiaries’ access+capabilities in project design, decision-making and M&E could change the dynamics of power? I look forward to reading your paper with Joerg Doerflinger.

  3. Completely agree to focus all the attention on the “end users” and to convey to donors and organizations that PROJECTS ARE ALIVE AND ALWAYS CHANGING.

    In this respect, I think it would be interesting to complement Agile methodologies with the PDCA idea of “Demming’s cycle” applied to ICT4D projects.

    Involving all participants in the review cycle would help to understand the adaptation to the changing realities of the projects, would facilitate reporting and possibly would give better results for all parties.

    I think this adaptation in projects can be very good for the “end users” and, therefore, for the success of the projects. What I can’t see is how you can fit all this dinamism (results focused on the end user, Agile methodologies, Demming circle, or others) in a static world where big donors develop their activity in organizational structures attached to burocratic civil service procedures. Maybe we need to shake up the world a bit more, … or much more.

    • Tony Roberts says:

      I’m definitely up for the world shaking Jaume! It’s interesting to see the similarities between the Demming Circle, Kolb’s Learning Cycle, Action Learning Cycle, PRA etc.
      Thanks for the comment

  4. Hey Tony,
    yeah you are definitely misreading me. Talking about “real and independent M&E” for me does not in fact means “Ex-pat M&E”…but rather the contrary. What I argue there is that we keep treating M&E as an appendix of projects instead of making it part of it. On the other side, I would be careful in saying that M&E should be done entirely by the beneficiaries of development projects. I believe we both agree that there needs to be a participatory process but also that the independence of the evaluation is extremely important. And maybe this is the trick: a participatory process that also guarantee independence and sustainability.

    • Tony Roberts says:

      Thanks Anahi. I agree that M&E shouldn’t be done entirely by the ‘intended beneficiaries’ as that would not extend capabilities (or be acceptable to funders). My suggestion was rather that putting Agile project planning documents and processes online could enable evaluations by ‘intended beneficiaries’, implementing partners and donors (and their ‘independent’ advisers. My preference would be for process ownership, including the power of evaluative judgement, to remain with the people who’s the intervention is intended to benefit and the Agile/participatory team.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s