Agile North 2012

Agile Project Management for Government Case study

caseThis paper was used as a syndicate case-study as part of a session run by Brian 29 Wernham at the Agile North conference on June 29, 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: brian.wernham@gmail.com LinkedIn: www.linkedin.com/in/bwernham Twitter: @BrianUkulele #APMFG Blog: brianwernham.wordpress.com

Agile Development of a Combat ID system by the UK 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

9 00 2 no sgd oH , sm a ill iW

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 a Combat 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 realtime 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

t ne mo m e ht ta dn a , nre tA sa d ed na rbe r yll ait rap n ee b sa h do hte m M DSD e ht fo n oit id e t se ta l e hT :e toN

la n igi ro eh t e su o t e u nit no c sre no iti t carp t so m e cni s ,re ve woh ,d e su g nie b em a n r eh tie e e s yam uo y

. nre tA na ht reh ta r n ie reh M DSD e su o sla ll ah s I , em an cim ynor ca

4 00 2 e cne fe D fo yrt sin iM 9 00 2 no sgd oH , sm a ill iW 9 00 2 s cim a n yD l are neG

2 3 4 5

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 as requirements 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. Iteration 2: Extend the software to cater for multiple friendly forces 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 . p , 01 02 KU s cim a n yD l are neG 7 e di lS .p p , 90 02 ro irP ,no sneH 9 00 2 s cim a n yD l are neG

6 7 8

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 controlled by 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 postproject activities. It is the middle five steps that cover the DSDM project lifecycle: 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!
80 02 m ui tro sn oC MDSD

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 the original 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.

1 .p , 07 91 e c yoR W n ot sn iW

01

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 by detailed 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

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 the picture, and to ensure that limitations to scope are understood, some requirements are classified as Wont 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 Haves. 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 Wont 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 making and 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

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 a period 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 being incurred 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

5 4 .p p , 01 02 KU s cim a n yD l are neG

9 e di lS .p p , 90 02 ro irP ,no sneH

11 21

whole project), and a Business Visionary (responsible for decisions on day-today issues). Risks were recorded on a risk register and linked to items on the PRL to provide a means for prioritization and replanning. Again, the overriding 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 all the 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
5 . p , 01 02 KU s cim a n yD l are neG 21 02 ra ha da M

31 41

10

example, was based on a land battle group carrying out counter-insurgency operations. The simulated mission was for the UK to coordinate a multinationality 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 different systems.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.

,VAN CAF ,ta m roF eg a s seM el ba ira V , ,m et s yS g ni k car T te s sA dn uo rG , NAM WOB , 61 kni L/S DIM

63 1 .p ,1 10 2 n en ia le raa s o sla d na ytil ib ap a c d na m ed -no sto lip e vi g dl uo w lo ot DI tab m o c weN SNAM RON d na CaTRON

41 -3 1 e di lS .p p , 90 02 ro irP ,no sneH

51 61 71

11

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 than longer timescales between iterations. Did the CIDS project meet these criteria? Could more have been done to make the project more Agile?

0 10 2 L DS3

81

12

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/c4isr1-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%20ukrockwell%20collinsqinetiq%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/wpcontent/uploads/2011/02/Improving-Outcomes-Through-Agile-ProjectManagement.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 Equipment and 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 LCpl of Horse Matthew Richard Hull. UK Army. Available online at http://www.mod.uk/NR/rdonlyres/887DE696-1DB9-4512-AF8E2ECFED455356/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.

13

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. 19. Available online at http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf.

14