I popped into Agile BarCamp a couple of weeks back, and it’s taken me this long to get it together and blog about it!

Bless the Christmas season, so little time, so many events big and small.

As Miramar Mike says, there were many different takes on the day. I was one of the people who’d only heard of the word, particularly from this provocation paper, and wanted to know more. And learn more I did.

In brief, “Agile” is an approach to project management that encourages openness, trust, and transparency via participation. This makes it a great method in situations where, as a project manager or senior project-coordinatory-type, you have a lot of room to move.

The contrast to Agile methods provided by Eduard Leibenberger was to something highly linear like engineering. If you have set timeline and a highly controlled project to work on, then you’ll not be using Agile. But if your project is (or could be) all about iteration and active learning, then Agile methods might just be for you.

What I found most interesting is that there is a constant assumption that public service projects require highly structured, tightly controlled, and incredibly restrictive project methodologies. The one mantra that seems to be uttered is “but we must report to the Minister”. And I guess that’s fair enough. As public servants we’re required to be accountable to the public via the Minister.

But. And this is a big but. Often the Minister isn’t interested in the minutiae of your project. The Minister is more often than not primarily interested in you getting them results that demonstrate value being gained from public monies. When you get right down to brass tacks, it’s not how you organise your project (be it large or small), it’s how you used that organisation/method to achieve great results.

And Agile is a method specifically designed and evolved to produce results. This is because Agile focuses attention on bringing all stakeholders to the table early, producing clearly defined and agreed objectives, and keeping your project on track by having stakeholders well-informed about progress. Seems pretty simple right?

It probably is. Although, exactly how to apply it to a researcher’s role such as my own will require some thought. I will therefore keep you updated.

(I’d recommend the DEMOS paper if you’re a public servant and interested in the idea. The stuff on the problem of bureaucracy constraining innovation is very close to the ideas Leadbeater puts forward.)