In a guest blog, corporate IT lawyer Alistair Maughan argues that Agile development is an evangelical fad ill-suited to government IT.
The Government ICT strategy had some good ideas. Agile project management isn’t one of them.
The Cabinet Office expects Agile will reduce the risk of ICT project failure. It’s a nice idea in theory. But it won’t work in government IT. It won’t work in the real world.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Two of the most cautionary examples of failed ICT projects in recent years demonstrated the drawbacks of Agile.
The court battles of BSkyB v EDS and De Beers v Atos Origin showed that when Agile projects go wrong, they can go spectacularly wrong.
The Agile methodology is meant to deliver IT projects flexibly, in iterations. It’s meant to involve customers more directly and adapt quickly to their changing needs. This means the final system only emerges gradually. It means customers don’t pay a fixed price for a complete project. They pay for a commitment of resources.
But the lack of clearly defined project roles and requirements is a problem for Agile.
Agile evangelists argue fiercely that the conventional waterfall development methodology is unrealistic. They say the sheer scope of work required by its pre-set deliverables often leaves it unable to fulfill expectations. They set themselves up to fail, say the evangelists, when they should be working collaboratively for success.
I’m prepared to accept on trust that, if all goes well, Agile may reduce the risk of project failure. But Agile simply won’t work in the real world of government ICT. We need a Richard Dawkins to bust the myth of the Agile gospel.
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?
Under Agile projects, you pay a given amount of money for a set amount of effort. But you can’t guarantee a specified outcome for a specific price.
This won’t work in government. Departmental budgets are managed very tightly, and they must be approved. Agile implies that charges for time & materials should be open ended. Government departments won’t accept that.
Government is also legally required to follow open procurement rules.
That means comparing different bidders on a like-for-like basis, and deciding on best value for money. Agile can’t give you a clear specification of outputs up-front. Nor can it give a definitive up-font price.
So how are government bodies supposed to make Agile comply with the legal requirement that public procurements are fair and open?
As if that isn’t problem enough, Agile offers insufficient means of remedy if things go wrong.
This is a particularly sensitive issue for government, where departments suffer public opprobrium if their project isn’t a resounding success. The press, the National Audit Office, and the Public Accounts committee (PAC) will give government a kicking if they can’t make suppliers pay for the damage they caused.
Agile makes it hard to apportion blame because the customer is intimately involved in the work. Since Agile contracts lack clear contractual delivery obligations or remedies, how do you enforce properly? How do you recover loss or damage if there’s a problem?
I wouldn’t want to be the first Permanent Secretary to admit before the PAC that his or her department has no real right of legal recovery from a failure.
Agile is fourthly not suited to public sector management structures.
Decision-making is centralised in government. Civil service structures ensure every important decision flows up to senior levels. The Cabinet Office has under the current government taken even greater power over ICT projects. But Agile decision-making (over requirements, for example) flows down. This is key, so small devolved teams can react quickly and adjust to new scenarios.
It is inevitable that Agile decisions will go through management hierarchies in central government. This will be like kryptonite to Agile projects.
Agile projects rely on decisions based on mutual trust. They are therefore well suited to in-house projects. But the faith they ask customers to have in service providers makes them ill-suited for external developments.
You can have an ICT project with a watertight contract, clear deliverables, openly and legally procured, with a fixed price and appropriate remedies if you don’t get what you want. Or you can have an Agile project. You can’t have both.
I do appreciate that as a lawyer specialising in large ICT projects, you may think, “Well, he would say that, wouldn’t he?”. But my job is the help create successful projects.
I’ve seen too many projects flounder for a lack of trust between customer and supplier to think the answer to government’s ICT problems is the Agile credo of, “Let’s trust each other some more”.
Partner and head of Technology Transactions at international law firm Morrison Foerster, Alistair Maughan has advised on large public and private IT contracts including HM Revenue & Custom’s controversial 10-year £8.5bn deal with Capgemini. Follow him on twitter @ICToutsourcelaw