An Agile UK Government - Let's not tip the kid out of the crib
First published in The Agile Journal, 5 May 2011
Surely one of the most controversial of Agile practices is Fail Early, Fail Fast. The underlying principle is simple. If an initiative is obviously crocked then the worst thing you can do is to keep it going*. Ed Yourdon talked about this years ago when he exposed "The Death March" syndrome of many IT projects. There are political reasons why these death marches continue to happen, each one a case study in the pathology of denial. Attempting to save face, or to buy time, are but two of them. The irrational yet very human desire to insist on return from bad investments is another. And then we have the "ugly baby" syndrome - a refusal to accept the evidence of one's eyes when the spawn is your own creation.
Now let us turn to the UK Government's Agile initiative, which they proposed in their recent ICT Strategy. I have been among the first to lift that ill-starred babe from the crib, and shake my head sadly at the Quasimodo before me. "This folly is an unworkable chimera" I have groaned. "How can Government be Agile? It will likely reject the substance of its own tissue". For whilst neither an abomination against God nor Science, an Agile Government is never likely to come to terms with its own contradictory form. To the bell tower with it then, before it blackens us all with its presence? Well, others around me propose even worse. But if we were to strangle this child at birth, it wouldn't be Fail Early Fail Fast, it would be murder. I say we have to give it a chance. At the very least it must be given the opportunity to succeed, and to prove any potential it may have. After all we are stakeholders in the success of our governments, and there can be no reward without some degree of risk.
And so it is that I must refute each of the arguments that were recently presented in Computer Weekly's Public Sector IT section. In the relevant article - " Agile will fail GovIT, says corporate lawyer" - a series of points were expressed which seem to sound the very death-knell of the Agile Government initiative. Another dose of healthy cyncism, perhaps? Well no, not really. Not when, in my view, each of the four points made happens to be wrong.
"Government customers want to know up-front how much a system will cost". Don't we all? In fact the pressure away from variable-time/variable cost (known as "time and materials") contracting has been building for a while. These days it is not at all unusual - in my experience, it is actually normal - for Agile projects to be conducted on a fixed-price basis. This works just fine, because it is the scope that becomes variable, and there are a number of iterations in which scope can be revised. The DSDM MoSCoW approach is a good illustration of this. On a waterfall project, the supposed "fixed price" is invalidated due to inefficiencies in change response, and as we know, the client just ends up paying through the nose via change requests. So the desire for up-front pricing is a driver for Agility, and not a contra-indication for it.
"Government is also legally required to follow open procurement rules". Tell me about it, it's a complete ball-ache. However, this has absolutely nothing to do with the methodology followed, nor does it militate against fixed-price tendering. On each of the public sector projects that I have managed we applied open procurement practices when soliciting Agile suppliers on a fixed-price basis. And for the record, yes, these practices did include OJEU. Each tender response was judged using a pro-forma in which they detailed their approach to iterative-incremental delivery for the fixed price they stated.
"Agile offers insufficient means of remedy if things go wrong". Well, it offers the ability to fix things regularly on an iterative and incremental basis, which is far more opportunity than you'd get with linear alternatives once you'd completed design. That's the Agile remedy. By involving the client throughout the project, the chances of final dissatisfaction are correspondingly reduced. The project proves its success by means of ongoing delivery. Of course that means the client is in a weaker position to sue at the end of it, but that's because they've been empowered and made stakeholders in their own success.
"Agile is fourthly not suited to public sector management structures". Good, this is a point which does in fact have merit. Public sector management structures are notoriously unAgile; those who are interested can read my previous whinge about this very matter. But many large corporates and multinationals were also renowned for being unAgile, and they have adapted. There is no reason to believe that the same benefits cannot be leveraged in Government. In fact, that's exactly why the PRINCE2 standard - so long regarded as the Niagara of waterfall methods - is now being integrated with Agile approaches. This is something I'm working on now with the DSDM Consortium.
The misgivings we all have about Agile Government are no excuse for misunderstanding. It is admittedly an unlikely initiative, but it can work. We've already gained some early successes and we will continue do so. Above all though, we need to be engaged and listened to by the Government; they need to prove it is more than spin, and allow us to help. Then, as is always the case with Agile Methods, we will see further proof of success in the delivery.
Update 10 May 2011: I've uploaded a video blog on the above:
 https://sites.google.com/site/wicmitchell/agilegov
*Also known as the "Mastermind" project, after the BBC quiz show of that name which featured the catchphrase "I've started, so I'll finish!"
