There is a guest article written by Alistair Maughan, a corporate IT lawyer, over at Computer Weekly claiming that agile software development will never work in government ICT projects.
There are four clear reasons why Agile won’t work in government ICT. The most obvious is that government customers want to know up-front how much a system will cost. That’s not so unusual, is it?
It’s not unusual to expect it. It’s not realistic to expect it either.
Why are government departments looking at agile at all, when they usually have funding processes that seem so adverse to agile development? Because using current methods, many more large IT projects fail than succeed. Maughhan talks about the difficulty of enforcing contract terms in an agile project. Anyone who has worked on an IT project will know that if things are getting to that point, the project is already a failure. A vendor can pay penalty clauses in bad cases, but the money will never even cover the cost of the project, not to mention the cost of the project not being implemented.
Repeat after me: Large IT projects are inherently risky. Say it ten times. Requirements are impossible to get right up front, regulations and political considerations change, existing systems must be safely modified and interfaced with, estimation of custom work at high level is difficult.
So how do we de-risk large projects? Well, we could:
- Fund, develop and deliver smaller, working parts of a project over smaller timescales which are easier to estimate
- Re-estimate subsequent work as those pieces are delivered
- Re-evaluate project goals, requirements and costs on the basis of knowledge gained doing the above
There is some value in the article, however. It points out the incompatibility between more incremental approaches and current government funding processes. This is indeed a problem. But a large part of the existing problems in government ICT projects is the fund-and-build-the-whole-world approach (typically followed, of course, by expensive change requests budgeted separately to get a system closer to what is actually needed). If agile is making that failure more visible, perhaps the problem isn’t with agile.
Maybe there is no hope that project funding in government will ever change, and there will always be broken processes leading to broken outcomes. But let’s have a proper discussion of the actual problems, rather than starting from broken axioms of how IT projects should work and then dismissing anything which shows just how broken they are.