honestlyreal

Icon

Agile, waterfall and muppets

There’s been some very good debate of late about how to do it all better, with a heavy emphasis on the role that Agile methods might play. “It” in this case being not just government technology, but extending to policy development, communications and more.

There seems to be a massed rebellion against the substandard, the lame, the failed and the apparent deathgrip that a few large suppliers have on taxpayer billions. This is a very good thing, of course.

I found a couple of recent pieces very insightful (in different ways). Alistair Maughan kicked off a lot of debate with a provocative piece arguing that Agile was doomed to fail in a public service setting. This from one of the architects of arguably some of the biggest, most expensive and (inarguably) rigid ICT contracts imaginable. Adam McGreggor from Rewired State came back with evidence of Agile success, and a rebuttal of the good lawyer’s key arguments.

These arguments really seem to me to be based around an overarching sentiment that Agile weakens the ability to hold contractors (and their clients) to account for the delivery of fit-for-purpose products. Whether as a result of mismatched expectation, fuzzy requirements, incompetence or downright fraud.

Our defence against these–particularly the latter two–has traditionally been the much-lambasted public procurement process. As Anthony Zacharzewski put it with characteristic tact and style, we should have a care about throwing out the defences that these processes are designed to provide, for all the tales of woe that can also be laid at their door.

Stepping back a little from all this, I am left wondering what points are really being argued here? Is this about a methodology, or is this about ensuring that the right people are getting through the door? Amazing things can happen when the usual barriers are thrown down and the real, trusted experts are brought in. (I hope to see real-life evidence of some of this next week.)

After all, with amazingly insightful and competent people involved, respecting each other, listening to reason, taking risks where necessary, being flexible–and above any suggestion of conflicted interest or perverse incentive–even the most traditional requirement/specification/build approach is going to perform pretty well. And just imagine the horror of a perversely-motivated behemoth muscling in (let’s call them Anders*nAgile, say) with their Chicago-schooled ScrumBizAnalysts(TM) charging a couple of grand a day to dance in a slightly different style to the same old tunes.

If this is about trust–and I think a lot of it might be–then we need to be careful not to confuse “method” arguments with those that are more about “gatekeeping”. A great sage in the public sector IT world once said that the only HR rule you ever needed was “No muppets”. He had a point.