RAISE2012 - Brian Wernham - 11 October 2012 - Agile Adoption in the US and UK Governments - A...

7/31/2019 RAISE2012 - Brian Wernham - 11 October 2012 - Agile Adoption in the US and UK Governments - A Comparative

1/10

Talk given at the Researching Agile development of

Information Systems (RAISE2012) conference

11th October 2012

held at the Inmarsat Centre, London

Agile Project Management for GovernmentAgile Project Management for GovernmentAgile Project Management for GovernmentAgile Project Management for Government::::

Agile adoption in the US and UKAgile adoption in the US and UKAgile adoption in the US and UKAgile adoption in the US and UKGovernments:Governments:Governments:Governments: aaaa briefbriefbriefbrief comparative reviewcomparative reviewcomparative reviewcomparative review

Brian WernhamBrian WernhamBrian WernhamBrian Wernham

Brian Wernham 2012 CC BY-NC-ND


2/10

2

Introduction

Good morning to you all!

After many decades of run-away technology

projects, where delivery has failed and

benefits have not been achieved, both the US

and the UK governments have said that they

want to move to a more flexible approach to

IT.

Ten years on from the signing of the Agile

Manifesto,1 we are seeing more than just an

interest in Agile from leaders in Government,

we have had clear statements of intent.

Agile is no longer the ugly duckling spurned

by the mainstream. Governments on both

sides of the Atlantic wish to use it - and use it

on large, critical projects.

One of the objectives of this conference is to

kick-off the "Agile Research Network" (ARN)

which will initiate research projects under a

jointly agreed research agenda.2

What I will suggest today is a stream of work

for the ARN to consider - a medium term

goal, over the next 3-5 years, to assess how

the switch to Agile in government is

progressing, and whether it is delivering to

the citizen and reducing the cost of project

failures. This research will be helpful in

identifying where the roll-out of Agile is

faltering and why. We need to understand

what barriers there are to the use of Agile ingovernment, and how to overcome those

barriers.

There have only been incomplete attempts to

survey the progress of the adoption of Agile in

government. A torrent of reports have been

issued in the last two years, and their

conclusions have been tentative and in each

case they have noted that more research is

needed. The general consensus is thatalthough targets for a move to Agile are

broadly set, more robust measurement,

monitoring and analysis is needed.

So - here is the structure of this paper - both

for the US and then for the UK we will

explore:

Firstly - some background: what is

driving the need for new approaches?

Secondly - What do these new IT

strategies promise?

Thirdly - What actions are underway?

And Fourthly - I will assess the current

status of Agile adoption - both for the US

and the UK governments.

The US Experience

BackgroundBackgroundBackgroundBackground

The US government has had its fair share of

IT technology disasters. For example, the

failure of a huge project that tried to

integrate the personnel systems for the USArmy, Air force and Navy. In 2010, the project

was cancelled, after 10 years and 850 million

dollars thrown away.

One of the problems is that so many

regulations have built up over the years.

These try to improve technical development

in diverse government bodies, but often they

have just ended up stifling effectiveness.

A good example of how regulation has not

improved project management is the series of

regulations created over the years by the US

Department of Defense. For example, to try

and improve project management the DoD

published the infamous 2167 standard. This

was widely interpreted as mandating a

waterfall approach. The department then

tried to stress that modular development and

incremental delivery was the preferredapproach - they issued the 2167A standard.


3/10

3

But waterfall projects continued unabated.

Efforts were made to sweep up all the

regulations under one all-encompassing

umbrella standard, DOD498.3

IT disasters continued to plague the

department, so-Congress got involved. The

Clinger-Cohen Act of 1996 begat the 5000

series of regulations. These tried to reinforce

the need for evolutionary development.

Unfortunately an inflexible approach to

project management continued.

The story is broadly similar in technology

projects across all US public bodies. Each

major project failure results in more

regulations - more audit - and more

centralised standards. These create a mirage

of apparent control over projects by

increasing the amount of detail in the

management apparatus surrounding the

development teams.

The 25The 25The 25The 25----Point PlanPoint PlanPoint PlanPoint Plan

In 2008, when Barack Obama put togetherhis team to prepare for his transition into

office, he appointed a 34 year-old geek as his

technology advisor. Vivek Kundra proposed a

very different approach to running

technology projects. Previously, there was

little central oversight of IT - there was an

"AdministratorforE-Government", but the

