Hotels.com has said it has significantly sped up its software development lifecycle by adopting Agile principles, reducing the lifecycle from 26 weeks to just a fortnight.
As a result, a new release of the hotel booking website now goes live every two weeks, and the company can better pinpoint the effects of new features on the website’s performance.
“We only had one application releasing through a 12-week cycle, but, when a cycle was in flight, the business had to wait 26 weeks for the idea to go to production,” said Stuart Silberg (pictured), VP of technology at Hotels.com.
Hotels.com first began to move to Agile in the summer of 2009, but at the time it was “really a fast waterfall”, Silberg said. It “re-stamped” the Agile methodology a year later, he added.
The company instructed managed services provider DSP to create a UK-based Agile development team and help it re-architect the web application into logical parts so that upgrades could be made to each part independently, without needing to re-test the whole application.
Examples of apps that have been developed using the Agile principles include Hotels.com’s mobile apps for iPhone, iPad and Android. Hotels.com shares partner Expedia’s data centres, where it uses around 30 to 40 servers, which are based on a standard open source stack of Tomcat, Apache and Java, using a SQL database.
Adopting agile has enabled Hotels.com to improve efficiency by between 20 to 25 percent, and decreased the company’s reliance on offshore software developers based in Eastern Europe, from 90 percent to 50 percent. Hotels.com has several hundred technologists working across development, quality assurance (QA) and operations.
“Distance and the whole lost-in-translation syndrome were at odds with the Agile model. Agile is hard, but Agile offshore is very difficult.
“We weren’t achieving the kind of innovation that we could. There were also concerns about quality and predictability,” said Silberg.
Moving properly to Agile was not without its challenges, however.
“The business had to stop asking for the world at once and plan out iterative features.
“They had to really focus on the ‘what’ and let technology focus on the ‘how’, to understand that there might be bumps in the road, and we may even be slower at first,” said Silberg.
The business also had to learn to communicate with the technology team more frequently throughout the software development lifecycle.
This included providing “better requirements in the form of user stories, being present at sprint planning, mini UATs (user acceptance testing), and at reviews – as opposed to handing over requirements and waiting for a large UAT event at the end,” Silberg said.
He added: “From a professional point of view, they had to trust we would deliver with quality.”