Agile and the strange case of Universal Credit in the UK
How could a system intended to avoid the past failures of large-scale government IT projects go so wrong?
In 2011 the UK government realised that things needed to change. Billions of pounds had been wasted on major IT projects that were later cancelled (from ID cards to a 10 year £11 billion health service system).
The UK government announced Universal Credit to simplify working-age benefits and incentivise paid work, and stated that Agile methods would solve the problems with the new project.
So how did the program degenerate into an inflexible system, 6 years behind schedule and a design that fails to match the lives and needs of real people.
So, what went wrong?
Lack of detailed plan
Without a detailed plan, there has been no measure of progress. If you can’t measure progress, how can you ever reach your destination? Equally the completion date — October 2013 — was set without justification or feasibility. Some would say the project was doomed from the beginning, and it is now more than 5 years behind schedule.
A silo mentality
The team working on Universal Credit worked with a large amount of independence. They did not seem to prioritise satisfying the customer, number one in the agile manifesto.
Lack of financial oversight
As the project progressed, the management skills of those delivering Universal Credit became called into question. Since the cost may now be more than the system it is replacing and is reported to be at risk of never delivering value for money, this seems a fair criticism.
Lack of supplier control
Without defining scope for suppliers, it has become difficult to hold those suppliers to account. Rather than aiming for technical excellence there is confusion around the contracts between systems. A lack of simplicity, and a gap between the business and developers had sown the seeds of project failure.
Catastrophic in use
This week the system has been criticised for intensifying the hardship faced by single working mothers, and the formerly flagship programme has been plagued by usability issues and it is doubtful whether working software can be delivered. The system has a two-child limit on elements of the benefit, and an exception can be made through a “rape clause” if a woman can prove her third child was conceived through rape which puts the onus of proof on a victim. Simply wrong.
Changing requirements
Agile welcomes changing requirements. Some of the flaws to the system seem to have been designed in the system, like charging claimants to call a helpline or demanding a 42-day wait for first payment. Changing requirements is one thing, but underlying problems have added cost that will not simply disappear through technical fixes.
Scathing report
Last year the National Audit Office described “weak management, ineffective control and poor governance” and warned that, with such sunk costs the system is too complex and expensive to stop.
Is Agile at fault?
In September 2012, the government minister Iain Duncan Smith said:
“The thing about the agile process which I find frustrating at times, because we cannot quite get across to people, is that agile is about change. It is about allowing you to get to a certain point in the process, check it out, make sure it works, come up with something you can rectify, and make it more efficient. So, you are constantly rolling forward, proving, and making more efficient. “
He is correct: Agile is about change.
But, the manifesto is clear about what it is.
I don’t think it is possible to claim that a better plan would solve all of the problems, or that closer customer proximity would have led to a better rollout or to list the principles and point out what was not followed. As ever, the search for answers is a little more complex.
Don’t blame Agile for your mistakes
I think that Agile became a rhetorical device to answer questions about the initial scale and timeline of the system, rather than a methodology to guide the project. This doomed the project to failure from the outset, and not because of the Agile mindset.
It is time the UK government did more than just pay lip service to methodology, and if it chooses to implement Agile methods see that there is more to Agile than changing requirements (it is not even the first of the 12 principles listed on agilemanifesto.org).
Agile could be part of the solution, let us not blame it for the long-standing problems of large-scale government IT projects.
