Author: devopsy.kinsta.cloud

You may not necessarily recognize the company name IHG – the company I work for – but I bet you’ve heard of our brands and stayed in our hotels. They include household names like Holiday Inn, InterContinental, Crown Plaza and many more. IHG stands for the InterContinental Hotels Group and we’re one of the world’s largest hospitality groups in the world. IHG operates 6,000 hotels in more than 100 countries. And we’re growing fast: IHG currently has 1,900 hotels in the pipeline for opening.

It takes a lot of software to run a global operation of this size, especially one that’s growing so rapidly. IHG employs hundreds of engineers around the globe to build and deploy the business applications and systems that keep our company competitive and growing. As the director of delivery engineering at IHG, which is our DevOps program, I’m tasked with empowering these developers with the tools and processes they need to be productive and successful at their jobs, helping translate their work into business success for IHG.

That’s a tall order for any engineering organization and ours is no exception. But we’ve forged ahead on our DevOps journey, starting by putting together a business case and setting some high-level goals and ambitions for our teams. Our list includes adding more automation and certification to our delivery flows, improving our processes and gaining more transparency and visibility into performance. Of course, we want to support innovation to keep our business ahead of the competition.

After finalizing our goals, we “took them to market,” which in our case meant sharing them with the software development community here at IHG. What could go wrong, you might ask?

Well, right out of the gate we discovered there were significant differences among the teams, their cultures and their tools and processes. The disparity left us struggling to bridge the gap between where we wanted the teams to go, and where they thought they were going. This was going to be a tougher journey than we expected. We had to fail fast and learn quickly.

Rethinking standardization

It became clear we needed to rethink our approach and how we engaged our development community. Recognizing that one size doesn’t fit all, we decided to take more of a consultative or service mindset, focusing more on people and engaging our developer community. After all, we have a lot of smart developers with great ideas that represent an incredible value opportunity.

Our approach features a comprehensive communications plan designed to motivate developers to embrace DevOps. We’re looking at gamification strategies, for example, that would make it fun for people to engage with the program, share their accomplishments and track progress toward reaching their goals. We also want to help team members reduce the amount of time they need for build and deploy processes, so we’re introducing more automation, including developing a semiautomated onboarding process.

Moreover, we’re involving developers in a transparent governance process – one that’s not simply a rulebook handed down and controlled by a third party or some other group in the organization, but one that’s shared and co-developed by our teams. Everybody’s represented in the governance process. Teams from application development, testing and quality, infrastructure and operations, security – and of course the DevOps group – all have a voice and work together to define quality gates and other requirements. It’s a true “voice of the customer” approach that puts developers’ needs first.

Supporting developers

To tame the complexity of our environment, we’ve taken steps to achieve some consistency around things like testing, merge processes and build and deploy routines. However, we never want to hamstring developers by over-defining process flows, so instead we provide teams with simplified workflow or pipeline templates that should work for just about any application.

I’m proud to report that our teams have been making huge progress along our DevOps journey. We’ve helped build about 40 pipelines for dev teams and we’re working on even more. Performance is up: Teams are now able to move a new version of an application to production in less than 30 minutes, compared to taking a week previously. And it now takes less than two hours to deliver applications to eight datacenters worldwide, with no downtime.

We’re also tapping the insights of our developer community by creating an InnerSourcing model where virtually anybody who has a good idea can add it to our code base to benefit the whole organization.

This is just a small sampling of our recent successes. And it’s all happening without micromanaging our developer community. The way we look at it, we’re here to enable and guide our teams, not dictate their choice of tools and processes. By allowing for a diversity of approaches – by embracing not replacing – DevOps is empowering developers at IHG to unleash their creativity and help drive IHG’s next round of growth.

Hendrickson’s career in the software industry spans a few decades and includes stints as a technical writer, developer, and test automation specialist. The variety of jobs has been a good thing, she says, giving her a holistic view of the industry and a deeper appreciation of each step of the development lifecycle.

Hendrickson started on her journey to agile software development after spending several years working for companies that developed software the traditional way, where the roles of code writing and quality testing were rigidly separated. She noticed that despite extensive testing, quality problems persisted. “It looked like QA was doing an incredible job,” she says. “They were finding and fixing all these bugs, so you think you would get better quality.”

Not so, Hendrickson says. “What’s happening is they’re finding the bugs so late in the cycle that it’s too late to fix them all.” Based on that experience, she wrote an award-winning paper debunking the notion that you can correct poor engineering simply by testing more.

In her search of a better way to do quality assurance, Hendrickson crossed paths with Rob Mee, co-founder of Pivotal Labs. “I had been learning about agile software development and I was intrigued by everything he said,” Hendrickson says. It wasn’t long before the future VP of QA joined Mee’s company. The move completely changed her perspective. “This is what software development is supposed to feel like,” she recalls thinking. “I never looked back.”

Agile Creativity

At Pivotal, she came to realize that agile software development was all about getting ideas into the code base in a way that was quickly “shippable,” thus allowing for fast feedback. She saw how waterfall-type approaches, with their multiple stages and signoffs, were actually just a series bottlenecks that slowed innovation. By contrast, agile software development – when done correctly – smooths the path from innovation to delivery. Agile practices were there to support human creativity, not about “process for process’ sake.”

Although organizations have now widely embraced the concept of agile software development, Hendrickson believes one of agile’s core tenets – early feedback – has been forgotten by many, with potentially dire consequences. “Agile done badly can be dangerous,” she says. “If you don’t have any form of feedback and you’re just focusing on being fast, you will end up shipping software that doesn’t work.”

How do you know you’re doing agile right? Hendrickson boils it down to what she calls the “Agile Acid Test.” There are three parts to it:

• Delivering a continuous stream of value. This doesn’t mean developing faster, but rather sooner. You put capabilities into the hands of customers more frequently, in smaller chunks, and get feedback faster.
• At a sustainable pace. Delivering software more frequently doesn’t work if it’s not sustainable for the team. “Doing a death march every month doesn’t work,” Hendrickson says.
• While adapting to the changing needs of the business. As the world shifts, your organization needs to shift with it. Agile software development makes sure you don’t build software products that nobody wants.

Delivering software continuously at a sustainable pace enables you to get the feedback you need to “steer towards value,” Hendrickson says. That’s why she’s always focused on delivering sooner, not faster. And when you think about it more broadly, she says, that’s a strategy that could benefit the whole business.

What else is on Elisabeth Hendrickson’s mind? Tune into DevOps Radio Episode #75 to learn about how she motivates development teams, thrives in a traditionally male industry, and avoids one of the worst mistakes you can make in agile software development.