Agile North 2012 - Agile Project Management for Government - Brian Wernham - Case Study Extract from...

7/31/2019 Agile North 2012 - Agile Project Management for Government - Brian Wernham - Case Study Extract from book

http://slidepdf.com/reader/full/agile-north-2012-agile-project-management-for-government-brian-wernham 1/14

Agile North 2012

Agile Project Management for Agile Project Management for Agile Project Management for Agile Project Management for

GovernmentGovernmentGovernmentGovernment Case studyCase studyCase studyCase study

This paper was used as a syndicate caseThis paper was used as a syndicate caseThis paper was used as a syndicate caseThis paper was used as a syndicate case----study as part of a session run by study as part of a session run by study as part of a session run by study as part of a session run by Brian Brian Brian Brian

Wernham at the Agile North conference on June 2Wernham at the Agile North conference on June 2Wernham at the Agile North conference on June 2Wernham at the Agile North conference on June 29 99 9, 2012 in Preston, UK , 2012 in Preston, UK , 2012 in Preston, UK , 2012 in Preston, UK

‘Agile Project Management for Government’ is being published by Maitland and

Strong on July 31, 2012.

You may reproduce this paper on a non-commercial basis in print and on the

Internet, but only in its entirety and as long as you attribute Brian Wernham as

follows:

Wernham, Brian (2012): Agile Project Management for Government. New

York, London: Maitland and Strong

© Brian Wernham 2012 CC BY-NC-ND

See: http://creativecommons.org/licenses/by-nc-nd/2.0 for details

Email: [email protected]

LinkedIn: www.linkedin.com/in/bwernham

Twitter: @BrianUkulele #APMFG

Blog: brianwernham.wordpress.com



2

Agile Development of a Agile Development of a Agile Development of a Agile Development of a Combat IDCombat IDCombat IDCombat ID

system by the system by the system by the system by the UK Ministry of DefenceUK Ministry of DefenceUK Ministry of DefenceUK Ministry of Defence

Two servicemen killed in southern Afghanistan

this week died as a result of friendly fire …

the wrong location seems to have been fired upon.

The Guardian, London

17 January, 2009

On January 14, 2009, Captain Tom Sawyer, 26, of the Royal Artillery, and Corporal

Danny Winter, 28, of the Royal Marines, died in a ‘friendly fire’ incident in Helmand

province. This increased the number of British troops killed by friendly fire in

Afghanistan operations to six. A subsequent investigation revealed that they were

killed by a Javelin heat-seeking missile fired by friendly coalition forces in bad

visibility whilst they were providing mortar ground support.

This was not the first time a missile had been involved in a friendly fire

incident. In October 2007 British troops killed two Danish soldiers with Javelin

heat-seeking missiles.1

The need for better Combat Identification

systems

Poor situational awareness in combat is a key risk factor, often leading to

friendly fire deaths. Both the UK and the US military held boards of inquiry

into the killing of Lance Corporal Matthew Hull in Iraq 2003. The finding

was that the co-ordination and awareness on both sides was lacking:

There can be no substitute for the clear, positive ID of targets linked to

unambiguous confirmation of precise location. The passage of positional



3

data relating to both the target and the nearest friendly forces should be

mandatory.2

In 2009 the UK Ministry of Defense (MoD) initiated a project to create aCombat Identification Server (CIDS). The CIDS was needed to tightly

integrate close air support with shared situational position information – the

technology that gave service personnel almost instant information on the

whereabouts of friendly combatants in deadly situations.

A contract was awarded to General Dynamics to develop the CIDS to be in

place by July 2010.3 It needed to provide autonomous, accurate near real-

time force tracking and location information to direct fire away from

coalition troops. General Dynamics had only 18 months to integrate their

“Net-Link tactical gateway” with their sub-contractors’ specialist technology.Rockwell Collins was to provide its “Rosetta multi-link gateway” and QinetiQ

was to provide its “CMISE correlation engine” which would knit real-time

data together to provide battle information in the heat of war.4

Project Kick-Off and the Foundations Phase

To meet their objective of an 18 month implementation of this lifesaving

software, the MoD chose an Agile approach. They believed that complex

military technologies could be better delivered without delay or unexpected

cost overruns using Agile.

A decision was made to use the “Dynamic Systems Development Method”

(DSDM).5 This is an Agile method which describes a process for supplier

delivery to a customer. The supplier does not need to be a third-party – it

could be the technology department within an organization. The important

