The quotation comes, of course, from Richard Bacon MP and Christopher Hope's Conundrum: Why every government gets things wrong and what we can do about it, pp.240-1. Here we are, back again, asking why government IT systems too often go over budget and what we can do about it.
The traditional approach to software development is often known as 'waterfall' development: that is, you plan, build, test, review and then deploy, in a relentless cascade. But some IT industry players regard this practice as the chief problem ...A rather different answer which has emerged in the last ten to fifteen years has been what are called 'Agile Systems', perhaps best described as a philosophical movement in action within the software industry.
The fashionable answer is that the problem is the "waterfall" engineering of software systems and the solution is "agile" engineering. Waterfall bad, agile good. That's the idea. Let's explore it a little.
Waterfall is always associated with Winston W Royce (1929-95) and, to hear people talking about waterfall these days, you'd think he was a bit of an idiot. Actually, he was a rocket scientist who got into large-scale software engineering and ended up running IT for Lockheed.
The reason he bears the blame for the British government wasting a fortune on IT, by common consent, is something to do with a paper he published in 1970, Managing the Development of Large Software Systems. A paper in which, incidentally, the word "waterfall" doesn't appear.
On the other hand, this diagram does appear:
That looks like a waterfall. To some people. Is that the smoking gun?
No.
Royce calls that a "grandiose" approach to systems development and he doesn't recommend it because it omits the "iterative relationship between successive development phases" shown in his next diagram:
He prefers this iterative approach in theory but he believes that in practice it "is risky and invites failure" because of the problem illustrated below – the developers can get locked in a loop, iterating away forever, never deploying the system, never releasing it into the field, it never moves into operational use:
Is that what's happened to the agile-loving Government Digital Service (GDS) and their so-called "transformation programme" with its 25 "exemplars"?
The dial seems to have been stuck on "1" for the number of live services for a very long time.
The single live service is exemplar #6 – Student Finance, which was released no later than 31 October 2012, please see Refining transactions with help from the Minister.
That's 18 months ago. What's going on with the other 24 exemplars? Has the "operations" box become disconnected from the rest of the agile development process, as predicted by Royce?
Maybe.
Are GDS suffering from the lack of an identity assurance service? Would they have done better to stick with the Government Gateway?
Maybe.
Or is it something to do with this paragraph which appears under the 1/7/16/1 dashboard:
All 25 exemplars have to meet the digital by default service standard in no more than 30 days time. What does that mean? Never mind.
Look at that "March 2015" at the end of the quotation. Surely no politicians think that releasing 24 digital services at the same time as launching their manifesto will help them to win the UK general election two months later in May 2015, do they?
Maybe.
We don't know why progress has stalled, but it has – agile doesn't seem to be doing any better than waterfall.
What would Royce have recommended 44 years ago? Do your program design first, he said, keep your documentation up to date, do a prototype, test thoroughly and involve the customer. In a nutshell, this – the bit to the left of the dotted line:
Whatever it is, it isn't a waterfall. Not as we know it.
----------
As far as the Government Digital Service (GDS) is concerned, agile is the only methodology for successful software engineering. They have always said that. Ex-Public Servant of the Year ex-Guardian man Mike Bracken CBE ex-CDO ex-CDO, ex-executive director of GDS and ex-senior responsible owner of the pan-government identity assurance programme now known as "GOV.UK Verify (RIP)", said it in connection with the UK's digital Basic Payment Scheme for farmers, for example:
I go weekly now. I go to the meeting of the Common Agricultural Policy Reform Group. It's the RPA. It's the Rural Payments Agency.
Why I'm so excited about that is because they've embraced agile completely. They're going with an agile build out of a whole new programme. That's going to affect everyone in this country, and how they deal with land management, all the farmers, all the people who deal with crops, all the data. It's going to create, I think, a data industry around some of that data.
It's going to help us deal with Europe in a different way, and quite rightly we're building it as a platform. It's going to be another example of government as a platform.
And yet the digital BPS failed and our farmers now have to apply for their money using pencil and paper.
The National Audit Office have published their report on this failure, Early review of the Common Agricultural Policy Delivery Programme. And they say:
It looks as though GDS's enthusiastic advocacy of agile methodology is based more on fashion than useful practical experience. They may be keen but, when confronted with the reality of a public service, it looks as though GDS can't deliver.
GDS provided limited continuity and insufficient insight into how to adopt agile on this scale. It was not able to identify and provide the systems integration skills required ... (p.9)
... the Cabinet Office [i.e. GDS] should ... provide stronger written guidance and capability building for departments on agile management and governance for major projects and how it fits with traditional governance structures ... [and should] support departments in acquiring the management and technical skills required to apply agile at scale ...(p.12)
The Department [DEFRA, the Department for Environment Food & Rural Affairs] and the RPA [Rural Payments Agency] had no experience of the agile approach. The Department felt it did not receive sufficient support from GDS given the level of experience of Programme staff, leading to poor application of agile. Programme governance was not adapted to quick iterative development cycles. (p.22)
The Department told us it sought guidance in 2013 from GDS on best practice for agile governance, but guidance on this was not published until June 2014. (p.28)
The Department and the RPA described GDS support as patchy. There was little continuity in personnel and GDS staff were reported to have provided insufficient insight into the use of agile at this scale. (p.33)
Many of the commitments GDS made to the Department are vague. For example, it did not quantify the savings that the use of agile would achieve: “no formal estimates of cost savings will be offered but previous experience of operating in an agile manner would suggest a significant cost reduction can be expected from traditional approaches to large scale IT procurement”. It was agreed that the Memorandum of Understanding would be reviewed every six months at Programme Board level, but this did not happen. (p.33)
More comprehensive guidance on agile management would help departments align governance for major projects with traditional governance structures. (p.34)
Updated 7.9.16
Universal Credit – From disaster to recovery? Good question.
That's the title of a report just published by the Institute for Government (IfG). Has Universal Credit (UC) flirted with disaster? Yes it has. Is it possible that UC will one day succeed? Yes it is.
UC is a Department for Work and Pensions (DWP) initiative. The report provides some insight into the IT problems of UC and the occasionally fraught relationship between DWP and the Government Digital Service (GDS):
There's a lot more where that came from (p.53) for anyone interested.
The reason it took 'much longer than they originally thought it would', according to Lord Freud, was that the GDS team were initially 'very naïve' about just how complex it was to build Universal Credit. He says: They were messianic about building the front end, doing it in an agile way, front facing, with their beautiful apps, and they were right about all of that. But they had no grasp of how complicated it was to tie the front end to the legacy back-office, these old and creaky legacy systems we have with which it had to work – the customer information system, the debt management system, the payment system and all the things you need to run 20 million people and their records, and with all that implied.
The IfG report identifies a lot of problems faced by UC including unrealistic timetables, DWP overload, lack of in-house skills and poor governance. "Waterfall" software engineering methods were not the only problem. "Agile" also was a problem. Nothing in the report demonstrates that "agile" is the solution – some of that earlier fashionable "messianic" ardour was misplaced ...
... and is now waning, please see for example The Tyranny of Agile.
