Why agile works

What does success look like?

Every organisation has a slightly different definition of what continuous delivery means from a time-to-value perspective.

Steel cites continuous delivery as the next step in the journey for Commonwealth Bank. He sees continuous delivery achieved via the automation of deployment processes to the point that iterations can be put into production at pace.

CommBank’s agile teams currently work on six-week release cycles - a short time-frame for any financial services industry let alone a big four bank - but Steel thinks there is still work to be done to get to what could be construed as ‘continuous delivery’ in the context of a regulated industry obsessed with risk.

“We’ve got iterations down to six weeks from three months,” he said.

“There is a lot of coordination required to get a major innovation out the door every six weeks. We want to shorten that for certain types of functions such as standalone customer innovation, less so for the deep plumbing inside the group. There will always need to be more scheduled releases for the big iron and systems of record.

“For systems of engagement, we want teams to ship a change that night if it’s ready. We want a train to be able to leave every night, so long as it is based on compartmentalised, safe releases. We aren’t quite there yet. When we have that going it will be fantastic. There is a lot of momentum and excitement in that area.”

Vodafone Hutchison Australia has spent the last 12 months experimenting with the ‘continuous delivery’ model.

Embracing agile allows VHA to experiment at low cost, put a digital product or feature into the market and see if customers will buy it. If customers bite, the focus becomes how to improve it and do more of it.

“Over the last 12 months we’ve looked at how to move from a cycle time of putting software out every six to nine months to now where we can put changes out daily without any downtime, whenever we want,” said Craig Rees, head of technology and product architect at Vodafone. “That’s been a huge journey.”

Bankwest has meanwhile driven agile practices from four teams up to 20. Another 10 would come close to fitting the definition, but not close enough for Ed Cortis, head of systems delivery and a vocal advocate of agile practices. These teams are nonetheless hosting stand-ups and retros, visualising their work, and engaging in practices other organisations would call agile.

A key indicator of the bank’s maturity has been the appointment of iteration managers, who work alongside project managers to focus on releasing services at a greater velocity.

The milestone for agile success, Cortis says, is when such practices are driven by ‘push’ rather than ’pull’.

“The tipping point is when it is no longer me standing on a soapbox, preaching the agile message,” he said. “The tipping point is where somebody comes to you and says, I heard you did good stuff with this, please come help us? That’s when you know it’s no longer an uphill battle.

“We’re starting to see agile practices leak out to the rest of the organisation,” he said. “There are coaches working with the rest of the business.”

For Walduck at Australia Post, continuous delivery means delivering many hundreds of small changes to its online services within the typical defined timeframe allocated to a software delivery project.

This allows for rapid experimentation when the business isn't entirely sure on the business outcome, he said.

“We can adapt and listen and work with our business colleagues in a far more integrated way to evolve ideas rather than define everything upfront,” he said. “We must move to a model in which we are more granular in how we execute and deliver. We need to test, try and learn.”

“As we reinvent our business, as we push into new products and services and as our environment becomes less certain, these adaptive and iterative techniques that are grounded in customer research enable you to realise outcomes sooner.”

Allianz has meanwhile moved from a six-month delivery window to three, and more recently to monthly.

“That’s good progress,” says Mitchell, but “but it’s still a massive effort every time you deploy. I’d like to get deployments into production during the day by the end of this year, if not in the next three months.”

The measure of success for continuous delivery is determined by the length of your longest iteration or sprint, he said.

Success is determined whether you can "press the button" at the end of that sprint and push code safely into production, he said.  

"Once your test team or continuous integration team says it’s done, once your TDD [test-driven development] suite says it’s done, once you’ve run all your performance tests, just deploy it! Why do you need any more governance and ITIL-style hoops to go through? You should be able to trust your process at that point and should be deploying at the end of every agile sprint. That is continuous delivery, in a nutshell."

Mark Cohen, Head of Digital at Fairfax has a one-year target for his team being able to be able to build, test and deploy code into production every day by year end.

“This doesn’t mean I expect the team to be releasing 50 times a day, it matters more that we are capable of it,” he said. “One release a day is the benchmark. We haven’t yet hit the target for saying that we practice continuous deployment, but we’re inching our way there,” he said.

Getting there, says Cohen, requires culture change on a scale few IT organisations have been brave enough to traverse before.

Many of these software delivery leads view the concept of DevOps - and its emphasis on greater collaboration between software development and IT operations – as the required ingredient.

This will be the focus for Pt II of this feature series.