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?”