position was little more than a placeholder.

Kundra convinced the president elect that apowerful executive role was needed - and that

he was the man for the job.

When Obama took office in 2009, Kundra was

appointed as Chief Information Officer with

the power to review and cancel any project in

the Federal government.

Kundra inherited a legacy of 27 billion dollars

of failing IT projects.

Vivek Kundra - the first Federal CIO

In the previous decade, IT spending had

nearly doubled, growing at an annual rate of

7 per cent. So Kundra immediately capped

the IT Budget - saving over 25 billion dollars

a year.

He forced change to the running of

technology projects by holding deep-dive

project reviews. These reviews, Kundra called

Technical Status, or TechStat reviews.

Each TechStat review entailed a long,

detailed, face-to-face meeting to inspect each

yellow or red status project. These reviews

were intended to delve deep into each project

with a relentless pursuit of oversight to

reshape projects, or to halt and terminate

them.

To kick off the initiative, Kundra attended

more than three of these meetings a week,

publically issuing memos to agencies where

problems were found. At the Environmental

Protection Agency, for example, one IT

project was found to be one year late and 30

million dollars over budget, so Kundra gave

them a month to put a recovery strategy in


4/10

4

place for the project. He was rolling up his

shirt-sleeves and meeting each agency CIO in

long and detailed meetings. If a project could

not come up with a realistic improvement

plan, it would be cancelled.

Kundra reviewed 38 projects. He saved three

billion dollars by cancelling four and

drastically reducing the scope of 11 other. In

12 cases he found ways to cut the time for

delivery by more than half, from two to three

years down to an average of 8 months by

adopting a more agile approach.

In 2010 he published a "25 Point Plan"

intended to shock the system.4 It shook up

the counterproductive processes that had led

to so many project failures. Major initiatives

were kicked off to put in place technologies to

complement agile approaches. For example:

Upgrading project management skills

to include agile training

Breaking down barriers to agile by

requiring integrated project teams

Making sure that procurement

professionals took agile approaches

Influencing Congress to change

legislative frameworks such as the

Clinger-Cohen Act that were anti-

patterns to agile development.

The current status in the USThe current status in the USThe current status in the USThe current status in the US

So, what is the current status in the US?

Yesterday at the Agile Business Conference I

talked about the failure of the FBI Virtual

Case File project, and how the subsequent

Sentinel project initially faltered. It started

with a massive Project Management Office

(PMO). This goliath superstructure tried to

control the supplier - over 100 million dollars

was spent on management 1/4 of the whole

budget - completely wasted until an Agile

approach was adopted and the PMO was

disbanded.

The introduction of Agile at the FBI was

initiated by Chad Fulgham, who came in

from the private sector, reorganised the

Sentinel project to use Agile and led the

project to success. Fulgham left earlier this

year to return to the private sector. And, last

year, Vivek Kundra left his post as Federal

CIO for a research position at Harvard.

Whether the US government can maintain

the momentum behind incremental,

accelerated delivery and implement Agile

remains to be seen.

The Government Accountability Office (GAO),

is the US equivalent to the UK National Audit

Office (NAO). The GAO released a report in

July charting progress in the adoption of

Agile in the US government. They found

pockets of excellence at various agencies:5

The Department of Defense had a 190

million dollar project developing a

Combat Support System using Scrum

A new 150 million dollar project to

improve the management of the

registration of Patents at the

Department of Commerce was also

using Scrum

A 44 million dollar Agile project to

create a system to manage tax

payments on Branded Prescription

Drugs

However, despite the GAO's enthusiasm for

Agile, the CIO Council, now without Vivek

Kundra, has yet to supply any leadership with

regard to the take-up of Agile specifically. The

Council has released guidance on modular

procurement and modular development but

has not specifically addressed Agile practices.

Vivek Kundra is a tough act to follow. We

will have to wait to see whether the new

Federal CIO, Steven Van Roekel, can keep up

the pressure for reform.


5/10

5

The UK Experience

BackgroundBackgroundBackgroundBackground

We are all familiar, I think, of waking up the

news that yet another IT technology project

has ended in disaster.

Surely the most egregious example of project

failure in the last few years was the

Firecontrol project.

The main contract to supply the Firecontrol

system started late and took two years longerthan expected to sign. The relationships in

the project between the IT supplier, EADS,

and the government were painful to say the

