Agile approach may clash with govt tender policy

Government structures could constrain the adoption of agile development

With the recent cancellation of the Government Shared Network and clouds hanging over some other multi-million-dollar, long-term initiatives, a GOVIS mini-conference earlier this month on agile development in government ICT was perhaps timely.

One of the main claims of agile methodologies is that they allow “mistake” projects to be identified early and fail relatively painlessly, giving at least some functioning deliverables rather than a huge mass of work all of it half finished.

Conference delegates acknowledged, however, that introducing agile into an organisation — particularly a government agency — used to transitional-style development and a traditional tendering process can be difficult.

The process of gentle introduction may involve working internally with agile methodologies, but dressing up the deliverables in a conventional “waterfall” style at first, for the sake of good communication.

Andy Neale, web manager at the National Library, sees the process of RFP, RFI and tendering as not greatly different for conventional and agile bids. The response to the RFP can contain statements about how the developer wants to work, he says.

However, Mark Pascall of developer 3months, says an RFP, when not preceded by an RFI, can be constraining. An RFP is often couched in terms of fixed timeline, fixed quality and fixed scope. Many projects are quite novel and there is an inevitable unpredictability involved. In trying to match those two, he says you’re asking the vendors to lie and the winner of the contract will be the one who can lie most skilfully.

Some RFPs exclude meetings with the vendor; “that to me is ridiculous”, Pascall says. “If you’re going to be working with these people in a room for the next three to six months, you’ve got to know whether you can work with them.”

Agile development cannot really be confined to the ICT element of the organisation, said members of a panel at the conference. The constant interaction with the user uncovers deficiencies in business processes.

A good agile process will throw up suggestions for change to the business processes and organisation, and this may meet resistance. If all the user is looking for is a system to justify an organisational change set in stone, failure is likely, says Mike Lowery, who came from designing a major web system with the BBC to introducing agile to New Zealand’s Accident Compensation Corporation.

From experience of his work introducing agile development at the ACC, Lowery says internal projects such as the redesign of forms have succeeded, but “there is reluctance to open up externally”.

Media were excluded from the conference — despite efforts by Computerworld and delegates to get us admitted — but audio recordings and a partial transcript have now been made available at:

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags agileDevelopmentDevelopment ID

Show Comments