Agile Governance – part one

I have recently completed a series of short presentations on Agile Project Governance as part of the ThoughtWorks Quarterly Technology Briefings.

I was the boring bit of the presentation, just setting context for the audience in preparation for the main speakers, but that’s ok because there’s no way I would have been able to compete with the speaking talents of Nigel Dalton and Josh Melville anyway!

I had a lot of difficulty working out what to say, or more accurately what not to say as I could talk on this topic for hours. In the end, I chose four key themes which I thought summed up the benefits and showed the main differences between Agile governance and governance in more traditional project methodologies:

- A bit about the history of Agile governance
- The illusion of simplicity and control in waterfall project governance
- Control and value with Agile
- Visibility

I will expand on these in upcoming blog posts.

One question that we knew would arise in the attendees' minds during the presentation was how they could get things moving in their own organisation. Our client speakers Nigel and Josh are both lucky enough to work for companies where there is executive level support for working using Agile project methodologies. Of course, there is no simple answer.

A possible starting point that I proposed was to attempt to highlight the fallacies associated with traditional project governance. One way to do this could be to encourage better post project reviews, focusing on the true return on investment:

- Were the predicted benefits actually realised?
- What proportion of the software delivered by the project was actually useful to the people who use it? (some of the statistics on this can be horrifying)

Without these measures, it can be easy to call a project a ‘success’, based simply on the fact that it has gone live. Value becomes irrelevant.

My recommendation is to encourage people in the organisation to see value to the business as the key project success criteria – not whether or not it came in under some budget number or within a pre-defined schedule. By getting people to think about what actually constitutes a successful project, they might also start thinking about better ways to measure that success during the project itself.