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...

Keep your friends close

Governance issues are particularly pertinent to outsourced software development – which in the banking and finance sector represents up to 75 percent of the work undertaken.

Agile is again an attractive option for an organisation looking to engage with outsourced partners, says Allan Gillard, a senior architect for Sydney Water, because it “addresses the disconnect between requirements gathering and passing that to an outsourced developer to build.

“By shrinking that down to a work package, and by getting the business involved [via stand-ups, code drops], you have that much of a quicker turnaround time, and less misinterpretation of requirements,” he said.

But while it might work for the customer, agile has not been the “natural starting position” for many large systems integrators that generate their profit from long-term contracts. Nor is the close collaboration required for agile that easy to achieve when outsourced software developers are based in India or China.

Solarte – an agile lead at the world’s largest systems integrator – agreed that many people within the SI community are “scared of working the agile way.

“We have the same struggles internally that you do,” he assured the banking and finance executives.

‘The reason agile works at our largest Australian customers is because those customers sorted out how they wanted to do agile first,” he said.

“The struggle comes down to change management. It’s only a struggle when an organisation wants us to complete a massive IT project for them, while simultaneously changing how we interact with the business, how IT reports in, everything all at once.”

Within a short few weeks of planning with one large Australian bank, IBM and the bank managed to “map out how agile can sit alongside ITIL and ISO20k”, but only because the client had done their homework first.

One key challenge is achieving the same level of trust with an outsourced partner that a business might enjoy with its internal IT team.

Overcoming concerns over the governance, risk and scope of agile projects “gets back to a central issue of trust”, Fullagar said.

“It requires a healthy relationship between business and IT. We’re fortunate we don’t outsource a lot of stuff and do everything internally, so we have those healthy business relationships. We have the business coming to us and asking to do agile projects because they have heard of the success from their peers.”

That same level of trusted relationship can be achieved when working hand in hand with one systems integration or software development partner, LeBlanc said.  “But if you work with multiple systems integrators, it’s rare you’ll find a similar approach and a similar attitude to Agile from all of them.”

LeBlanc recommends a two-week “all hands on keyboards” consultation with all parties at the commencement of a project to “come up with where the touch points for the business are.”

“You need to define what a good enough governance level is for the right level of collaboration, without impeding on the ‘how’,” he said. “From everything to initial solution design through to pre-acceptance testing, it needs to be clear what you expect each supplier to deliver on.

“We’ve seen a predictable and consistent construct as to what those touch points are across the development lifecycle.”

LeBlanc concedes this level of preparedness doesn’t sound much like an agile approach.

“The question is  - how do you decouple this governance layer from [agile] execution? I would argue that there can still be an agile mindset to that discussion," he said.

"Just because something is predictable, it doesn’t mean it’s traditional. There is a way of adding more predictability to the process – a way to trade up scope.

"It might not mean firming up everything initially, but firming up how we’ll make those decisions along the way. Even if the outcome isn’t 100 percent predictable, how we’re going to get there is a little more predictable.”

How to define success

Holland feels the best way to contract for agile is to document each iteration of the software as a “statement of work” that aims to deliver a specific outcome.

Negotiators should “make the outcome the primary consideration,” he said.

LeBlanc recommended two tiers to an agreement: a long-term contract for 10 months to two years, and shorter “work authorisation” processes that slot in beneath it.

“That way you don’t need to go back to legal for every change – you can right-size your scope as you get more feedback and the project changes. We’ve found that two-tier contracting model to be quite effective.”

Solarte said IBM Global Services began contracting for agile projects using a similar “work authorisation” approach. Typically that would involve at least a 12-month contract, with releases every six weeks and code drops every fortnight.

This, he said, usually introduces the agile methodology and the relationship between parties effectively.

More recently, the systems integrator has evolved toward what Solarte calls “capacity-based” contracts.

This involves contracting for a set capacity (person-hours or person days) over a fixed time period to meet a stated outcome, with the contract specifying that the customer is able to adjust that capacity upward or downward by no more than 15-20 percent at each review period. Review periods might be as often as every six weeks or up to every quarter.

This allows a large organisation to ‘ramp up’ and ‘ramp down’ development efforts according to the development lifecycle of the software. Customers have noted, however, that it can be difficult to track what specific talent is working on the deal.

But so long as the contract focuses on the outcome, these specifics may not be relevant.

When the Commonwealth Bank gives “outcomes-based pieces of work” to an outsourcer, “we try not to get in the middle of their methodology,” Whitely said. “They should simply deliver as efficiently as they can.”

“You have to step back,” Holland agreed. “You are now paying someone for an outcome. Do you care how they get to the outcome?”