point with DSDM is that because it uses a product centric approach it is

potentially a viable approach to teaming up with suppliers to carry out Agile

development.

The first phase of a DSDM project is called the Foundations phase.During this first piece of work, the team analyzed the theoretical payment

plan in the contract and found that it did not match reality. A “win/win”



4

situation was sought by both the MoD and General Dynamics which

recognized the advantages of ongoing re-planning rather than sticking to the

theoretical plan. As evidence of progress informed the team, and asrequirements that had not been identified at project outset were discovered,

the plan would flex.6

The DSDM method helped test and evaluate the solution as a “constant

and regular activity”, and allowed the development team and the stakeholders

to gain more confidence at each iteration.

Three main phases were planned:7

♦ Foundations (Feb – May 2009)

♦ Exploration and Engineering (Jun 2009 – April 2010): in three iterations

of about 3 months each:

o Iteration 1: Create a simple version of the software that could

deal with one friendly force position.

o Iteration 2: Extend the software to cater for multiple friendly

forces

o Iteration 3: Make the solution robust and fast enough to deal with

the operational number of request responses and to interface with systems from other coalition partners.

♦ Deployment and demonstration (May – Jul 2010)

This initial Foundation phase created an architecture that would ensure

tracking information could be collated from 15 different sources in any

battlefield. The UK Bowman system would now collaborate with the key

coalition sources providing friendly position data. For example, the

architecture had to be flexible enough to allow near-real time information on

the position of friendly forces to not only artillery, but also other ground fire

and aircraft. 8

DSDM stresses the need for scalability from the smallest project to the

very largest. It concentrates on governance and structures around

incremental project outputs.



5

DSDM has a long pedigree. It was first published in the UK in 1994 as an

alternative method avoiding the pitfalls of Waterfall methods that were being

encouraged. Although it started as a proprietary method closely controlledby a small consortium, in 2007 the decision was taken to make the method

more openly available. The manual is now available to all for free on the

Internet at www.dsdm.org and training may be bought from many suppliers

(subject to training body certification requirements of the DSDM

consortium). 9

At 202 pages, the handbook may not on first appearances appear to reflect

the ideal of a ‘light-weight’ method. DSDM is process and output orientated.

It prescribes seven main steps for every DSDM project creating up to 43

products – each described in the handbook in some detail.

The first and last of the seven steps simply cover pre-project and post-

project activities. It is the middle five steps that cover the DSDM project life-

cycle:

♦ Feasibility (Step 1) – where an outline business case is created before

much planning work has started

♦ Foundations (Step 2) – where enough (but not too much or too little)

architecture and requirements work is carried out to allow work to start

♦ Exploration (Step 3), Engineering (Step 4) and Deployment (Step 5) –

repeated as many times as required to meet the project aims.

One of the strengths and flexibilities of DSDM is that steps 3, 4 and 5 may

be carried out in whatever order or combined together, or omitted depending

on the technology being implemented, and ease of deployment. For example,

if one month iterations are being followed, but updates to end-users are

restricted by a wider organizational policy to once every three months, then

only every third iteration will include a ‘deployment’ step.

This DSDM method is intended to be very different from the traditional,or Waterfall approach to project management. Waterfall projects are

segmented into discrete phase, each dependent on the completion of the

previous phase, but with no feedback or iteration. When using a Waterfall

approach, one cannot start a phase until the previous has been completed.

This leads to a series of one-way ‘gates’ (see Figure 1). Once one has

committed to swimming downstream, it is impossible to return to an earlier

stage without a lot of effort – like attempting to swim up a waterfall!



6

Figure 1: An example of a Waterfall lifecycle10

The strength of DSDM is that it presents Agile concepts in a structured

fashion, using terms that traditional project managers understand, whilst

avoiding a Waterfall approach. Processes and outputs are defined that are

amenable to ‘traditional’ project management techniques. For example:

♦ Quality planning is used to define the necessary levels of acceptance for

project outputs – this provides a ‘definition of done’ for each output that

can be objectively tested and audited.

♦ Requirements planning is used to maintain Prioritized Requirements List

(PRL), with mandatory release dates defined for all ‘Must Have’

requirements, and tentative release dates for ‘Should have’ and ‘Could

have’ requirements

♦ Earned Value Analysis (EVA) can be carried out to compare the actual

versus estimated development effort originally expected for each product

feature in the PRL, thus providing feedback on the accuracy of theoriginal estimates and the productivity of the team.

