Almost a year ago, while chatting with a good friend of mine Alessandro Cinelli, I discovered the Agile Development Manifesto. Since then I have been thinking about it and had the fortune to meet Jacopo Romei, an Agile Coach, working with Alessandro in a small but incredibly talented team under the name of Ideato. This blog posts is the outcome of my conversations with those two incredibly talented people and some of the ideas coming out form that conversation.
So, what’s the agile manifesto? On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met and created the Agile Software Development Manifesto to respond to the need for an alternative to documentation driven, heavyweight software development processes.
The Agile Manifesto states the following:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
The Agile Manifesto also has 12 principles:
- “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Looking at this manifesto and the principle it is clear that this software development methodology can easily be applied (and should indeed) to ICT4D projects. Looking at the following graph it is impossible not to notice how this methodology seems indeed to fit development projects overall and not only software development.
Shouldn’t this be the way we always design ICT4D projects – and probably all development projects?
The system as explained here is actually very simple:
You first think about your Strategy, what is the problem that you are trying to address and how do you think it would be the best way to address it. The you start rolling your project out and you review it all according to feedbacks from the beneficiaries and the users of the actual system. You look at how people are actually using your system, your technology if any, and then you start re -working your project again according to the outcomes of this first interaction. The entire project design is done in a phase to phase way, where the actual results, activities and work-plans are not a predefined variable but an on going process.
Once your project start taking shape you then look closely at the day to day type of interactions, they actual rolling out of the system, its sustainability and its long term effects on beneficiaries and local communities. This all system lead you to a complete different methodology where the project may be subjected to transformation over the course of the implementation and where the majority of the energies of the team are concentrated on the actual development and customization of the project and not on the necessity to follow a plan or a predefined list if deliverables.
In 4 words: adaptability, transparency, simplicity and unity. This i what ICT4D project should be, Adaptable to the real necessity on the ground, the actual technical literacy, the existing workflows and existing power relationships. Transparency in terms of actual results and methodologies, based on a collaborative design. Simplicity in the way the project is created, implemented and rolled out: not tons of deliverables and activities but actual results linked to real needs on the ground. Unity of the stakeholders, where beneficiaries, implementers and donors are not different actors in different times but can be part of the same system that discuss and create the project on a daily bases.
But how to we achieve this point? How do we get to the point where we can actually use this methodology?
A year ago, Mitchell Toomey, from UNDP, was asking those same questions:
” The big problems remain: large development institutional processes are still primarily waterfall, when the work calls for an agile approach. In my experience as a manager operating within such a traditional context, I often run into roadblocks that are basically caused by a systemic bias towards “waterfall” thinking. Take for example the process of procuring specialized professional services (such as training consultants, or software developers). In contrast to the highly volatile conditions into which a project is being deployed, the rules governing the procurement of services to support and achieve the project are still governed by lengthy documentation processes that were originally designed to “manage risk” before the advent of the more iterative lower-risk processes were made possible and transparent via information technology. Who will become the first international institution to actually mandate an agile development model in its programming? What would donor agreements look like? What about programming agreements? Procurement rules? Project management tools? Success criteria? Evaluation methods? The parallels between software programming and “human development” programming are encouragingly clear. Both help people by providing access to tools and capabilities that they did not have before, and both can be successfully managed, with a clear focus on results, if the most appropriate methods are employed. It’s time for development 2.0.”
Let’s do an experiment then: let’s take this approach and re-work the Agile development Manifesto to fit not just the way we design and implement the technology part of an ICT4D project, but the way we do development project design overall.
Here we have our Agile Manifesto then:
“We are uncovering better ways of developing development (and humanitarian projects) by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working and sustainable projects over comprehensive documentation and reporting
- Beneficiaries collaboration over contract negotiation
- Responding to change over following a workplan
That is, while there is value in the items on the right, we value the items on the left more.”
Let’s look at the principles:
- “Our highest priority is to satisfy the beneficiaries through early and continuous delivery of valuable and sustainable projects.
- Welcome changing requirements, even late in the development of the project. Agile processes harness change for the beneficiaries competitive advantage.
- Deliver meaningful deliverables frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Beneficiaries, donors and aid/development workers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development project is face-to-face conversation.
- Sustainable and meaningful projects are the primary measure of progress.
- Agile processes promote sustainable development. The donors, developers, development workers and beneficiaries should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best results, sustainability, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
I would love to see organizations subscribe to this manifesto. I would love to see us learning a bit more from the software development world, and if not going that far, at least make sure that we use that methodology for our ICT4D projects, where the very design of the technology is extremely important for the actual success of the project.
The Unwilling Colonizer 
well done 😉
Thanks Michele, very much appreciated! Please feel free to comment on the post if you have any idea you would like to share 🙂
Thanks for the citation – and the clicks 🙂
One practical way to jump start the use of Agile is to change a team’s toolset. Take a development project, offer to fund it on the condition that they use GrennHopper (http://www.atlassian.com/software/greenhopper/overview) or GitHub (http://github.com) to document and manage it. Bring in someone from the software world as an Agile Coach, and iterate.
Thanks Mitchell, agree totally. I also think that there is huge methodology change to be done in terms of the way funders request people to apply for fundings. While documentation and management is part of the issue, and definitely of the solutions, the entire design process also need to respond to more agile ways to think through the design development of the project before you even get to documentation and management.
Anahi, thanks for a great read. I completely support your desire to move to more agile project development in ICT4D. Are you aware that some tentative efforts to use agile in the participatory development project work happened in Madhya Pradesh in 2006 (and were journal published)?
Hey Tony,
no I was not aware. Do you have a link you can share? Which journal published it?
Hi Ahani
Firstly, I want to say that I am a fan of agile approaches, and I’m sure that development has much to learn from agile software development. See:
[1] A Dearden, H. Rizvi, 2009 A deeply embedded sociotechnical strategy for designing ICT for development. Journal of SocioTechnology and Knowledge Development 1(4), 52 -70.
[2] A Dearden, H Rizvi, S Gupta, 2010. Roles & Relationships in Agile ICT for Development. In proceedings of India HCI / Interaction Design for International Development, 22nd – 24th March 2010, Mumbai, India. Electronic Workshops in Computing (ISSN 1477-9358) http://ewic.bcs.org/content/ConWebDoc/35770
Secondly, I want to thank you for setting up this stimulating thought experiment.
Now, I want to unpick some of the places that perhaps the metaphor breaks down, so I’ll look at the principles in turn:
1. “Our highest priority is to satisfy the beneficiaries through early and continuous delivery of valuable and sustainable projects.
Absolutely
2. Welcome changing requirements, even late in the development of the project. Agile processes harness change for the beneficiaries competitive advantage.
This depends on where these ‘changing requirements’ come from. In the Agile manifesto they only come from the customer, and the software developer has to learn to welcome them. In reality, they generate new business for the software provider & new costs for the customer. In development projects, things could be more awkward. Whose ‘requirements’?, what kinds of changes?, who is paying? This needs to be thought through a bit more closely.
3. Deliver meaningful deliverables frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Actually, in software development for ICTD longer timescales can be better – the gradual learning processes in adopting technology mean that this kind of rapid turnaround can be destabilising for a project and can make it hard for beneficiaries to adapt to and adopt new ways of working. We certainly found that in the Rural e-services project. Of course it depends on the existing capacity of the host/beneficiary organisation.
4. Beneficiaries, donors and aid/development workers must work together daily throughout the project.
Yes, that’s the way to go.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Yes, people are key
6. The most efficient and effective method of conveying information to and within a development project is face-to-face conversation.
Sometimes yes, but sometimes no. The kinds of methods used in PRA are all about finding different ways of conveying information and agreeing common goals. Pictures, chapatti diagrams, maps, need to form part of the mix. Face to face conversation assumes small teams and lots of cosy 1 to 1 chats. Accountable & inclusive projects need other kinds of conversation (in groups / in pictures / in actions) to make progress and keep people together.
7. Sustainable and meaningful projects are the primary measure of progress.
Ah, here’s the rub. How do you propose to measure sustainability and meaningfulness? Phrased this way it’s a bit circular. Who measures what, when & why is all about power (sorry you can’t make it go away!)
8. Agile processes promote sustainable development. The donors, developers, development workers and beneficiaries should be able to maintain a constant pace indefinitely.
Yes, I can imagine this. A big part of the job is forming long term partnerships. Software development businesses don’t think in terms of single products / single projects. They look to develop ongoing long term relationships with customers gradually building up understanding & trust. Development actors need to think the same way.
9. Continuous attention to technical excellence and good design enhances agility.
Yes – but not just technical excellence. Relationships are a key issue.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
Very much so. Feature creep is a major problem, especially when donors who are not ‘on the ground’ see another ‘great idea’ and want to try it out. In software, developers are often keen on the latest technology and want to play – researchers value orginality – but customers might be better served by something that is old, but tried & tested.
11. The best results, sustainability, and designs emerge from self-organizing teams.
Perhaps.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Yes
As I said, an important conversation starter, but not an infallible recipe. By all means adopt an agile approach, but handle with care.
Andy
Hey Andy, thank you so much for the comment. very useful. Let me also clarify: i ma by no means an expert here..just trying to work my head around it, since I only got to know Agile Development a couple of months ago. 🙂
Here some reply to your comments:
“2. Welcome changing requirements, even late in the development of the project. Agile processes harness change for the beneficiaries competitive advantage.
This depends on where these ‘changing requirements’ come from. In the Agile manifesto they only come from the customer, and the software developer has to learn to welcome them. In reality, they generate new business for the software provider & new costs for the customer. In development projects, things could be more awkward. Whose ‘requirements’?, what kinds of changes?, who is paying? This needs to be thought through a bit more closely.”
Could not agree more. My thought on this are that changing requirements normally comes from two actors: the implementers (organization that gets the money to do the project) and the beneficiary (the people that supposingly will benefit from the project implemented). Now I agree on the cost issue, and believe me, I so am aware that those issues are at the heart of the issue, but on the other side I believe that we should detach a bit development project from the “follow” the budget mentality because too many time you end up linking your project “requirements” to the budget and not to the outcomes you have on the ground. I ma not sure how we find a way out without taking into account that if something is not working it needs to be changed, and this would also means, that your budget would end up being changed too, adding costs to you (as implementer) and to your funder (I know not happy news for them!).
“3. Deliver meaningful deliverables frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Actually, in software development for ICTD longer timescales can be better – the gradual learning processes in adopting technology mean that this kind of rapid turnaround can be destabilising for a project and can make it hard for beneficiaries to adapt to and adopt new ways of working. We certainly found that in the Rural e-services project. Of course it depends on the existing capacity of the host/beneficiary organisation.”
mhm I believe we are saying the same thing here. My point here is that we cannot develop a technology and deliver it. We should involve beneficiaries in the initial stage of the development, and work all the step towards the final release with them. Only in this way we can guarantee that the solution we are designing is actually responding to their needs and their “technology literacy”. Agree that this make the process longer, slower and possibly more difficult for the beneficiaries themselves, but this will also support a growing capacity for them to understand and use the technology.
“6. The most efficient and effective method of conveying information to and within a development project is face-to-face conversation.
Sometimes yes, but sometimes no. The kinds of methods used in PRA are all about finding different ways of conveying information and agreeing common goals. Pictures, chapatti diagrams, maps, need to form part of the mix. Face to face conversation assumes small teams and lots of cosy 1 to 1 chats. Accountable & inclusive projects need other kinds of conversation (in groups / in pictures / in actions) to make progress and keep people together.”
Yes and no. So I believe we agree here. I believe that face to face is a broader concept that also include groups. My point here is that in a lot of the places where I work face to face cannot be replaced by other tools. Not because those tools are not necessary, but because in person relationship is necessary and other tools cannot be used at all or are not familiar to the people involved. Here I am looking specifically at the inclusion of communities in development projects. Where possible, feasible and necessary, I would use all tools available. but still, face to face remain to me the best and most efficient way to convey information – again when possible, feasible and necessary. 🙂
“7. Sustainable and meaningful projects are the primary measure of progress.
Ah, here’s the rub. How do you propose to measure sustainability and meaningfulness? Phrased this way it’s a bit circular. Who measures what, when & why is all about power (sorry you can’t make it go away!)”
hehe right. Sustainability I believe it is a bit more measurable, success definitely not. On the who, when and why, I believe we are going back to M&E, which I tried to address in my latest post. I definitely need to think more about this. More to come then 🙂
I am trying to re work this “manifesto” again, and this is by no means a “final” version..so if you have other suggestions on how to phrase it, I am all ears.
Thanks again, this is helping me a lot in thinking about this 🙂
Glad to help. I don’t see any major points where we disagree at a fundamental level.
This is a genuinely critical question. The quality and impact of ICTD projects will be heavily dependent on the qualities of the processes that are used in those projects, and on the capacity of beneficiary groups (and their advocates) to manage ‘IT procurement’ to shape projects around their understandings, objectives and priorities. Agile makes this a bit less difficult, but it is never easy.
We’ve been using Agile development methodology for big and small IT development projects at the Royal Bank of Scotland. Although, initially, it did give us teething problems with everyone involved taking some time to get their heads around this unique development methodology but after a few months our team is now the trend setter within the organisation.
Greater visibility of the project for all stakeholders, better adaptability to unplanned changes, and realisation of greater business value are some of the benefits that come to my right now.
I generally know that a methodology is agile when it has the following features:
– Continuous engagement of all stakeholders (developers, testers, project sponsors, project managers, UX) at all stages of the software development process
– No separate distinction between stages of the software development process
– Short development cycles and regular testing to bring out issues as soon as possible
– Daily stand-ups and meetings (called scrums) between the project team members to update on progress and future potential issues
– Writing of the specifications for the software being developed in the user story format with multiple acceptance criteria
– Knowledge and full support for the agile process amongst all project stakeholders
In my opinion, if we can get this working in the extremely challenging investment banking environment where the timelines are ever so tight – I am sure with a few customisations it can work and give great results for ICT4D projects.