How To Implement DevOps Without Missing The Point Entirely

In this third and final article, Andrew Stickland looks at some of the ways DevOps can and should be implemented.


DevOps, like agile methodology, is a complex cultural and philosophical goal, the results and implementation of which will vary significantly across different organisations – and even within organisations.

Both agile and DevOps have guiding principles, but neither is a definitive end goal in its own right. Your organisation needs to understand the core principles of DevOps and to determine what they mean for your organisation. What will be the end goal by which you will measure success?

I’ve heard it expressed that DevOps is an unachievable goal, as there is no end point. This is something I partially subscribe to because, like agile, it’s a mindset targeted at continuous and endless improvement.

Better DevOps, Part 1: How To Identify The Problem Of DevOps Cargo Cults

Better DevOps, Part 2: The Biggest DevOps Mistakes That Businesses Make

Principles Of DevOps


So what are the principles of DevOps?

Well, firstly, we have Flow, where we want to accelerate and optimise the delivery of work from development into operations and therefore on to the customer or end user.

Secondly, we have Feedback, where we want to create safer ways of working so we don’t pass poor quality of work down the chain and so, where problems do occur, we recover quickly. The third and most important principle is that of Continuous Learning and Experimentation. This is where we want to create a high-trust and blame-free culture, where experimentation and risk taking are encouraged but backed by scientific method.

And to achieve a high-trust and blame-free culture, we have to get our teams to accept shared ownership of the problem. It’s not Bob’s fault that the last thing we tried didn’t work, because everyone was in on the idea from the beginning.

What we’re seeing a lot of in the industry is a focus on Flow, followed some way behind by Feedback, and then Continuous Learning and Experimentation coming in a lowly third.

Flowing The Wrong Way

The focus on Flow is evident in the DevOps jobs that we all see being posted on job boards. What does a title like ‘DevOps engineer’ actually mean? It seems to be a continuation of the theory that if we automate or put someone in charge of operational automation, then we’ve solved the problem and achieved DevOps. We’ve ticked the Flow box so we’re done.

I believe it’s a bit cloudier than that. When you consider that DevOps is about getting the disconnected teams and working practices to come together, tackling the automation issue is not key.

One of the problems here is that people tend to look at DevOps as a huge challenge – and it definitely is. As a result, they try to bite off ‘chunk 1’ – in other words Flow – and leave the rest to later.

Unfortunately, the third principle is at least as important as the others. The third principle, the joining of forces across the teams, the shared ownership, will significantly inform how you undertake Flow and Feedback changes.

Shared Ownership

Let’s dive a bit deeper into the issue of shared ownership. Looking at the philosophy and culture of DevOps properly, you’ll find that the fundamental message is about how everybody works together.

There are some fundamental things to be taken from the DevOps messaging:

  • Shared ownership of the problem
  • Common understanding of shared accountability
  • Single source of truth shared by all
  • Everyone together

Note that I haven’t included automation in that list at all. The truth is you can automate all you want from testing to deployment, but without the ‘shared’ elements where everyone come together, you won’t achieve anything like your full potential.

Developers have to start thinking not only about how the end user might click buttons and enter and view data. More importantly, they have to start thinking about how the user will access the application and how they’ll operate and use it on a day-by-day basis.

Operations, on the other hand, needs to think about how software works and why. And, most importantly, they need to think about how the tools in their armoury would help the development teams.

Doing DevOps Right

Now we’ve identified what DevOps should look like and what it most certainly shouldn’t, let’s round things off with a few essential tips:

1. Don’t be a cargo cultist

You can’t create a DevOps label, subscribe to a few simple bits and pieces such as automation and have any realistic expectation of it making any significant difference to your business.

2. Don’t create new silos – break down barriers

There is no such things as a DevOps team – unless you get rid of your development and operations teams. This is about bringing people together and building a culture of shared responsibility.

3. Do foster a common understanding

Everyone from the top to the bottom of an organisation needs to know what DevOps really means. If you’re not singing from the same hymn sheet, you’re not going to succeed.

4. Do define your target to DevOps

Ask yourself how you’ll know when you achieved DevOps. What does it actually mean for your organisation? How will you embed the three principles within the organisation?

Atlasssian expert resources

Visit our blog for expert news and articles from the Atlassian world. On our resources page you will find recorded webinars, white papers, podcasts, videos and more.

The Software Blog

Read our blog for articles offering best practice advice written by Atlassian experts, as well as the latest news concerning your software.

Software White Papers and Guides

Dive deep into Atlassian software with our white papers and guides on individual tools, partner products, services, and best practices, written by the experts.

Expert Webinars

All of our webinars are pre-recorded and available to watch on-demand. Enjoy everything from partner features to application demos and updates from Atlassian experts.

Subscribe to our Newsletter

Subscribe to our Newsletter