5 best practices for scaling DevOps

The insights from this piece are from a talk given by Giulio Iannazzo, a Solution Engineer at Atlassian, at DEVOPS 2018. Access the full presentation and video, and indeed all the presentations and videos from Europe's leading DevOps event, at your leisure.

If you're thinking of possible barriers to scaling your DevOps and digital transformation, here are some best practices to get you going. 

Challenge 1: DevOps is a vague term with differing interpretations

It may be that some people in your organization think DevOps is only about automating repetitive processes. But there's more to it than that.

Best practice 1: Organize workshops which demonstrate DevOps techniques in practice

This approach gives your teams the theory and the benefits all in one go.

You need to communicate that DevOps is not a tool or quick restructure, it's an attitude and a philosophy! To do this successfully, you need to let people witness DevOps in practice so that it becomes part of their everyday way of working. DevOps is a culture of constant experimentation and improvement, one that catches failures quicker than before thanks to a no-blame culture. More job satisfaction for engineers should follow.

Challenge 2: DevOps shouldn't become just one team’s responsibility

As DevOps represents a cultural change, the end goal is for its methods of constant improvement to be integrated into everyone's way of working (including the C-suite). By assigning a group of people to 'do DevOps' permanently, you run the risk of others thinking it's not their responsibility.

Best practice 2: Change up team structures and don't create a DevOps silo

Change up team structure so that you have various specialists in teams, including Ops. Plan for your DevOps transformation to have an expiration date.

Challenge 3: Different tools used by different teams across the organization

Collaboration is a lot more difficult when teams aren't using the same tools for similar tasks.

Best practice 3: A uniform software production line

Make your software assembly line uniform across the organization and enlist expert help to make the right choices when it comes to tooling. Prove the benefits of new tools by letting teams experience them first hand.

Challenge 4: Change is difficult

An “If it’s not broken, don’t fix it” attitude runs counter to changing things for the better. New processes take time to master. What's more, the cultural silos may have existed for ages at your company.

Best practice 4: Show, don’t tell

This one's linked to solution no. 1. Show teams how DevOps will lead to them becoming more successful. Share specific examples across the company where DevOps is working and driving benefits: on the intranet, by email, or a lunch and learn. Running a DevOps pilot in one of your teams is a way of getting that valuable first example.

Challenge 5: DevOps transformation is a massive project: where do you start?

There’s no way around it: DevOps transformations can be unwieldy to handle.

Best practice 5: Get expert help in the beginning and recognize it's a journey

To prevent DevOps transformation from happening in fits and starts and overwhelming your department, start with low hanging fruit like uniform tooling, and get expert advice at the beginning of the process in the form of a DevOps assessment and roadmap. Assessments lead to transformation roadmaps with weighted prioritizations which pave the way for the change you want to see.

DevOps is a culture of constant improvement and experimentation, which makes your Devops transformation a journey that continues far into your company's future. Then again, that doesn't mean your DevOps transformation should last forever, and there is an 'end point' at which DevOps becomes business as usual.

One brilliant tip for the road: the pre-mortem

You've heard of a post-mortem for projects. A pre-mortem takes that to the next level by anticipating issues that may arise before work on the project has even begun.

Run this exercise before beginning any work on the project. First, split your team into two groups. Then pretend that the world has fast-forwarded to one month after the completion of your project. One group discusses a reality where the project was a resounding success. Have them talk amongst themselves and list the reasons why it was a success. The second team represents a future where the project was a complete failure. Have them discuss the reasons why it was a failure and list them. Next, discuss both scenarios as a team.

The exercise allows you to anticipate what problems may arise, so your project stands a greater chance of being a resounding success.

Reading material

Atlassian's Giulio Iannazzo recommended the following book in his talk, as it sheds further light on the topic. Happy reading!

Forsgren Ph.D., Nicole. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Kindle Locations 781-785). IT Revolution Press. Kindle Edition.

Access Giulio Iannazzo’s presentation and video here.