Approaching Cruising Altitude: American Airlines’ DevOps Journey Part 1

A few years back American Airlines started on a journey that was originally focused on DevOps transformation within IT, but has continued to build momentum and evolve into a product delivery transformation encompassing the entire business. This series of posts presents a case study on their journey, based on their 2020 DevOps Enterprise Summit – Virtual presentation. 

Stop Making Excuses and Get Started

In the beginning, American Airlines’ DevOps journey grew out of a series of questions. The first being simply What is DevOps? 

“We were really starting at the very bottom, at the very beginning,” Maya Leibman, Executive Vice President and Chief Information Officer of American Airlines related at the DevOps Enterprise Summit London 2020.

To get started the team did their research, but most importantly they stopped making excuses. In the beginning of DevOps several years ago, most examples were coming from digital native companies like Netflix and Spotify. It was easy for the team to discount their accomplishments—after all, they were born in the cloud. But as more traditional enterprises, companies like Target, Nordstrom, and Starbucks, got on board, American Airlines knew they didn’t have any excuses left. 

To get started they did the following:

1. set concrete goals
2. formalized their toolchain
3. brought in coaches and mentors from outside the company
4. experimented and automated
5. conducted immersive practical training (to learn while they were doing)

But all of this was tied to their ultimate goal to deliver value faster. 

There were so many times when a business counterpart would bring something to the table, a new idea, and they’d say, “Oh this is what we want to do but it’s going to take IT six months or a year to get it done.” And those experiences just killed me. So the impetus behind this was really “how do we not be the long tent pole.” We knew there was a better way of working that would help us achieve that,” Maya Leibman.

Their next step was to decide what outputs they were going to measure. They started with:

• deployment frequency
• deployment cycle time
• change failure rate
• development cycle time
• number of incidents
• mean time to recover (MTTR)

Early successes in value stream mapping helped members of the team better understand the end-to-end processes of the system and inspired motivation. From these successes, they built energy around how to attack it and make it better. They also conducted immersive learning opportunities across IT.

Finance, Friend or Foe?

These initial successes, learning about DevOps and starting to actually practice some elements of it, led them to the second big question on their DevOps journey: Finance, friend or foe?

The current finance approval process was cumbersome and lengthy, with months of approval cycles. “I used to describe it as a process that’s designed to make you give up,” said Maya Leibman.

The process looked like this:

• No projects approved without finance involvement.
• Projects were approved but no headcount added to do them (and no other priorities were stopped).
• Requests were given equal scrutiny regardless of size or risk.
• Requests were given equal scrutiny, even if it was a top corporate priority and there was no question that it was going to be done.
• Projects were often completed before they were approved.

While even finance knew that the process needed to change, a lack of trust between finance and IT caused a block. To help shed light on where the money was being spent and to build trust with finance, they undertook a cost mapping exercise and assigned all the costs to their products, including the costs to run them.

For the IT team, they were able to better see where money was actually being invested and question whether that was the best use of it. For finance, they were able to gain the visibility they needed to trust there weren’t large amounts of waste.

Through this visibility they built the trust to experiment. They took four product teams and gave them a set budget for the year. The teams defined the OKRs and used the budget for the top priorities they felt met those OKRs. This allowed the team to test before rollout and focus on accountability and outcomes, and finance was able to gain even more visibility.

This success allowed them to scale the new model against all of their products and define a new funding process for the full department. “This was a huge accelerator in our journey,” said Maya Leibman.

What’s the Score?

With finance on board and new processes in place, America Airlines discovered with the third question in their DevOps journey: How do we know what the score is?

As they were achieving small successes, they wanted to better understand how they were doing overall. What was the score? Were they finished? 

For the American Airlines team, year one of their DevOps journey was really focused on inputs: learning about Agile/DevOps, focusing on products, cloud, and security, etc. 

In year two of their journey it became more about outputs, including the metrics they began measuring like deployment frequency and mean time to recover. 

Year three was the moment that they started to focus, not just on inputs and outputs, but on outcomes. “At the end of the day, what do we really want to do,” said Leibman. 

They came up with the following outcomes:

• make money
• improve Ops
• increase LTR (likelihood to recommend)
• reduce cost

In year one, one of our objectives was X% of people are going to go to Agile training. That really represents an input. In year two, as we started focusing more on outputs, the objectives sort of changed to X% of teams are going to up their agile maturity from this level to this level. And by the time we got to year three, agile wasn’t even an objective anymore. We realized the inputs and outputs are great, we have to measure them, but ultimately we have to be focused on the outcome.

What’s a Product?

This finally led to the fourth question in their DevOps journey: What’s a product?

It was time to flesh out their taxonomy. This proved to be one of the most challenging moments of their journey. There were lots of opinions and no single right answer. In the end, they decided to just get started, put something on paper, organize around it, and fix it as they learned. And ultimately, this all led to their fifth question: Does this feel way bigger than DevOps?

To answer that and to show some specific product success examples, we’ll continue the American Airlines journey in the next post.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•