Information Age: What prompted you to introduce the Agile methodology at BA?
Mike Croucher: When I took over development at BA ten years ago, I wanted to drive predictability in development projects. So I put in a very clear ‘waterfall’ technique based on the Capability Maturity Model Integration (CMMI) process improvement approach. And by doing that, we certainly achieved a very high level of predictability and the organisation was delivering well.

But over the past two years, the IT department has been required to become even more flexible in terms of reacting to changes in market conditions. Even before the economic crisis, we recognised the need to be able to handle change, rather than just be predictable.

The typical waterfall and CMMI method tries to avoid change, through change orders and various change management processes. So we decided to experiment with Agile.

What was happening with your levels of staffing at the time?
Our IT department is based on a four-layer model of personnel: we’ve got a commodity layer, an integration layer, a management layer and a strategy layer to our people.

For many years we’ve outsourced the commodity layer, using global resourcing in places such as India. In the economic crisis, we needed to scale back the size of our IT department so we scaled back those global resources. But that meant we lost the developer skill set.

We wanted to address this by reskilling the analysts who were developers in the past. That was another good reason for adopting Agile.

How did you go about introducing the methodology?
About two years ago, we used Agile on a project developing functionality for our website, with a small team of about seven or eight people.

The project didn’t go exceedingly well for a number of reasons. We certainly weren’t focused enough on business value, and we didn’t get the right customer engagement. We hadn’t changed the mindset of the business to match the culture of Agile so they were still thinking in a more traditional way, even though we were trying to put iterative development in.

We learned a lot from that project about Agile and about how to get the business engagement we needed. At the end of the pilot we decided that Agile was the thing for us but that we hadn’t executed it very well.

After the pilot, what functional areas did you apply Agile to first?

First, we used Agile with our mileage company, which is like a rewards system for executive passengers and is a separate profit and loss [division] of British Airways. They had a very clear business proposition, which was to generate more revenue by making the Airmiles scheme more flexible and allowing members to buy flights partly with cash, partly with Airmiles.

With the traditional waterfall approach, we would have said we need to have a very complex rules engine that controls what we offer the customer based on the inventory available. Then we would have built all that and loaded it 18 months later.

Instead, under the Agile approach, we said, “Let’s build a simple offer that allows you to pay 50% in cash, 50% in Airmiles.” That was the first release, and was running live on the website after two weeks.

Then we started to introduce the complexity. In the second iteration we brought in five different options for the ratio of cash to Airmiles. Then we started to put in a rules engine that allows you to control those percentages dependent on other conditions, and we slowly started to introduce more complex rules.

Each one of these was a live implementation being used by customers and generating revenue. By making it live and generating revenue from the first week, you achieve your return on investment much sooner. For me, Agile is about driving business value early.

Also, you get better value for money because you only deliver the higher-value components of a project. Once you’re only developing the lower-value components, you move on to something else. In the past, we were often delivering software that was never actually used.

Coaching

How did you train your employees in the Agile methodology?
We received coaching from a company called emergn. They have a coaching philosophy: they didn’t come in and do it all for us, they coached my own people to do it themselves. This made it very scalable. We weren’t flushed with money during that time, so it was important for me that my people would take on the responsibility [for implementing Agile] rather than bringing in contractors and consultants to lead it.

Bringing in people who were prepared to challenge our cultural thinking was really key, because adopting Agile is a cultural process. If you say, “I don’t like that bit of it, let’s leave it out,” you end up going back to your old culture.

What kind of employee received the coaching?
At BA, we have quite a clear set of role profiles, from technical designers to functional leads, project leads, developers, testers and business analysts. But I was brought up in a world where everyone did a bit of everything.

As part of the move two years ago, I introduced a new role called simply ‘software engineer’. I wanted there to be a role that said you need multiple skills – you need to be able to code, you need to be able to test, you need to be able to analyse code and to talk to the business. And that software engineering role became the role that I used to seed my Agile team.

How did you choose who to train first?
We were quite selective about who we put in there at first. I wanted it to be a success, so I went after people who are comfortable with standing up and talking about what they are doing. That is not a skill we’ve always valued in IT.

In an Agile world, the developer must have courage. They need to be able to say to the business, “I only have this much ‘velocity’, so you can only have certain features – what do you want me to prioritise?” And they have to be asking, “Are we driving the top-value items or are we driving something that is just nice to have?”

Since then, I’ve scaled it up so we can put anybody into Agile training, because it does them good. It takes them out of their comfort zone.

How was the Agile methodology received by your engineers?

I had individuals who kicked against it and I said, “That’s fine, come out of the Agile team.” But the ones who like it really like it.

I put one of my ‘Scrum masters’ in with one of my legacy teams who didn’t see the value of Agile and didn’t see why they should change. It took three months, but now they love it.

What proportion of your development practice now uses Agile?

At the moment we are using it in around 20% to 25% of my IT shop and I’m expanding it. We want to try it in new areas.

Which technical areas are suitable and which are not?
We have found Agile easier to use with front-end, customer-facing systems than with operationally critical, compliance-led systems, because the methodology deals with incremental change.

If I’m building a system to support some legal requirements to track the whereabouts of my employees, I can’t be 80% legal. It needs to be 100% compliant from the moment it starts. I’m looking for things where the end proposition can be broken down into many features.

Can I use it for large infrastructural builds? Does Agile require a stable platform or can I use it as I develop infrastructure? These are things we’re still finding out.

Agile in business

You recently extended Agile beyond IT into the business. How did that come about?  

During the past year, we wanted to find new ways to generate more revenue very quickly. But one problem we’ve always had is the time it takes for an idea for a new revenue stream to become a value proposition, even before it enters the IT shop. The longer people work on these propositions, the more they get attached to them, and they can end up trying to justify that proposition when they might actually need to kill it.

So the business decided to set up Agile-like teams for developing value propositions called Revenue Labs. We lent them some Scrum masters to do this, and now they are training their own.

We try to separate what these Revenue Labs do and pure Agile, which is a methodology specifically for IT, but they share the concept of getting the right people together for a concentrated period of time and a very visual approach to project management.

Rather than a team spending three weeks on a very nice PowerPoint presentation and taking it to a steering committee, senior management comes down to the team and sees the raw materials.

When the proposition team is done, someone from that team will form part of the Agile IT team developing the system to support that proposition, so you get that cross-over. And sometimes you might need to feed back from the Agile IT team into the proposition team.

Can you give an example of this in action?

We used this to help the business develop an idea for a revenue stream around marine travel. Shipping companies often need to fly their crew out to join a ship, and this is a market with very particular requirements: the passengers start in various countries but need to come together as a group at a certain point; they want a one-way ticket; they tend to have a lot of baggage and they need an extensive route network, because they need to fly to many different places to meet their ships.

This is not something we had targeted heavily because a single one-way ticket with excess baggage with very short notice is quite expensive. But if you do corporate deals with the agencies flying the seamen, it’s a good market to be in.

We need to develop the whole business proposition from what corporate deals should be to what the required yield was and how we would sell it. You’ve got a lot of things to tie together in a proposition, and you need some very senior sign-off to get things done.

So we put a Revenue Lab together very quickly, flying people in from all over the world. We used an Agile-like process with a visual countdown board and daily stand-ups, and brought in senior management as ‘unblockers’. After three weeks, the proposition was done.

What would you say have been the overall benefits of introducing Agile?

The first thing I’d point to is the value that we’ve driven for the company, because that’s the reason why we’re in business.

And the second thing is the way it has motivated many of our people in IT. Some have said it has changed their lives.