How to contract for agile success

Agile software development has underpinned several standout successes in Australia’s banking and finance sector over the past five years – but advocates still find it difficult to win the hearts and minds of key stakeholders in their business.

Executives in legals and finance, especially, are constrained by traditional project management frameworks that desire fixed cost and scope. The build of a system, these stakeholders would argue, is a project that has a start and end date, fixed deliverables and a fixed budget.

In reality, most organisations embarking on large software projects spend far too long developing requirements. By the time the development team returns with a solution, it often fails to meet current market needs.

Agile, in a sense, is a reflection of this reality. It deliberately pre-empts the tendency for scope to shift. It expects that the production system won’t look and feel precisely as it was first envisioned. It pulls in business stakeholders at regular intervals to shape the product’s direction. It recognises that any software system reflects the needs of a moment in time, and must adapt to changing conditions over time.

But how do you convince Finance to fund a project without an end date? How do you convince Procurement to contract for a project with variable scope? How do you set deliverables for third parties and outsourcers?

Last month, iTnews moderated a panel of senior software delivery executives from some of Australia’s largest organisations to find out how they have navigated these issues.

The appeal of agile

More often than not, agile appeals in the enterprise because it allows for applications to be developed at the same speed as smaller, more nimble competitors.

By breaking down development into small “stories”, with regular stand-up meetings and code review by product owners, new features can reach users faster.

Agile, iTnews’ panel agreed, offers a formula by which business and IT are forcibly aligned.

It offers the opportunity for a large organisation to “change its operating model so the business and IT guys are working closer together,” said Tim Whiteley, executive general manager of enterprise services at the Commonwealth Bank.

CommBank very successfully used the agile methodology for several front-end applications – first to extend its NetBank experience to the world of mobile apps (Kaching) and for an online product that offers self-directed wealth management (MyWealth).

Agile also appeals to Kerry Fullagar, head of architecture and program delivery at insurer Allianz, for many of the same reasons. Allianz has been experimenting with agile for three years “to varying degrees of success”.

“We use a combination of different methodologies, depending on the project. Agile definitely has a sweet spot but others [waterfall etc] still have a role to play,” Fullagar said.

“For us, agile is about getting people to work together early and frequently, rather than write requirements for what you anticipate six or twelve months later.

"It’s about having developers and business analysts working together to deliver an outcome around what current needs are rather than writing to the needs of 12 months ago.”

The contract dilemma

But not all executives encounter agile for the first time with the same enthusiasm.

“When I first came across agile, I saw contracting trouble, to be honest,” says Stephen Holland, a vendor management expert who has worked with the likes of Westpac, Insurance Australia Group and StarTrack Express.

“My first question was, how do I contract for this? How do you contract for an iterative process?”

Holland has seen some ‘interesting’ expressions of requirements for agile software development projects, many of which challenged all the best practices he has learned around contract and project management.

“When you try and write a contract for those requirements, the whole world changes,” he said.

It is difficult to write a watertight contract, Holland explained, for a project in which both its sponsors and participants aren’t precisely sure what they have set out to achieve.

Holland has seen numerous outsourced IT projects come unstuck by not defining specifications, budget or scope in a contract.

His concerns point to the central problem many organisations have with agile: a perceived lack of governance or ‘controls’.

“People feel that because they set a boundary in the contract, they have controlled something,” explains Roger LeBlanc, a global sales executive for IBM’s Rational software business, which markets tools explicitly geared to managing outsourced software development projects.

Within internal IT projects, that ‘control’ revolves around a fixed deadline, a fixed budget and fixed scope.

One banking executive at the iTnews roundtable argued that it is near impossible to nail all three at once. Software projects can be delivered for a fixed budget and to a deadline, but scope rarely stands still. And when projects are late or over-budget, it is invariably because the business sought changes to the original scope.

“They often only discover what they really want when they see it on a screen,” the executive said. “So the project runs over budget, but only because the business changed their mind and scope was adjusted over time. That’s not strictly running over budget when you compare it to the original scope.”

Kurt Solarte, the agile practice lead for IBM, has helped to deliver agile projects for such large Australian organisations as Suncorp and NBN Co.

Solarte said that the “reality” in most 18-month software development contracts is that scope is being “measured again at months 16 and 17".

The irony is that agile – in principle – should enable sponsors to better govern scope and cost, but only if they let go of the “emotional attachment” to knowing all of this upfront.

“The practice of agile is that you prioritise the scope on a much more regular basis,” Whiteley said. “Rather than find out what was not delivered near the end, you’ll have actually decided it along the way.

“So is agile so unpredictable? I think it’s actually more predictable, as the feedback is more frequent.”

Scope and investment should always be weighed against the benefit it will provide, Whiteley said.

“What usually determines if an organisation continues with a project is whether they are realising the benefits. If the project is delivering a great benefit, they keep investing.”

Read on for tips from our panel on how to contract for agile success...