There was a fair bit of criticism last night of the UK government’s approach to agile development, and in particular its use of agile on the huge Universal Credit (UC) project. This was at a SPA 2011 session entitled “Towards Agile Government”, which came off the Institute for Government’s report on the subject. A straw poll at the end showed (by my reckoning) a 50/50 split in the audience between “depressed” and “impressed”. So, yes, there was hope expressed, too, but in this post I want to address the negativity… as I’ve done before.

Steve Dover, who leads the beast that is the UC project, stood up and talked about not just the challenges of doing agile development well, but of doing large projects which involved complex operating models, complex hardware such as telephony systems, and the most vulnerable people in society. I thought he spoke with passion and authenticity. Afterwards I talked to some people who said, essentially, “but they’re making this mistake, and surely that’s wrong”. But I think it’s unreasonable for an experienced practitioner to poke holes in another organisation’s genuine attempt to try something so ground-breaking (for that organisation) and so vast.

When I look back on our first attempts to do agile development at the Guardian I’m almost horrified by our naivety. Almost, but not really. Because while we made mistakes, and while we have come a very long way since, what we were doing was a real step forward. Benjamin Mitchell asked me “what if someone had come in and told you what you were doing wrong?” I think that would have helped for some things, but not for everything. Sometimes you have to have experience to be able to apply your knowledge.

By coincidence, earlier in the day I met Tom Loosemore, who leads alpha.gov.uk, the UK government’s other flagship agile project. When Tom talks about alphagov he talks about “Changing by doing”. Alpha.gov.uk might be at the far end of the scale from UC in terms of size and complexity, but that’s one core principle that’s important. You change your system by doing work on it, learning, and feeding back into the next phase of doing. And it’s true for the way you work, too: you do something, feed back, and do more — but this time, better. Just because you might be able to improve it doesn’t mean those first steps are fundamentally wrong.