Fairfax Digital targets daily release cycles

Fairfax’s team of software developers intends to have the capacity to release new versions of their online, mobile and app properties on a daily basis by the end of this year.

The publishing company manages diverse media investments running on a multitude of platforms, requiring some 170 developers, testers and digital specialists to keep up-to-date.

For the last three years, Fairfax’s head of digital Mark Cohen has instilled agile culture into the company, with the whole team working to a version of Scrum.

His progress has been marked - the majority of digital teams currently work in three week sprints. This means small, incremental changes are made on any given property every three weeks, with the release dates of each group staggered for efficient allocation of product management resources.

It may be some time before Fairfax can attain a consistent approach to agile for all its properties. On some of Fairfax’s most modern digital titles, releases can be made multiple times a day.

But for those running a more mature CMS (content management system), daily releases are all but impossible. “They simply weren’t designed that way,” Cohen told iTnews.

Cohen has been promoting the value of faster release cycles to his staff and more broadly to the business.

“Our value to the business is how quickly we can turn something around,” he said.

“If you intend to test a new approach to SEO (search engine optimisation), you don’t want to measure changes in increments of three weeks at a time. If you think about publishing in terms of a ‘minimal viable product’ – a key principle of agile – it might be a flat HTML page. If you could build that in a day, why wait to release it in three weeks?”

Cohen has set a new KPI (key performance indicator) for the business – the ability to build, test and release a change every day.

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

Cohen said he had enjoyed strong buy-in from those most affected by the change – developers and testers.

“We haven’t yet hit the target for saying that we practice continuous deployment, but we’re inching our way there,” he said.

“When I introducing this as a formal KPI in our strategy meeting  for 2014 with my direct reports, something interesting happened: I started talking about the goal of continuous deployment, and all I heard from my staff was – 'but of course, this shouldn’t be a question, we should be doing this'. They know this is what we have to do.”