System Error - Procuring Agile

There has been a fair of amount of comment on LinkedIn (although sadly not in the mainstream press) about the Institute of Government's report System Error.

In summary, the report recommends two big ideas, platform and agile.

The platform thread seems to be following the pervasive movement towards the cloud.  The report however substantially ignores security issues, which are often a major additional cost factor in government computing.  It's not good if a bank loses a laptop, or has it's firewall breached, or exposes customer data over the internet.  But when MOD loses a laptop, or a CD, or USB disk, the press have a field day.  While amateur hackers enjoy targetting Microsoft or Sony, state sponsored hackers focus on the big government departments, agencies, and government contractors, for whose security of course the taxpayer pays. Few then correlate the security risk with the cost of making Government devices and information secure.  Any government platform will have to be demonstrably secure, with robust (expensive) processes to maintain security.

Of more interest to the Agile community is the recommendation to adopt agile methods more widely.

Cornwell consultants have been trying to get various government departments to procure more projects using agile methods (usually DSDM, since it seemed most likely to be be approved by OGC) for at least 15 years, with some success.  In general, we were restricted to small-ish projects by the entrenched belief that agile doesn't scale.

We found that while the business sponsors got "agile", procurement often resisted because agile contradicted their standard risk management models.  Finding agile IT suppliers able to work in government was also problematic.

Contracting was always a problem. As soon as the project got near EU procurement, the need for a precise specification and a fixed price took over, and it became harder to get through the gates.  Moreover the time and effort required to bid often made it harder for smaller suppliers to stay in the race.  The usual suspects, with professional bids teams, could always write a compliant bid, and find some colateral to show how agile someone somewhere in the business had been.

What to do?  We've learned never to require "agile" - any salesman worth his commission knows to say "If you want agile, then we're agile".  But when the going gets tough, the tough revert to type, stop collaborating, and go waterfall.  The suppliers' strengths and weaknesses are only revealed late in the project, when stage payments may have already been paid, and it is too late to recover. 

Better by far, to frame the requirement such that an agile response will be a better solution, and assess who has the more agile approach.  Also take up references early, to assess whether the team proposed has indeed been agile.

The contract for agile may not be as difficult as it might first appear.  Agile aims to produce an outcome, not just software. The outcome will include business change, the establishment of new ways of working, not just delivery of software.  Can the contract not be for the desired outcome, stated simply in a few short paragraphs, and not in a requirements/features list?  There must be some criteria to inform acceptance, but again at a high level.  A key differentiator is whether/how the proposals address the need to resolve the detail, what kind of project process they propose.  The risk of delivery is placed, correctly, with the supplier, who works to his strengths, manages his weaknesses, and has to deliver the desired outcome.

Sounds easy, doesn't it?  It's just not often been done up till now.