The insights from this piece are from a talk given by Giulio Iannazzo, a Solution Engineer at Atlassian, at DEVOPS 2018 last month. Access the full presentation and video, and indeed all the presentations and videos from Europe's leading DevOps event, at your leisure.
DevOps is useful to companies for many reasons. If you're thinking of possible barriers to scaling your DevOps transformation, chances are you've realized that already. So let's get going on giving an overview of barriers and top-line solutions.
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 assembly 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.
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.