Galovic has helped to manage a period of digital transformation at the Qantas-owned airline, which makes upwards of AUD$3bn in annual revenue.

I asked him about what was involved with the move to agile, how the teams are setup, the barriers to progress and the benefits to the business.

Read on to find out what Galovic had to say, or for more on digital and ecommerce in APAC read our interviews with Fonterra and MetLife…

What state was team in before move to agile?

Before moving to agile we primarily relied on outsourced development. It was all pretty waterfall.

So we’d go to a supplier or a partner and present them with a scope document, and they’d then estimate it, provide statements of work, and we’d deliver it in that fashion.

We decided to change this way of working about three and half years ago and began moving most of our systems toward agile.

So for our booking engine, which is our main application that we do a lot of custom development on, we decided we wanted to have a split model where the development team is a bit closer to the business and the delivery team.

And we’d kind of augment that with contractors or suppliers where we needed to.

So you hired more staff in-house?

Yeah, we in-housed about 50%-60% of that work, and where we do use outsourcing it’s through contractors who come in and work on those teams.

So they’re more like internal employees, they’re part of the teams.

It gives us scalability and augments the teams, but we still work in the way we want.

Where did the decision to change things come from? What gave you the impetus?

Part of it was around speed to market. We’d had small internal teams before and as we the business expanded we’d relied on outsourcing rather than expanding our internal teams.

We were finding that we were becoming a bit slower and the quality wasn’t as good.

It was a time-consuming process to come up with the requirements upfront and try to get estimates for that.

We often weren’t hitting our timelines or the estimates would be inaccurate.

We wanted to go back to what we had before with a small internal team, enabling the business to talk directly to the delivery teams without having to go through these large scoping exercises.

How long have you been with the company?

Around seven years. I started as a developer on one of those small teams.

Jetstar is only ten years old and has grown very quickly from a small domestic Australian airline to a global company.

The structure has shifted to a global services model, so we actually maintain the website and applications for all of these different businesses across APAC.

So all the airlines are different companies under the group umbrella, and we provide the services to them as our customers.

What different applications do you provide?

Digital channels, like the web CMS or our booking engine, which is basically our ecommerce platform for purchasing flights, checking-in, managing bookings etc.

Then there are our mobile platforms, like iPhone and Android apps, and the mobile website.

These are available across all markets, so that’s 20 different points of sale and nine or ten different languages.

Our CMS has different point-of-sale (POS) websites that can be customised per POS. we’re actually looking at consolidating that now.

It grew from the early days when the businesses were quite independent and managed their stuff independently, and over time we’ve consolidated things so the brand and the group is more consistent.

We’re changing the model to have consistent information architecture across the sites.

But there’ll be the ability to localise where we need to.

How do you manage content delivery? Do you work with local agencies?

In our primary markets we try to have local marketing teams and local content producers.

So that’s in Japan, Hong Kong, Singapore and Australia.

We found that having people internally who look after content and the website definitely helps in those markets.

Jetstar’s Japanese site

For our secondary markets like Thailand and Southeast Asia, which are important but aren’t our key markets, we tend to go with local translations.

Then as markets get to a certain size we might look to in-house more of it.

Going back to agile side of things, how is the team structured?

We have small teams of around four or five developers, a QA (quality assurance analyst), and a BA (business analyst)/scrum master or delivery lead.

All the teams are around that size and cross-functional, so they’ll have those roles and if we need larger teams then we just scale out that model.

So for our booking engine for example we’ll have four or five of those teams working on it, for others we might have one or two teams.

How long has the process taken?

It’s still on-going. Some areas are more agile than others.

So the booking engine is an area that we’ve put a lot of focus on, and mobile as well. Now we’re doing a fair bit of work to replicate a similar model on the CMS.

There were some constraints around the CMS that meant it’s not as easy to adopt technical practices around agile.

So it’s not as simple to achieve those frequent releases and testing might not be there as part of the framework.

So we’re actually rebuilding our CMS now and trying to adopt some of those practices.

What have been the main barriers to adopting agile working practices?

I think when we first started this process we were lucky that as a smaller company we didn’t have such strong processes in place.

If you’re an organisation that has a lot of old school PMO (project management office) type structures in place it can be more difficult.

For us we were coming from a less structured environment, so in the beginning we were almost adding more structure through the agile process. That was the first challenge.

     

Nowadays as we get larger and have more enterprise project management processes in place, it’s a challenge for them to understand the agile model in terms of funding and that kind of stuff.

You want to have fixed teams for long periods, set to systems or products, rather than thinking of everything as a project.

So ideally there are long-life teams structured around value streams and systems and those streams are funded for a longer period, like 12 months, no matter what projects they’re doing.

You need to understand that it’s all about the flow of work going through, not so much this portfolio of project management, and I think that’s one of the challenges that we’ve faced.

At the beginning of your move to agile, how tight was your transition roadmap?

We kind of treated it as a project, so there was a change management and stakeholder engagement issues to deal with.

At that time we were relatively small and had a few key decision makers that were already onboard.

I suppose we were lucky in that agile kind of fitted the Jetstar culture anyway. It’s a very dynamic place, people change their minds all the time.

There are a lot of different factors that go into delivering projects, e.g. contracting with suppliers and getting catering agreements in place and all that kind of stuff.

So to manage the overall end-to-end projects to a rigid schedule is very difficult anyway.

So our stakeholders like the fact that they’ve got a pipeline of work and if something’s not right they can fit something else in.

It’s not too hard to get that buy-in, and as digital is becoming more prominent and c-level execs are getting more interested in digital transformation as a technology, I think it’s been perceived pretty well that we already had a lot of this stuff in place.

What has been the impact on the business?

It’s definitely improved quality and consistency around our delivery. There’s a lot more clarity and our pipelines of work are very clear.

Our different system domains and teams have their pipelines stretching out over the year and it’s very clear based on the priorities of the business where different items are going to fall.

We’ve also benefited from making decisions around prioritisation and being able to deprioritise items and see what the impact will be on the flow if we spend more time on something else.

There’s definitely more consistency around project planning, so those pipelines, once you remove some of those variables in project management around resources, quality and cost, and scope is your only variable, it makes those portfolio and project management decisions a lot easier.

Where there any key lessons or takeaways that other people might learn from?

There are definitely a lot of technical practices that go along with this model.

So areas like continuous delivery and being able to release frequently require a reasonably large investment in automated testing.

The other thing is to make sure you take the organisation along with you.

So I’d recommend getting in a third-party in terms of an agile consultancy or coaches that can come in and look at the way things are being done now, then provide recommendations on how to change and talk through the process to actually make the changes stick.

We did that in the beginning and really helped to have a third-party come in. Even if you think you know what needs to be done it’s good to have a fresh pair of eyes.

In terms of staffing, do you find that local talent is available in APAC?

It’s challenging I think, but it’s the same everywhere.

Singapore’s a pretty small place, even compared to Australia, so there’s definitely a challenge getting talent here.

Locally it’s difficult to get Singaporean engineers. I think there’s been a history of engineering or development not being seen as a prestigious or desirable occupation in Singapore.

So a lot of engineers want to become project managers or BAs quite quickly, they don’t see long-term careers in engineering.

That’s starting to change and there are a lot more startups and tech companies in Singapore, but historically that’s been the view and it’s probably reduced the number of people coming through the system (i.e. universities).

On the flipside though, it’s relatively attractive for people from the Philippines or India or Southeast Asia to want to move to Singapore.

So you tend to get a lot of good candidates from overseas and it’s relatively easy to get them work permits to come here.

So although the local talent pool is small it has a bit of a gravitational pull for the rest of the region.