least. The Government and EADS failed to

provide timely information to each other.

A lack of interim milestones undermined the

Departments ability to hold EADS to account

for delivery and conversely the delays to

delivery led to cash flow difficulties for EADS

which created further strains in an alreadytense relationship.

Both sides were locked into the deadly

embrace of a non-agile contract. The

Government took legal advice and found out

that it was unable to terminate its contract

with EADS without incurring substantial

compensation payments provided for under

the contract. And EADS in turn was unable to

deliver against a final key milestone for mid-2011. In the end, the contract was terminated

and the government received a settlement of

22.5m from EADS little cheer considering

that 469m was eventually written off.6

Whereas the US government tried to regulate

and legislate tighter control in an attempt to

make Waterfall project management work,

the UK tried 'softer' techniques based on

best-practice guidance issued by the Office forGovernment Commerce such as PRINCE2,

MSP (Managing Successful Programmes and

the use of 'Gateway' peer-reviews. In the

time available I will just focus on the latter:

'Gateway peer-reviews.

These short, sharp reviews produced reports

at each Waterfall gate between stages of

projects. These reviews pre-supposed a

Waterfall approach with clear 'Gates' between

each cataract of the Waterfall.

This approach depended on a review of

detailed BDUF documentation, with an

assessment of likely success based on

paperwork and interviews with project staff.

No expectation existed of an iterative

approach. There was no encouragement for

the delivery of increments of working

software or for real life deliveries of that

software to users.

These Gateway reports mirrored the

assumption that Waterfall project

management was necessary for large projects.

They were confidential between the reviewing

team and the project sponsor. Because of

their secrecy they could not be even

requested under the UK Freedom of

Information (FOI) legislation.7.

The original objective of this secrecy was to

encourage robust criticism that might have

been stifled if embarrassing facts were made

public. However, the contents of each report

were often widely distributed within the

government, so the conclusions were often

not clear and were usually overoptimistic.

One report stated that the reports were

ineffective because of this lack of robustness,

and that they were considered unimportant

by Senior Responsible Owners.8

The findings of these Gateway reviews were

invariably optimistic, and often had not

impact on the likelihood of success.


6/10

6

The new IT StrategyThe new IT StrategyThe new IT StrategyThe new IT Strategy

The UK Institute for Government (IfG) has

been pressing for a change of approach for

several years. The IfG issued a report last

March called, System Error - the sub-titlewas "Fixing the flaws in government IT". It

recommended two major changes:9

First, the need for a new IT Strategy to

drive down costs and increase flexibility.

Second, the rollout of agile project

management throughout government.

In the same month, influenced by both theIfG's lobbying and also the US 25-point Plan,

Francis Maude published a new UK IT

Strategy.10

Francis Maude specifically declared a drive for

the adoption of Agile project management.

Five out of the 14 points in the UK IT

Strategy specifically relate to the adoption of

agile approaches.11

The plan was for 19 separate strands of

technological change, one of which was the

adoption of an agile approach. For example,

the use of flexible framework contracts. These

would be used rather than large fixed price

contracts that had so often ended up as

anything but fixed in price and length.

One influential paper from Emergn, put the

suppliers point of view as a response to theUK Government IT Strategy - it stressed the

need for agility could only be supported by

more involvement of Small/Medium sized

Enterprises (SMEs). Large project

procurements often fail, the paper argues,

because of inflexible use of standard forms

and contracts which slow the agility of both

suppliers and customers. Experts in the

buying and negotiation of large contracts are

too distant from the technology experts thepaper argues, and experts are so intimate

with the detailed in contract specifications

that they overlook the importance of

flexibility.12

Francis Maude - Minister for the Cabinet

Office

One important strand in the new

Government IT Strategy to support the move

to Agile, was to be major drive to end the use

of massive contracts that were seen to favor

the existence of an oligopoly of large

suppliers.

Most saliently, the IT Strategy set what

seemed like a concrete target for half of all

large IT developments in Government to be

using Agile within two years - by April 2013 -

next year.13

The CThe CThe CThe Current Status in the UKurrent Status in the UKurrent Status in the UKurrent Status in the UK

Later in 2011, the NAO investigated the

activities that had been spawned in the first

six months of the IT Strategy. Their report

was optimistic, but found that there were no

clear measurable targets in the strategy and

no system to measure its impact. They

warned that because there was no overall

plan to support the strategy, progress could

be hindered through lack of resources.14


7/10

7

When the Government produced a statement

on progress towards the IT Strategy in June

2012, the only agile project cited as a success

was the successful, but small-scale, e-

Petitions project which, although it had

collated 16,000 petitions successfully, was not

really a large-scale delivery project.15

However, one year later there was still little

evidence of the promised increase in use of

agile approaches. A Cabinet Office report

admitted that 10 departments had not yet

started any significant agile projects, and in

those that had, agile adoption was patchy.

Significant progress was reported in only

three areas:16

The massive Universal Credit project was

underway using some agile techniques

The Government Digital Service had

released alpha.gov and beta.gov websites

A lot of money had been spent on

training staff in agile techniques at the

Maritime and Coastguard Agency.

The IFG published a report from their

research into progress. They interviewed all

significant Government CIOs and their

procurements staff, and representatives of IT

suppliers both large and small. They found

that progress towards using agile approaches

had been slow.17

They noted that the US has effective directintervention from a strong Government Chief

Information Officer (CIO). In the UK they

found that the implementation of agile and

the strategy overall was poorly coordinated,

incoherent and still without clear objectives

or success criteria, despite the warnings in

the NAO report of the previous year. The IFG

noted that although senior leaders in

government and in technology suppliers

supported the concepts proposed in the 19

strands of the strategy, they were not

convinced about the approach to

implementing it:

The IT strategy did not adopt the

(previous IFG) recommendation that

platform and agile should be driven by a

strong, independent CIO instead (it relies on

a) CIO delivery board. CIOs should question

whether they are genuinely improving the

ways that they are working in areas such as

agile, or whether they are just attaching a

label to projects to get a tick in the box. 18

The IFG found that there were concerns that

the agile projects that were underway were

often very minor projects running on the

fringe of the departments and that in some

areas projects may be being labeled as agile

without having really changed the way in

which they were run. 19

Two weeks ago, the NAO has issued a report

surveying the use of Agile Project

Management in the 17 central UK

Government departments. The report was

expressly NOT intended to analyse the

economy, efficiency and effectiveness of these

efforts such Value for Money (VFM)

reports from the NAO are larger, usually

focusing on one department or project. This

recent report aims to identify elements of

agile practices that are being used in central

government departments, rather than analyse

VFM. Although this report is just a warm-up

for analytical VFM reports on Government

technology projects, it does identify the

problem that there is still no specific plan for

tracking the adoption of Agile throughout

Government, and it is unclear how many

Agile projects are actually underway.

Conclusions

To conclude:

What I have found fascinating in my researchare the similarities and the differences


8/10

8

between the US and the UK.

Both the Obama and the Cameron

administrations have similar aims with

regard to flexible IT development, but they

have taken different approaches towards

making the changes.

On the one hand the US IT Strategy has

measurable targets, but they mainly relate to

deadlines for the production of

yet more guidance material on modular

development

running training courses

setting up clear project management

career paths.

On the other hand the UK IT Strategy has a

vaguely defined target of half of major ICT-

enabled change programmes being Agile by

April next year - a great intent, but one that is

difficult to measure.

Certainly, even though both governments

have the aim of moving away from Waterfall,the approach in each case is different. Vivek

Kundra in the US used a hands-on approach

to re-shape failing projects for faster, more

incremental delivery. In the UK a consensual

approach of management by committee has

been adopted.

This is a great area for potential research: the

best estimates are that governments are

responsible for about half of IT spend in boththe US and UK.

One private sector Agilist that I spoke to in

my researches thought that Agile in

Government was an interesting niche for

research.

Well, half of all IT spend is a pretty big niche!

There has been a spate of reports in the lasttwo years from the IfG, the GAO, the NAO

and industry commentators, such as Ovum.

DISA started GCSS-J in 1997 as a prototype.

The system is being developed incrementally

using Agile software development

specifically, the Scrum methodology.20

These reports have recognized that a move to

Agile is a major policy shift, but that more

research is needed into progress.

For example: What is a 'major' programme?

What is, and what is not an 'IT-enabled'

programme? How can we be sure that a

project really is using an Agile approach?

A follow-up survey by the NAO, published justlast month, found it impossible to identify a

consistent list of the Agile projects that are

underway.

There is a window of opportunity here, I

suggest, to assess how the switch to Agile in

the US and UK governments is progressing.

To realise this goal of proving the benefits of

Agile to government, we need research overthe next 3-5 years to show:

How many projects are actually using

Agile?

Which strategies for making the switch

have really worked?

What evidence is there that a switch to

Agile has brought an economic benefit?

This is a fertile area in need of more research- perhaps some collaborative, trans-Atlantic

work.

Will the US resolve and clarify how 'modular'

approaches relate to Agile approaches - are

these terms synonymous? Is the new US

guidance really any more than a new set of

regulations - how can the culture change that

is needed be enacted? And can the vigorous

and decisive leadership during VivekKundra's term as Federal CIO be sustained


9/10

9

now that he has moved on to fresh pastures?

Finally - a unique opportunity for

comparative research is offered by the

existence of two similar Agile strategies,

being enacted in two different countries in

similar timeframes.

It's up to us to take up this research

opportunity, and run with it!

Thank you!

Brian Wernham's new book, "Agile Project Management for Government" was published thisBrian Wernham's new book, "Agile Project Management for Government" was published thisBrian Wernham's new book, "Agile Project Management for Government" was published thisBrian Wernham's new book, "Agile Project Management for Government" was published this

summer by Maitland and Strong.summer by Maitland and Strong.summer by Maitland and Strong.summer by Maitland and Strong.

[email protected]

1 See http://agilemanifesto.org

2 See http://www.agileconference.org/academic-conference

3 Brian Wernham, Agile Project Management for Government: Leadership Skills for Implementation of Large-

scale Public Sector Projects in Months, Not Years. (New York, London: Maitland and Strong, 2012), 24856

4 Vivek Kundra, 25 point implementation plan to reform federal information technology management

(Washington [D.C.]: The White House, 2010)

5 Michael Azoff, Agile in the UK public sector (Ovum, 2012) unpublished manuscript, .

6

UK NAO, The failure of the FiReControl project, 2011,http://www.nao.org.uk/publications/1012/failure_of_firecontrol.aspx

7 Agile for Universal Credit a good choice says report, Campaign for Change, 2011,

http://ukcampaign4change.com/2011/10/05/agile-for-universal-credit-a-good-choice-says-report

8 Tony Collins, Gateway reviews, Campaign for Change, 2012,

http://ukcampaign4change.com/category/gateway-reviews/

9 Justine Stephen et al., System Error: Fixing the flaws in government IT, Institute for Government UK,

2011, http://bit.ly/PWNjCC

10 UK Cabinet Office, Government ICT Strategy, 2011,

http://www.cabinetoffice.gov.uk/sites/default/files/resources/uk-government-government-ict-strategy_0.pdf

11

UK Cabinet Office, Government ICT Strategy, 2011 and UK Cabinet Office, Government ICT Strategy,2011, http://www.cabinetoffice.gov.uk/sites/default/files/resources/uk-government-government-ict-

strategy_0.pdf

12 Emergn, Sourcing for Agile, 2012, 6, http://www.emergn.com/wp-content/uploads/2012/05/TP-Sourcing-

for-Agile.pdf

13 UK Cabinet Office, One Year On: Implementing the Government ICT Strategy, 2012, 9

14 Implementing the Government ICT Strategy: six-month review of progress: NAO Report (HC 1594 2010-

2012), UK NAO, 2011

15 UK Cabinet Office, One Year On: Implementing the Government ICT Strategy, 2012, 9

16 ibid


10/10

2

17 Justine Stephen et al., System Error: Fixing the flaws in government IT, Institute for Government UK,

2011, 14, 30, http://bit.ly/PWNjCC See Figure 1 for a diagram which illustrates the lack of clarity over co-

ordination of the implementation of the strategy.

18 ibid.

19 Government Technology Opportunity in the 21st Century (GTO-21), TechAmerica Foundation, 2010, 18,

http://www.techamerica.org/Docs/gwd4r5.pdf

20 See also US GAO, GAO-12-7 Information Technology: Critical Factors Underlying Successful Major

Acquisitions, 2011, 13, http://www.gao.gov/new.items/d127.pdfand Azoff, M, Agile in the UK public sector,

Ovum, 2012

RAISE2012 - Brian Wernham - 11 October 2012 - Agile Adoption in the US and UK Governments - A...

Documents

Transcript of RAISE2012 - Brian Wernham - 11 October 2012 - Agile Adoption in the US and UK Governments - A...