Many Australian and New Zealand companies have a keen interest in DevOps – some have very advanced DevOps cultures, while others are just beginning to see how it can be beneficial to their work.

DevOps combines collaboration and transparency to speed development, implementation and innovation throughout an organisation. Teams must share critical data in real time across the whole organisation for DevOps to drive business outcomes.

I’ve seen that many businesses that are just beginning their DevOps journey are looking for advice on how to get started, as well as the potential risks to that transition. At New Relic, we’re frequently asked about how we do things: how did we do our (Project) Upscale transition? How do we use our own technology to drive and support DevOps?

What we’ve found is that some of these businesses are headed down a path where they use the name “DevOps,” but they’re not really doing it. It’s not uncommon to hear “We’re the DevOps team, but we just do ops” – and we try to help companies get past this mentality.

There’s no point to having the buzzword if you don’t act on the buzzword. If your title is DevOps Engineer and you’re first line technical support, but you didn’t build the software, when something happens you’ll have to contact the development team anyway. The goal of DevOps is to integrate your team, so everyone owns it, and everyone is contactable.

Several ANZ-based organisations stand out to me as DevOps leaders, or at least significantly far ahead in their DevOps journey. Four such companies are Atlassian, Xero, ANZ Bank and NZME. These last two were more of a surprise for me, given that both come from a more traditional background. But all four companies have internal technical leaders who are driving transformation.

Having technical leaders inside the team allows the other team members to have someone they know, and can talk with, to understand what’s going to happen. Even if you start small, with DevOps in just one area of the business, that can eventually expand across the enterprise. One good example in the US is Capital One, which has evolved from one agile team to expanding DevOps across its entire operations.

Developing a DevOps culture is currently the best way to rapidly drive changes through your software systems. We see this at New Relic: the teams that have fully embraced the DevOps culture are the ones that rapidly deploy value to customers and improve their overall availability.

When I think about DevOps culture within organisations, it’s more about the why. No team’s goal should be to be “a DevOps team” – they instead should want to be a team that thinks about how to rapidly deploy value to their customers. What I’ve seen is that DevOps is the current best way of getting there. You could do a digital transformation in another way, but it would be slow and risky.

For organisations starting their DevOps journey, consider these five tips:

1. You need an executive sponsor

It’s important to have someone senior in your organisation who isn’t going to quit on you, and will give you the time and space to do the transition. It’s likely to be rough at times, and the team (and the sponsor) will need to persevere.

2. Hire coaches

At New Relic, we’ve had a lot of success by having coaches on board: external coaches that help the team through that initial period.

3. Build cross-functional teams

You have to build teams that are cross-functional, the mix dependent on how much hardware you own. You may be able to get by with fewer SREs (Site Reliability Engineers). But hardware can simply be needy: power supplies or hard drives can go bad, and you need the skills and experience within your team to fix that.

4. DevOps is a team sport

Everyone on the DevOps team needs to participate, only just SREs. Almost all of our teams include one SRE and often more (even the teams that are directly customer facing), and everyone on the team is on the pager rotation.

5. Hold regular retrospectives

Our teams have regular retrospectives at the end of each iteration or sprint to review the things that are working well versus those that aren’t. We then focus on doing more of the “good” things, and find ways to improve the others.

The main issue that Australia and New Zealand face compared with other parts of the world is that there are limited people with experience in the region. There are plenty of eager people wanting to do the work, and it’s all trainable. It’s a skill they can learn and develop. But the coaching is a different story, and for now, most businesses are going to have to find that expertise outside the region.

In DevOps, you need to give the team flexibility to fix the problem. Google defines a concept of “toil” – like a tax on the team. Toil  becomes an ever-growing burden if you don’t manage it. I encourage teams to create time to reduce their toil, because when they do this, they have more time to work on customer value. Every team tolerates a certain amount of toil because it isn’t worth the effort to eliminate and automate everything. But the lower the bar is for toil, the harder it is to have time to work on value.

Ron Crocker is a distinguished engineer and architect at New Relic. He holds more than 30 US patents and is focused on making people-oriented applications work well via innovative solutions.

This article was first published by TechWorld