World’s Largest Agile Program Goes Back To Waterfall
The UK’s Universal Credit Welfare System , “a complex IT project that involves switching off multiple benefits and reworking them into a new tax credit system” was, by most accounts, the most ambitious agile software development project in history. Suppliers include Accenture, Cap Gemini, HP, and IBM. In their implementation they limited the potential users to the most simple cases: single people out of work, and is a small geographic area. Seems to make sense, delivering working software, even if not the full feature set.
Quoting Computer Weekly “ DWP drops agile from flagship government software project”
The Department for Work and Pensions has dropped a coalition government scheme to avert software disasters from its £2bn Universal Credit programme.
The DWP gave up using the “agile” method of software development for Universal Credit, the coalition government’s flagship reform programme, last month.
It had before now repeatedly claimed agile was the way it would keep Universal Credit on track. The coalition government had meanwhile singled agile out as a major part of its flagship strategy to stop IT projects going calamitously and expensively wrong.
The Major Projects Authority – part of the Cabinet Office – was going to press-gang government departments to use agile methods on big software builds. Universal Credit was the government’s first – and immensely ambitious – big stab at agile.
In its final stages from April 2013, the programme is using the waterfall approach – a standard DWP testing methodology,” said Hoban, shadow employment minister.
“Initial development used agile, But it was no longer needed. “In a programme as complex as Universal Credit, which includes new IT developments and changes to existing IT assets, both agile and waterfall methods may be appropriate at different times.”
Just because we are not using agile doesn’t mean agile is inherently flawed, or that Universal Credit is inherently flawed,” he said. “It probably means agile is at a point where agile is not appropriate.”
There are potential issues like:
- How was the initial schedule obtained (I hope they used some kind of estimation model)
- What were the assumptions that changed
- How agile was the program, really
- Should this program have been agile or was it a well bounded replacement system where other approaches might have been better
- Was this system too large to be agile
- And on and on
Some say this should have been a 2 year development but they added another 4 years just to cover all bases. There is an interesting 2 minute interview on youtube discussing the program and its agile plans.
According to techwell.com in their story “World’s biggest agile project collapses” there is massive finger pointing between the stakeholders as to was Agile the issue or something else. SOme say it was due to a billion + pound contract being issues as in waterfall, others say contractor personnel may not have has an agile track record.
We often describe agile is seeing how far you can get within a timeframe rather than waterfall ish where we see how long it will take to get the functionality complete. If they were required to build all the functionality and it had to replace existing functionality then they were probably in some hybrid mode.
Bottom line: Agile is a good thing when applied to the right problems. I can make no judgment as to whether this was one of those appropriate problems from existing information, nor about total ownership costs with their agile approaches for such a a long life large system without more information. Hopefully they did a lot more documentation than agile folks like since this system could be in place for decades.
This post Covering “Is Agile Cheaper” could be of interest as well.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.