I've been transitioning teams to DevOps culture for the past four years. During this time, I've seen many misguided decisions, such as teams choosing a new tool, changing a process, or fitting people in a framework without clear goals.

Other times, teams select a tool, users slowly adopt it, the company decommissions the old method, and people keep learning as they go. Other people conflate DevOps with using Kanban boards, putting the infrastructure in version control, and implementing continuous integration.

But a solid DevOps transformation depends on people's ability to communicate effectively and share work efficiently. With that in mind, here's a set of recommendations to truly implement DevOps in your team.

Learn the Concepts

Everyone learns by different methods, so I'll offer several alternatives. Starting with books, here are my essentials:

• The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win is presented as an easy-to-digest narrative, so you can easily picture yourself in the story. 
• The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations focuses more on people skills and less on technical aspects. It presents useful case studies to illustrate DevOps practices.

If you're more of a podcast person, here are a couple of recommendations:

• ArrestedDevOps features guests who currently work at companies like Etsy, GitHub, and eBay. Don't feel overwhelmed by the extensive episode list; try starting with the early ones and listen or skip as you see fit.
• DevOps Cafe has been around for eight years. Each episode includes show notes, so you can choose which episodes you need to listen to.

For the video crowd, I suggest Microsoft's "DevOps at Scale: A True Story." In exactly an hour, two seasoned leaders from Microsoft share their experiences migrating Visual Studio developer teams from traditional waterfall development to modern DevOps practices.

Share these resources with other people in your organization—talk about them openly, discuss things that would be easy to achieve, and get different opinions. Each audience will have a different perspective depending on their role.

Other organizations may formally train their staff for DevOps transformation so they can get a grasp on the basic concepts and take it from there. It's fundamental that people understand that DevOps practices do not have a one-size-fits-all approach.

Get Leadership on Board

Once you have solid concepts, it's time to talk to leaders so they can help you promote DevOps culture. Expose opportunities to reduce rework, propose a greenfield project as a laboratory to learn, and practice new methods.

Focus on using language appropriate for each audience, and highlight successful experiences at other companies. You could quote relevant statistical data from studies like Accelerate: State of DevOps by DORA. Also, catch your manager's attention by talking about quantifiable benefits.

Set Goals, Then Let People Define How to Achieve Them

Every organization has room for improvement in different fields. Here's a set of popular goals:

• Minimize manual steps in your deployments until there are zero
• Consolidate configuration so you have a unique source of truth
• Shift application security to the left of your development process
• Standardize application provisioning across teams and environments
• Replace your integration environment by using automated code testing

Choosing one of these goals is enough to get people's interest during a first approach.

Empowering teams to decide how to achieve their tasks is primary. Avoid micromanagement; it's demoralizing. Leaders are there to remove roadblocks and remind teams that value to customers is a high priority.

Improve Cross-Functional Collaboration

According to Conway's law, any system will replicate the social boundaries of the organization that produced it. You can avoid this pattern by empowering people to work outside their functional teams. As a result, you'll increase diversity, which leads to smarter teams.

Companies with global teams have additional challenges, such as multiple time zones and lack of face-to-face rapport. This kind of team may benefit from rewarding transparency and offering a safe means to report inconveniences.

Cross-functional teams can also help you avoid the curse of knowledge in your outcomes. People with different skill sets will create better products with fewer assumptions and biases.

Work and Deliver in Small Batches

Consider realigning your schedule and expectations by setting incremental goals. If your team is implementing Scrum, you're probably already used to doing sprints, which usually last a couple of weeks. Be sure to take time to reflect after each sprint, and ask yourself these questions:

• Does your team have a product at the end of each sprint?
  • If yes, how long before it reaches production?
  • If no, what could be improved (by devs or ops) so they have one every time?
• Was there an issue estimating the scope of work?
• Are there contentions from operators keeping devs from delivering faster?
• Are deployments causing incidents that take time away from development?

Also, there should be a clear agreement between developers and operators on the definition of "done." Here's a sample definition: "Software isn't done until it's been delivered. Delivered means it's been released to production and proved reliable by monitoring."

Encourage People to Talk About It

Get the conversation going, and provide time and space for people to ask questions. Any change will bring uncertainties. Certainly, some people might be positively motivated, but others probably will feel threatened with being made redundant.

You can also share articles to read, talk about it outside meetings, and buy books and make them available for anyone to read at the office. Transitioning to DevOps culture is more like a marathon than a 400-meter dash. It requires continuous attention to the people involved, process changes, and outcomes.

Measure Your Team's Performance

To perceive progress, lead your cross-functional teams to propose metrics that can provide evidence of performance change. Then you can use these metrics to build a baseline. It will probably show low performance. The purpose is to have relevant data that validates whether your actions are improving your outcomes.

Define evaluation periods and compare data. Correlate performance changes with directly related metrics. As a result, you can make decisions either to push forward or change strategies. Iterate this process in every evaluation period.

Get Feedback From Teams and Customers

Criticism from your teams is highly important. You could consider using one-on-one meetings as an opportunity to get honest feedback because people feel more confident expressing criticism privately.

When it comes to external customers, try approaching the respective departments that handle such relationships and ask them for data that you can put in perspective with your own metrics.

Implement, Measure, Learn and Iterate

Every organization and team is different, but I hope this set of recommendations will be useful for your particular case. It's a collection of thoughts and conclusions I've gathered on the rocky road to DevOps. Remember that even if it's a long process, it leads to rewards when properly implemented.

This blog is brought to you in partnership with ASPE.