Thus a high level of compatibility between the overall Agile approach and

some specific useful formal project management techniques can be achieved.

Techniques such as EVA are mandated by US law for large Government

projects, so this compatibility is very important.



7

The DSDM method adopts the Agile approach to guard against cost and

time overruns by turning the ‘baselining’ model on its head. Previously, a

detailed ‘baseline’ for the scope of a project would be agreed – supported bydetailed assumptions and theoretical estimates, If the estimates were

inaccurate (and of course they often are as they are made before work begins

and actual progress becomes evident) the only variables left in the equation

would be cost and/or timescales. Since the baseline would be fixed, then

these mutually dependent parameters would be flexed –more time would be

taken, with the fixed costs running a large project team continuing to be

borne by the business whilst the timescale for the delivery of a solution

slipped (see Figure 2 – the ‘Traditional Approach’).

But DSDM only fixes a central core of product features at the outset and

flexes the scope as the inevitable mis-estimation of time and cost becomes

clearer. The opposite of ‘scope creep’ takes place – scope is reduced if

difficulties are encountered. DSDM fixes cost and time and flexes the features

to be delivered. In effect, there is zero time or cost contingency, but there is

contingency in the scope of requirements (see Figure 2).

At its simplest, features left out of one iteration are simply deferred to the

next iteration. This can work both ways: if better than expected progress is

made, then features that were only on a wish list for an iteration may be

included – some delight and surprise for the stakeholders!

Figure 2: Waterfall fixes features and allows cost and time to vary – DSDM fixes time and cost,only the number of features vary

DSDM recommends that no more than 60% of the work expected for

each iteration of development should be on features classified as Must Haves

– about 40% of the remaining work is split between Should Haves and Could

Haves. The Should Haves are features that are not absolutely essential, in



8

that workarounds can be put in place if they are not present. Could Haves

are features that bring additional value-add and business benefits, but can be

delayed for future work without any immediate downside. To complete thepicture, and to ensure that limitations to scope are understood, some

requirements are classified as Won’t Haves.

The actual percentages should be reviewed with regard to the

predictability of the overall scope of the project. If the scope is well

understood, in a stable business environment and the target technology has

been previously used, then perhaps a lower percentage of requirements could

be in the tentative category of ‘Could Have’s’. However, it is tempting to

make simplifying assumptions and move back into the realms of traditional

fixed-scope estimating, and then find that the assumptions are false, and that

development will be more problematical than expected. It is better to achieve

an over-delivery of output features than promise too many mandatory

features and under-deliver.

Requirements Planning in DSDM

In DSDM, every requirement for every iteration is prioritized into four

categories, referred to by the acronym ‘MSCW’. Often this is pronounced and

written as ‘ MoSCoW. These are the Must Have, Should Have, Could Have

and Won’t Have requirements. This technique, which is central to DSDM,helps create flexibility and agileness by three tricks:

♦ Once the priorities are set for an iteration, the team working on the

solution is delegated responsibility for which features they are working

on. As the team (of a fixed size) progresses in its work towards a fixed

deadline, the team decides which features will be included in the delivery.

If the delivery is expected to be deployed into live use (rather than as a

prototype demonstration of capability) then the team members, which

includes key users, agree the deployment plan. Decisions are set at the

lowest level possible so as to reduce the cycle time in decision makingand ensure that quality and delivery timescales are met.

♦ The priorities are set for each iteration, but change as the project

progresses. Features that are low priority for one iteration are set as

higher priority in the next iteration

♦ Quality is protected: if an essential feature in the emerging solution is not

of sufficient quality (it functions incorrectly, is unusable, or cannot meet

capacity or other performance requirements) then it can be descoped



9

from delivery in that iteration. Effort instead is focused on ensuring that

the higher priority features are of adequate quality.

How did the Agile DSDM method deliver a

solution to ‘friendly-fire’?

Forward Air Controller engagement scenarios and acceptance criteria

were developed with real-life military operators collaborating in the

development work. The requirements were placed onto a “Prioritized

Requirements List” (PRL) a key DSDM control document. It prioritizes each

requirement, for each increment of work using this MoSCoW requirements

prioritization system.

For example, air requirements such as the Link 16 air intelligence system

were ‘Must have’ requirements, whereas armored situational awareness

systems, such as the Force XXI Battle Command Brigade and Below (FBCB2)

system was of lower Should have priority.11

Developing the CIDS in timeboxes within each

