SIREN: an alarm call for agile?

There have often been predictions of a significant agile development failure. Does this mean agile is doomed to fail? Lawyers from DLA Piper debate the issue

In June the Audit Commission published Grant Thornton's report into the failed SIREN project. SIREN started life in 2005 when the Surrey Police Force identified a need for a new crime, intelligence and custody suite of software products. The Force agreed with its chosen supplier to use an agile development methodology.

However, the project ran into difficulties, the 2009 planned implementation date came and went and SIREN was effectively abandoned, leaving the Force with little benefit for eight years of work.

Yet, the report says, termination was "without cause" (ie the supplier was not at fault) and the Force paid the agreed development cost of £14.8m; a scenario which triggered Grant Thornton's Public Interest Report. How did this happen?

A number of factors undermined SIREN but the report found that two proved key: the customer skill set; and governance and internal controls, both of which are fundamental to agile development projects.

Agile projects demand close supplier and customer collaboration. In SIREN, the report notes that the Force's in-house team was willing but unfortunately did not have the necessary skill set and experience to support an agile development. It also suffered from frequent changes in personnel and external expertise was not brought in until late in the day. The report concludes that the Force's inexperience meant that it did not always recognise when an issue or risk arose for the ongoing project. Its supplier, the report notes, did not compensate for this failing.

Governance takes on heightened significance for agile projects. These projects should "fail faster"; difficulties being identified and escalated quickly. In SIREN, governance and reporting processes were in place but failed in practice. Looking at specifics, the report comments:
• The scope of the project was not well defined, with 140 people working in a "free-for-all" manner - meaning user requirements were unclear;
• Project plans focused on "soft" easily achievable targets (eg meetings; requirements to "start work" on a task) at the expense of "hard" critical milestones (eg testing).
• Progress reporting was "rose tinted";
• Financial reporting was not granular enough to allow a proper assessment of / challenge to the project's claimed financial benefits.

The report does not disclose or analyse SIREN's contract terms, other than to comment that there was no termination for convenience clause and that all development monies were due after a specified period of time regardless of the delivery progress. We know that the Force paid the agreed development costs which suggests that the supplier broadly complied with its contract obligations, such as they were.

The two contractual factors identified in the report contributed to the impact of the ultimate failure of the project. However, the problems with the project started not with the contract, but with the delivery of the project itself.

The takeaway from SIREN is that the customer must understand and prepare for its role in the successful delivery of an agile project. A key benefit of using an agile methodology is that it puts the customer, as the "product owner", in control of the project. However, for this to work, the customer must have the skills, experience and resources to effectively exercise that control.

Bolting on an agile methodology to a traditional customer does not work. Rather than one team within the customer organisation being asked to "do agile", the customer organisation as a whole needs to "be agile" if it is to deliver an agile project of key importance to the organisation.

Callum Sinclair is partner, and Ishbel MacPherson is senior associate at law firm DLA Piper