Are GDS agile?
Or are they digital-by-default?
When it comes to Universal Credit,
it may not be possible to be both.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items onthe right, we value the items on the left more.
Principles behind the Agile Manifesto
We follow these principles:- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
History: The Agile Manifesto... Representatives from ... and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened ...... attendees voiced support for a variety of "Light" methodologies ... articles were written that referenced the category of "Light" or "Lightweight" processes. A number these articles referred to "Light methodologies ...... Early on, Alistair Cockburn weighed in with an epistle that identified the general disgruntlement with the word "Light": "I don't mind the methodology being called light in weight, but I'm not sure I want to be referred to as a lightweight attending a lightweight methodologists meeting. It somehow sounds like a bunch of skinny, feebleminded lightweight people trying to remember what day it is" ...
[which is how the methodology came to be called "agile"] GDS, the Government Digital Service, are committed to making public services in the UK digital-by-default.
They are committed to achieving this goal by using so-called "
agile" methods.
What are agile methods when they're at home?
AgileAs noted by the National Audit Office in their report
Universal Credit: early progress (p.53), agile methods derive from the admirably short
Agile Manifesto published by the Agile Alliance in 2001 and reproduced
opposite.
The Agile Alliance acknowledge that their thinking is based on earlier methodologies in software engineering – it wasn't new in 2001 and it certainly isn't new now, 12 years later.
The reader may note
en passant that "agile" is just a word. The Agile Alliance could have been called the "Lightweight Alliance", please see
opposite, and they could have published the
Lightweight Manifesto.
More important, please note the
12 principles that the Agile Alliance distilled from their professional experience in the world of software engineering.
Digital-by-defaultUniversal credit to be first service 'digital by default', said the
Guardian on 3 February 2012, when Steve Dover was still the director of major programmes at the Department for Work and Pensions (DWP). The article quotes him as follows:
| The starting point, I said to our telephony collaboration teams based in Newcastle, was just think of a contact centre, but it has got no people in it and think of an operating model that has got no back office, and start from there. |
Mr Dover is
no longer the director of major programmes at DWP.
The Cabinet Office's
Digital Efficiency Report estimates the savings to be made by introducing digital-by-default. These savings would be made only if 80% or more of public service transactions take place on-line. The report estimates that it could take 11 years to reach that goal. On p.19 the report says:
| If the proportion of savings estimated to relate to staff costs ... is applied to the total estimated annual savings and then divided by an average cost per FTE [full-time equivalent, what we used to call a "person"], this amounts to a total FTE savings estimate of at least 40,000. This represents the number of FTEs [people] that could be saved [scrapped] if a shift towards digital transactions right across government were achieved. |
"Digital-by-default" means empty call centres, unmanned back offices and 40,000 fewer public servants, minimum, all replaced by computer systems.
This is Tony Blair's deceased
transformational government agenda. Dead, but still walking.
No.6Take a look at the principles behind the
Agile Manifesto reproduced
above. Particularly principle no.6:
| The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. |
"Requirements elicitation" as it's known. The best way for a development team to understand or elicit what is required of them is by "face-to-face conversation".
As keen followers of agile methods, GDS may be expected to adhere to that principle. They will not rely on documentation printed on paper or displayed in browsers, they will not rely on emails or texts or instant messages or phone calls or memos. Face-to-face conversation. That's what works.
We can think of other scenarios where face-to-face conversation works best. Teaching children in class, for example, and diagnosing a medical problem.
Let's call this class of requirements elicitation scenarios "Class H", where the "H" stands for "human".
And let's distinguish Class H requirements elicitation from Class D, "digital".
Amazon doesn't need a teacher or a doctor to find out which book you want to buy. That simple piece of requirements elicitation can be accomplished digitally. Buying a book on Amazon is in Class D. You want to buy a heated towel rail on eBay? Ditto. Class D. You want to hire a car at Catania airport for five days beginning 12 December 2013? Class D. Etc ...
Universal CreditNow suppose that you don't want to buy a book or hire a car, instead you want to register for Jobseeker's Allowance or any of the six state benefits that
Universal Credit is meant to replace. DWP need to elicit your requirements. Is that a Class H or a Class D requirements elicitation?
The answer isn't obvious. We need an intelligent argument based on facts to convince us that registration for state benefits could be achieved exclusively digitally.
GDS simply assume that registering for state benefits is comparable to buying a book on Amazon – they haven't provided any argument to support digital-by-default in this case.
And in the absence of any such argument, it is imprudent – to put it mildly – simply to assume that registration could be digital by default. If we look at the evidence, we may find that the Agile Manifesto is right and that, in this case, "the most efficient and effective method of conveying information ... is face-to-face conversation".
Are GDS agile? Or are they digital-by-default? When it comes to Universal Credit, it may not be possible to be both.
----------
Updated 11.11.13:Should G-Cloud and the GDS be taken seriously as contenders to run Universal Credit?| Among the offenders are those who trumpet "digital by default" as the "answer", without considering the question. |