Increment

Each of the three increments was divided into timeboxes. A Timebox is aperiod within which the team is encouraged to get on with work without

interruption. Deadlines are sacrosanct. If within a timebox it becomes

apparent that any of the Must Have requirements are at risk, then effort will

be redeployed away from lower priority requirements.

Timebox deadlines cannot be extended. Any issues became evident

immediately and an attitude of fail early if unacceptable risks escalated was

encouraged. Through a trading process the customer agreed that a few

Should Have and Could Have requirements could be descoped from the PRL.

The important factor was that this was achieved without any penalties beingincurred on the supplier, and no cost or schedule overrun for the customer. 12

The project manager, from the prime supplier, General Dynamics, led

teams from the other sub-contractors (Rockwell Collins and QinetiQ) and

MoD staff and their specialist technical advisors from 3SDL. The MoD

designated an overall Business Sponsor (responsible for the success of the



10

whole project), and a Business Visionary (responsible for decisions on day-to-

day issues). Risks were recorded on a risk register and linked to items on the

PRL to provide a means for prioritization and replanning. Again, theoverriding concern was to maintain an iron grip on cost by flexing the

delivery of functions to deal with risks as they emerged.

Collaboration taking precedence over negotiation

The potential for ‘tit-for-tat’ negotiations over points of detail and costing

were considerable. Trust had to be built between a potentially suspicious

customer not used to an Agile approach, and a supplier under pressure to

deliver. The MoD procurement division initially proposed a severe penalty

clause to guard against the possibility that the supplier would not deliver allthe requirements – even the Could Haves. However, a collaborative approach

was agreed, following the DSDM principles of fixed cost rather than fixed

scope. Any difficulties encountered would be resolved by requirement

trading. In effect the project contingency was held in the Could Have

requirements which could be traded out if unworkable or too onerous.13

Laboratory Integration Tests

As planned, at the end of summer 2009, integration tests started to take place

at the UK Battlespace Laboratory. The Battlespace Laboratory is a completely

independent body managed, and owned by the MoD, bringing together

industry, government and military coalition partners across the world from

the US to Australia.14 The tests took place in a virtual environment providing

systems testing, defense demonstration and preparation for operational

missions in realistic environments providing information on up to 50

battlefield positions simultaneously.

One laboratory integration test took place every third iteration. Each test

used a simulated operational environment to carry out formal tests to be

accepted as a prototype that has demonstrated operational effectiveness. This

test was at “Technology Readiness Level 6” or TRL6. In addition, a

stakeholder demonstration was carried out at the end of teach LIT to increase

customer confidence.

Testing was based on combining together individual user stories into

integrated scenarios which the team termed vignettes. One vignette, for



11

example, was based on a land battle group carrying out counter-insurgency

operations. The simulated mission was for the UK to coordinate a multi-

nationality NATO attack on an insurgent compound in a desert storm.Proof was needed that the system would be able to provide friendly force ID to

all units (including artillery and attack aircraft) in a difficult environment.

The team found that the Agile DSDM method enforced a discipline of

delivering into a formal test environment at the end of every iteration. This

increased the focus on interoperability – the key to the development.

Although various items were re-prioritized for each iteration, in the end, the

flexibility and discipline of the DSDM method adopted meant that important

requirements were not sacrificed.15

Joint US and UK Interoperability Testing

Full coalition interoperability testing with all coalition partners at TRL8 (the

highest technology readiness level) was to take place the next year at “Bold

Quest 2011” organized by the Joint Forces Command. These are the most

demanding coalition Combat ID (CID) capability assessments, and are aimed

to enhance situational awareness, target ID and minimize “collateral damage

and fratricide”.

Rather than wait for that event the MoD decided to carry out a live trials

to prove the system at TRL 7 well in advance of the “Bold Quest 2011” event.

So, in August 2010, in Norway, the new CIDS system was demonstrated

side-by-side with the U.S. CID server and Norwegian and Danish ground and

air forces – and all able to successfully communicate with one another.16

According to 3SDL, who had been contracted by the MoD to organize the

demonstration, both static tests and dynamic tests were undertaken using

known positions and mounted and dismounted Norwegian soldiers exercising

controlled scenarios. Over 90 dynamic user friendly force information

requests were made from the ground and the air using seven differentsystems.17 Throughout the exercise period, the CIDS proved to be highly

reliable, providing friendly-force position data within an average of three

seconds to within five meter accuracy.



12

