mod gets agile article - extract from computer weekly may 28, 2013

7/30/2019 MoD Gets Agile Article - Extract from Computer Weekly May 28, 2013

1/4


2/4computerweekly.com 28 May- 3 June 2013 20

HOME

NEWS

IAN IT SERVICES

OMPANIES MUST

LVE TO PROSPER

CKBERRY TAKES

MESSAGING

ROSS-PLATFORM

URAC MIXES ERP

ND BI FOR MORE

GILE REPORTING

LOTUS F1 TEAM

YS AHEAD WITH

DATA ANALYTICS

EDITORS

COMMENT

OPINION

BUYERS GUIDE

MOBILE DEVICE

MANAGEMENT

IT INNOVATION

LLENGES IN THE

ANCIAL SECTOR

MOD USES AGILE

FOR LIFESAVING

MBAT IT SYSTEM

DOWNTIME

AGILE DEVELOPMENT

T he US, UK and other Nato forces have been developing and improving combatidentication systems over many years. In 2009, the UK Ministry of Defence(MoD) initiated a project to create a combat identication server (CIDS). TheCIDS was needed to tightly integrate close air support with shared situational

position information.

A contract was awarded to General Dynamics todevelop the CIDS and have it in place and ready for useby July 2010. It needed to provide autonomous, accu-rate near real-time force tracking and location informa-tion to direct re away from coalition troops. Every fewseconds, CIDS would need to integrate data from all thefriendly forces in a battleeld and distribute it back to allthe nearby unit commanders.

General Dynamics had only 18 months to integrateits Net-Link tactical gateway with specialist technol-ogy supplied by its subcontractors, Rockwell Collinsand QinetiQ.

To meet its objective of an 18-month implementation of this lifesaving software, the MoDchose an agile approach, through which it believed the complex military technologies couldbe better delivered without delay or unexpected cost overruns.

T H I N K S T O C K

CW500:Agile

techniques forsoftware

development

UsingSSADM and

DSDM forrapid

applicationdevelopment

Lifesaving software getsthe agile treatmentBrian Wernhamreports on how the Ministry of Defenceused the DSDM agile development framework tomanage the creation of a combat IT system

THE MODCHOSE AN AGILE APPROACH FOR ITS COMPLEX MILITARY TECHNOLOGIES



HOME

NEWS

IAN IT SERVICES

OMPANIES MUST

LVE TO PROSPER

CKBERRY TAKES

MESSAGING

ROSS-PLATFORM

URAC MIXES ERP

ND BI FOR MORE

GILE REPORTING

LOTUS F1 TEAM

YS AHEAD WITH

DATA ANALYTICS

EDITORS

COMMENT

OPINION

BUYERS GUIDE

MOBILE DEVICE

MANAGEMENT

IT INNOVATION

LLENGES IN THE

ANCIAL SECTOR

MOD USES AGILE

FOR LIFESAVING

MBAT IT SYSTEM

DOWNTIME

AGILE DEVELOPMENT

A decision was made to use the DynamicSystems Development Method (DSDM) frame-work because it gives guidance on the processfor agile supplier delivery to a customer. Thecustomer does not need to be a third party itcould be the technology department within an

organisation.The important point with DSDM is that

because it uses a product-centric approach,it has the potential to be used to formalisepayment milestones with suppliers based onproduct deliveries.

DSDM avoids pitfalls of waterfall projects

DSDM requires just enough design up front (EDUF), and the foundation phase should beas short as possible, while still ensuring an essential understanding and clarity of structureof the overall solution and to create an agile plan for delivery.

This initial foundation phase created an architecture that gave both the MoD and GeneralDynamics an assurance that minimum acceptable performance levels could be achieved. Forexample, tracking information on the position of friendly forces needed to be collated froma minimum of 15 different units in any battleeld.

The architecture also had to be exible enough to allow near-real-time position informa-tion to not only artillery units, but also to nearby aircraft. The approach ensured that testand evaluation of the solution was a constant and regular activity, and allowed the devel-opment team and the stakeholders to gain more condence with each iteration.

The project would run from February 2009 to July 2010. Overall plans were agreed at theend of the foundation phase, which took three months. Then the exploration and engineering

phase started ,with three iterations, each about three to six months long:Q Iteration 1: Create a simple version of the software that could deal with one friendly forceposition.

Q Iteration 2: Extend the software to process multiple position information.Q Iteration 3: Make the solution robust and fast enough to deal with the operational num-

ber of request responses and to interface with systems from other coalition partners.Iteration and feedback is the core of DSDM, and it makes

