boosts mobile innovation with continuous delivery’ is a posterchild for UK digital innovation. Indeed, it was a report from co-founder Martha Lane Fox (now Baroness of Soho) that inspired the government’s celebrated “Digital by Default” strategy.

So it is surprising to learn that when John Crosby joined the company as VP for product and technology last year, the travel booking site was not making the most of the latest digital revolution: mobile.

“Mobile is so aligned with the brand proposition, but actually the company’s ability to take of advantage it was very limited,” he recalls.

With consumers making more and more purchase through their smartphones and tablets, Crosby knew that it was an opportunity that had to grasp. “We needed to build a mobile web proposition very rapidly.”

At the same time, Crosby found that the company’s software development processes were not as mature as they had been at Trader Media, publisher of Auto Trader, where he previously worked. “Some people might might have described it as Agile, really it a waterfall process,” he says.

Crosby took the pressing need for a new mobile web offering as an opportunity to introduce some more enlightened development techniques.

“It’s not a project, it’s a product line”
John Crosby


“I wanted to introduce lean principles to our mobile web development,” he explains. “That means putting the customer at the heart of our design process, identifying customer problems we need to solve, and deploying out to the market as quickly as possible.”

In particular, Crosby was keen to introduce continuous delivery. This means setting up a development operation that, instead of piecemeal projects, is constantly releasing new, stable features to the software platform. “It’s not a project, it’s a product line,” explains Crosby.

“My challenge was how we could get that knowledge into the business quickly.”

Crosby turned to ThoughtWorks, a development consultancy that specialises in continuous delivery.

“I brought ThoughtWorks in to show what good looked like, so people could aspire to work that way.”

Continuous delivery

So what is continuous delivery? Inspired by the lean manufacturing principles, and by Eric Ries’ influential book The Lean Startup, the idea is to reduce the risk associated with each new feature by getting rapid user feedback and minimising the interdependencies in the software.

“When you do a new piece of work you do just enough so that when you’ve finished it, you can release the software,” explains Barry O’Reilly, a ThoughtWorker who worked on the project.

To a degree, continuous delivery has been enabled by the growing sophistication of automated software testing. “In the past, testing was done at the end of the development cycle,” explains O’Reilly. This meant you would not find out if everything was going to work until you had already spent months building it.

“Now we’re able to do development and testing in parallel,” O’Reilly says. “So your confidence that the changes you make will not break something is much greater.”
“The more time you invest in development without getting feedback from customers, the bigger the risk you’re taking”
Barry O’Reilly


Encouraging developers to make small, frequent additions to the code base means that if something does break, it is easy to identify the case, explains Crosby. “The smaller the change, the lower the risk, the quicker it is to identify a problem if one happens,” he says.

“The biggest impact of this is that it builds up your confidence,” Crosby explains. “In days gone by where, you used to be very worried at the end of a 3 or 6 months project whether it would work if you went live.

“Now the mindset is, why wouldn’t you go live? We’ve deployed it and tested it 400 times already, we can be confident this will work.”

Rapid feedback loops

Another pillar of continuous delivery is rapid customer feedback. Just as working for a long time without testing code increases the chance that it will break, developing features for months without getting input from users increases the chance that it won’t be what they wanted.

“The more time you invest in development without getting feedback from customers, the bigger the risk you’re taking,” says O’Reilly.

To get that rapid feedback, ThoughtWorks uses techniques such inviting actual customers in every week to give the new features a try, and even going out into the street and putting them in front passers-by. “These techniques are fast and cheap, but they generate insights,” O’Reilly explains. “You get a real idea of what the pain points are.”

Giving software developers this feedback is changing the nature of their role, he adds. “Software developers are becoming product developers – when they’re building something, they understand who it’s for, and what the pain points they’re trying to remove are.”

A third tenet of continuous delivery is creating cross-functional teams. “The classic organisation breaks down by functions – marketing, development, testing, customer service – and they end up becoming silos,” says O’Reilly. “What we do is put representatives of all those functional components in one team.

“The idea is that you are shrinking the feedback loops to be very fast. The developers, testers and operations team are always talking to the business team about what they want.”

Success by outcomes

Starting in May last year, a team from ThoughtWorks team came into and set about implementing a continuous delivery capability.

“The first few weeks were the inception phase,” explains O’Reilly. “This was about bringing the team together and understanding the challenge we were taking on and the opportunity we were trying to address.”

“After that came the execution phase,” he says. “This was about figuring out the key roles that ThoughtWorks people would fill initially, and pairing them up with individuals from within, effectively mentoring them to take over the role.”

“Then, as the project progressed, we elevate the internal people into those leadership positions and gradually drop away the ThoughtWorkers.”

Despite the introduction of an entirely new approach to development, the mobile web project made rapid progress.

“In four weeks we had an initial set of mobile landing pages out there,” says Crosby. “In 12 weeks, we had a mobile web shopping user path up there, and while it didn’t have full online check-out at that point, we were able to direct people to our call centre to complete the booking.

“Within the 16 to 20 week window, we fully rolled out the mobile web path.”

The mobile development team is now working – continuously – on functions and features that might help grow its share of the mobile holiday bookings market.

But without discrete projects, which mean a finite return on investment (ROI) can be calculated, how does know it is allocating the right amount of resources to mobile web development? The answer is by tracking the desired business outcomes.

“We have a scorecard that shows the business outcomes we’re trying to achieve and the quarterly targets – what are we’re aiming for towards in terms of traffic conversion and revenue, etc.,” explains Crosby. “I would argue that measuring success by outcomes rather than deliverables is what everybody should be aiming to be.” is now implementing continuous delivery across a number of other development teams, with eventually goal of everyone working in this fashion.

“What we’ve built is an innovation engine, with constant customer feedback,” Crosby says. “Our vision is that all of our teams will be working in this way.”

Pete Swabey

Pete Swabey

Pete was Editor of Information Age and head of technology research for Vitesse Media plc from 2005 to 2013, before moving on to be Senior Editor and then Editorial Director at The Economist Intelligence...

Related Topics

Development Process