In addition, even though the Danish aircraft had not been specifically

prepared for the exercise when they arrived they were immediately able to

make successful requests friendly force ID using their Link 16 technology.

18

Discussion Questions

1. The MoD, as customer, had indicated its eagerness to use an Agile method.

If the MoD had specified a Waterfall approach what arguments could the

suppliers have used to convince them of the risks of Waterfall and the

advantages of Agile?

2. The MoD had indicated their inexperience with Agile. What risks were

there in using an Agile approach?

3. What strengths and weaknesses are there in the application of DSDM to the

CCID project outlined above? (Draw on your own business experiences of

projects – whether Agile or Waterfall).

4. The MoD procurement division had been keen to ‘nail down’ the suppliers

to a fixed specification. What may have been their thinking? How would

you draw up an Agile contract that would suppliers to account?

5. Agile projects are expected to iteratively deliver a working solution. An

Agile project should have a natural preference for shorter rather thanlonger timescales between iterations. Did the CIDS project meet these

criteria? Could more have been done to make the project more Agile?



13

Publication bibliography

Slabodkin, Greg (2011): New combat ID tool would give pilots on-demand

capability. Available online at http://defensesystems.com/articles/2011/02/28/c4isr-

1-blue-force-tracking-sidebar.aspx, checked on 18/06/2012.

3SDL (2010): Case Study: Exercise Bold Quest 2010. Available online at

http://www.3sdl.com/success-stories/exercise-bold-quest.aspx, checked on

18/06/2012.

DSDM Consortium (2008): DSDM Atern The Handbook. v4.2.

General Dynamics (2009): General Dynamics UK-Rockwell Collins-QinetiQ team

completes Foundation Review on situational awareness contract. Available online at

http://www.generaldynamics.uk.com/news/general%20dynamics%20uk-

rockwell%20collins-

qinetiq%20team%20completes%20foundation%20review%20on%20situational%2

0awareness%20contract, updated on 26/08/2009, checked on 18/06/2012.

General Dynamics UK (2010): Application of the Dynamic Systems Development

Method in a Complex Project Environment. Helping clear the ‘fog of war’. DSDM

Consortium. Available online at http://www.dsdm.org/wp-

content/uploads/2011/02/Improving-Outcomes-Through-Agile-Project-

Management.pdf, updated on 10/04/2010, checked on 18/06/2012.

Henson, Stuart; Prior, Jon (2009): UK MOD Combat Identification Server (CIDS)

Technology Demonstrator Programme - Presentation. UK MoD Defence Equipmentand Support. International Data Links Symposium 2009 (IDLS2009). Available

online at

http://idlsoc.com/Documents/Symposiums/IDLS2009/Day1/D1_MAIN_Combat_Ide

ntification_Server_Mr_Henson_Programme_Director_TDLs_MOD_UK.pdf, updated

on 12/08/2009, checked on 18/06/2012.

Madahar, Bob (2012): Open to ideas (Defence Management Journal, 49). Available

online at

http://www.defencemanagement.com/article.asp?id=399&content_name=ICT&artic

le=12608, updated on 18/06/2012, checked on 18/06/2012.

Ministry of Defence (2004): Board of Inquiry Report into the death of the late LCplof Horse Matthew Richard Hull. UK Army. Available online at

http://www.mod.uk/NR/rdonlyres/887DE696-1DB9-4512-AF8E-

2ECFED455356/0/boi_lcpl_hull.pdf, updated on 21/02/2006, checked on

18/06/2012.

saarelainen, tapio (2011): Enhancing Situational Awareness by Means of Combat-ID

to Minimize Fratricide and Collateral Damage in the Theater. ICDT 2011 : The

Sixth International Conference on Digital Telecommunications, updated on

7/11/2011, checked on 18/06/2012.



14

Williams, Rachel; Hodgson, Martin (2009): MoD launches friendly fire investigation

into deaths of two British soldiers in Afghanistan. The Guardian. London. Available

online at http://www.guardian.co.uk/politics/2009/jan/17/mod-friendly-fire, checked

on 18/06/2012.

Winston W Royce (1970): Managing the Development of Large Software Systems. In

: Proceedings, IEEE WESCON, pp. 1‐9. Available online at

http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf.

Agile North 2012 - Agile Project Management for Government - Brian Wernham - Case Study Extract from...

Documents

Transcript of Agile North 2012 - Agile Project Management for Government - Brian Wernham - Case Study Extract from...