it very different from waterfall approaches. Its strength isthat it presents agile concepts from a management pointof view, using terms that traditional project managersunderstand while avoiding a waterfall approach. Like many

methods, though, it has little to say about leadership behav-iour. Processes and outputs are dened that are amenableto traditional project management techniques, but have anagile approach.

The DSDM framework is an agile approach that guardsagainst cost and time overruns by turning the baseliningmodel on its head. In a waterfall project, a detailed baselinefor the scope of a project needs to be agreed on sup-ported by detailed design assumptions and theoreticalestimates. Hence the phrase big design up front (BDUF).

If the estimates are inaccurate which they often arebecause they are made before work begins and actual progress starts to be measured theonly variables left in the equation are cost and/or timescales. Stakeholders ex their mus-cles and ask for additional nice-to-have features, which cause the required amount of workto increase a situation known as scope creep. This is why so many waterfall projects go

ITERATION AND FEEDBACK IS THE CORE OF DSDM,AND IT MAKES IT VERY DIFFERENT FROM WATERFALL APPROACHES

FAQ: Agilemanagement

and leadership

Project phasesin DSDM Atern



HOME

NEWS

IAN IT SERVICES

OMPANIES MUST

LVE TO PROSPER

CKBERRY TAKES

MESSAGING

ROSS-PLATFORM

URAC MIXES ERP

ND BI FOR MORE

GILE REPORTING

LOTUS F1 TEAM

YS AHEAD WITH

DATA ANALYTICS

EDITORS

COMMENT

OPINION

BUYERS GUIDE

MOBILE DEVICE

MANAGEMENT

IT INNOVATION

LLENGES IN THE

ANCIAL SECTOR

MOD USES AGILE

FOR LIFESAVING

MBAT IT SYSTEM

DOWNTIME

AGILE DEVELOPMENT

over time and budget. Since the baseline is xed, these mutually dependent parameters areallowed to run out of control.

DSDM is an agile method and therefore has a different philosophy from the waterfallapproach. When it is used as the project management framework to guide the team, only thecentral core of solution features is identied at the outset. The scope is allowed to change, ina controlled manner, as the inevitable mis-estimation

of time and cost becomes clear. The opposite of scopecreep takes place scope is reduced if difcultiesare encountered, rather than time and budget beingincreased. The project comes in on time and costbecause DSDM xes these variables, and insteadrescopes the features to be delivered.

DSDM suggests that no more than 60% of the workexpected for each iteration of development should beon features classied as must-haves. About 40% ofthe remaining work is split between should-haves andcould-haves.

The should-haves are features that would be pain-ful to leave out, but a workaround could be found forthem otherwise a must-have would be compromised.Could-haves are features that bring additional value-add and business benets, but can be delayed for futurework without any immediate downside. To completethe picture, and to ensure that limitations to scopeare understood, some requirements are classied aswont-haves.

Developing the CIDS in timeboxes within each increment

In the MoD project, each of the three to six-month long increments was divided into time-boxes of a month. In each timebox, the team, which included domain experts, was encour-aged to get on with the work without interruption. Deadlines were sacrosanct. If, within atimebox, it became apparent that any of the must-have requirements were at risk, then theteam self-organised the redeployment of people away from development of solutions forlower priority requirements. This is the essence of agility: decisions are delegated to thelowest possible level to those closest to the work at hand.

The supplier project manager from General Dynamics led a multidisciplinary teamcomprising staff members from the other subcontractors (Rockwell Collins and QinetiQ)and MoD staff and their specialist technical advisors. On this project the potential for

tit-for-tat negotiations over points of detail and costing were considerable. Trust had tobe built up between a potentially suspicious customer not used to an agile approach and asupplier under pressure to deliver.

The MoD procurement division initially proposed a severe penalty clause to guard againstthe possibility that the supplier would notdeliver all the requirements even the could-haves. However, a collaborative approach wasagreed, following the DSDM principles of xedcost rather than xed scope. Any difcultiesencountered were to be resolved by require-

ment trading. In effect, the project contingency was held in the could-have requirementswhich could be traded out if unworkable or too onerous. Q

UNDER THE DSDM METHOD,THE SCOPE IS ALLOWED TO CHANGE , IN A CONTROLLED MANNER , AS THE INEVITABLE MIS-ESTIMATION OF TIME AND COST BECOMES CLEAR

Brian Wernham is the author of Agile Project Management for Government, published by Maitland and Strong.Click here for a discount on the full price

i Transitioning a Waterfall team to an Agile development teami Ten ways Agile development process, Waterfall approach differ

i Waterfall versus Agile development: A case study

mod gets agile article - extract from computer weekly may 28, 2013

Documents