Most innovations are not completely and utterly new ideas that no one has ever had before, but rather happen when you take an idea that works in one context and try it out somewhere else. So while I talked with the software developers and coaches at the agile coach camp last weekend, I kept thinking: What if we used the principles that they use to make software development more participatory, user-oriented and faster learning and adopted them in international development projects? The basics of this new approach are summed up in the:
Manifesto for Agile Software Development
“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.”
Have a look at the way it starts. It is not about “we have all the answers” but “we are discovering better ways by doing”, not just by theoretical thinking about it. In my years of working with international development projects I have seen all different kinds, but I must say, a lot of projects still are heavy on the right hand side. Let me take you through how I connect this manifesto to my experience to explain some of the things I have seen in international development. And tell me if this relates to your experience as well…
“Individuals and interactions over processes and tools”
Someone has a tool (whether it’s a new solar cooker or a new kind web platform) they are excited about and look for a place where they can implement it – and for funding to do so. If you have a hammer, the world looks like a nail… Some of these hammer and nail projects have really interesting unintended effects of a side aspect of the project, maybe the training meetings allow the stakeholders to network, even if the content they learn is less relevant. But how many projects are able, willing and allowed (by their funders) to have a close look at this, abandon their hammer and just focus on what really has an impact?
“Working software over comprehensive documentation”
Some donors seem very focused on extensive documentation, pre-defined evaluation and filling out forms, and less insistent that the project or product actually works on the ground. Agile teams believe in very fast feedback loops, they might program for a couple of weeks, get to a point where a product (thought far from perfect) can see the light of day, be tried and tested and the feedback you get is fed into the next cycle of improving the product. Imagine doing that in a development project. Take your solar cooker or web platform prototype to the potential users after a few weeks, let them play with it, get their feedback, incorporate it in the next design and bring it back to them soon to play (or cook) some more. Continue to improve.
“Customer collaboration over contract negotiation”
At the coach camp we talked a lot about the fact that trust is crucial for being agile. And I think that is one of the reasons why a lot of people involved in development projects (whether funding or implementing) try to develop contracts and other binding commitments that are as waterproof as possible, because working with strangers (or new colleagues) from different cultural and socio-economic backgrounds and with different expectations makes it extremely difficult to develop trust. So the thinking is: If I don’t know if I can trust this one, I better have a really good contract to protect me. However, we often work in countries where a written contract has only a guiding function and is impossible to legaly enforce and it is the quality of the trust and collaboration with your “customers” on the ground, that is your strongest protector against abuse or fraud. But while that is something that many successful development practitioners know and do intuitively, that happens on the level of individual learning and is not supported by the general structures we work in.
“Responding to change over following a plan”
I think that is what resonated most strongly with me, because I have seen so many projects that were bound to execute the plan that they had come up with in the initial proposal, even if they found through their work on the ground that something else would work much better, a different problem was much more severe or conditions on the ground changed rapidly from the time they first developed their plans. I was once in a project meeting where the donor representative said: “You know, this is a learning project, so if you realize in the middle of it that you need to change your approach, that is fine.” I think we felt something like shocked relief that a donor would actually say that.
The agile coaches I met didn’t talk a lot about programming and code etc. but about how to support organizational change, how to encourage managers to be open to new approaches and how to deal with resistance. One of the most powerful things about this meeting was that it was a gathering of the tribe (as in “people of the same kind”): In their work as change agents they might often be the most radical, craziest person around, trying to convince their reluctant clients that being agile is actually possible and beneficial. And here they were, a large room full and within this room they were all mainstream, not radical at all. And the things that would spur endless discussions and scepticism outside would just get a “yes, I know” and the reassurance that the other person did indeed know.
If agile philosophies are to take root in international development (and I have seen donors and implementers who are leaning towards them, even if they call them something different), I think it is crucial to – once in a while – gather the tribe and just say “yes, I know” to people, who are just the same kind of crazy…
And now back to my question above… does this resonate with your experiences? And: Where do you go to meet your tribe?