GOVIS hosted a panel event last Monday called “Government Projects the Agile Way: Can It Be Done?”. After listening to the panel discussion and hearing the questions coming from the audience, my take on the question would be a qualified “Yes”.

Presenters and audience

There were a good range of presenters: Mike Lowery from ACC, Andy Neale from Digital NZ, Liesle Venter from the Department of Conservation and 3months’ own Mark Pascall. Having a (small) range of organisations all excited to get Agile practices off the ground is a great start. The panelists had different levels of experience with Agile, but were all confident with what it could bring them. The discussion from the panelists didn’t over-complicate the topic. There was also a good turnout, with a range of informed and challenging questions coming from the floor. The questions made me realise that people genuinely care about the opportunities on offer.

Pragmatism

The prevailing mood from the panel was around finding pragmatic ways to implement Agile practices. The approach of starting with an appropriately sized project was bashed about by the panel, with views tending towards “take it easy for the first one”. I’m in absolute agreement with this approach – my experience has been that adopting a new methodology of any kind is disruptive to an organisation and is bound to be met with resistance, so it makes a lot of sense to make sure the first project off the block demonstrates some value without playing in a highly sensitive space. The other aspect discussed was the level of organisational change needed to make Agile succeed. Again panelists were in violent agreement: you are better off leading the transition to Agile with a success rather than trying to reinvent your organisation first.

Timing

This didn’t come up as a topic in the discussion, but it’s a big factor in adoption and was touched on by some of the speakers. As far as I’m concerned there couldn’t be a better time to kick off a transition to Agile in any organisation and specifically in the public sector. My top three reasons for this:

• Money is tight. If you need to deliver more with less, what better than to use a method that enables you to pick off the top 20% of value from a project and let it show a return before delivering all of your “nice to haves”.
• The environment is changing rapidly. Agile is a great enabler for letting your customers change from iteration to iteration (every two to four weeks) providing everyone is willing to prioritise.
• Appetite for risk is increasing. Bear with me on this one. In the world of waterfall and monolithic delivery, risk aversion is built in to the process at increased cost and complexity. Requirements documents completed before design, detailed designs completed before development, and complex and punitive project change control processes – all of these things exist to give management a signature to point back to (and yes, other more practical reasons too). All this achieves is more expense and less visibility of progress, with customers waiting six to nine months for the first appearance of completed software. This risk averse approach is causing organisations to lose out on opportunities. Organisations need to be able to realise project risk faster, and either deliver change or pull the plug earlier if changes aren’t going to provide needed value. Agile (and iterative) methods provide this.

Procurement and governance

So what could stop a transition to Agile from succeeding? The panelists discussed a couple:

• Request For Proposal processes: while the panelists did a good job of pointing out that RFPs don’t exclude Agile practices, RFPs can be weighty and can get in the way of a good conversation. Often RFPs are issued with fixed time, cost, quality and scope. As one panelist pointed out, for a software project this kind of request is asking respondents to tell fibs.
• Management buy-in to Agile: governance groups don’t need to be overly familiar with the process, but do need to be value-focussed rather than detail focussed. Governance groups should be there to make sure the product you’re building is delivering the value they’ve signed up to, not changing your background colours and fonts. Governance groups also need to be educated about scope trade-off that happens in an Agile project.

Government Projects the Agile Way: Can It Be Done?

Government agencies can learn to work with vendors who use Agile and do so in a way that increases their return on investment. This is happening now and the success of projects delivered in this way will lead to more of the same. Successful Agile projects will be led by responsive business owners who understand value and teams who know how to deliver it. Those that fail will fail fast and free up scarce budgets for new projects.

Will government agencies succeed in adopting Agile practices internally? I personally think this is a bigger challenge and will take a lot longer to take hold. Those that do make the transition successfully will be value driven, adaptable and not afraid to take risks.

There are plenty of opportunities to find out more about Agile: the Wellington branch of the Agile Professionals Network gets a great turnout for its events and Agile topics are cropping up on the agendas of GOVIS, the CIO Summit, the PMI NZ conference, Webstock earlier this year and almost anywhere else you can fit it in.