This is part 3 of my blog series, ‘You can’t buy DevOps but you may need to sell it’. Previously, we looked at some ways to get buy-in on driving DevOps changes. In this post, we will explore some of actions to take to spread change.

Actions to Spread Change

At this point, you’ve convinced people to start learning more about DevOps and maybe even driving some change. But how do you go from simply sharing your ideas to getting other involved? Here are a few ways.

Study Groups

There may be little or no money for formal training on the specific topic in your organization. But you can try to find other people who are interested in it. Form a small group of colleagues who also want to explore or continue to learn. Consider inviting outsiders. You can get somebody else is in front of your colleagues and talking about their DevOps practice. Sometimes, external validation can be more powerful.

This is different from “lunch and learns” mentioned previously in that it’s the group learning from each other more than you presenting ideas.

Internal Events

There are a lot of public events and conferences where you can go to learn about DevOps. I think these are great places to learn, but they aren’t going to be talking about the specifics of your organization.

Consider hosting internal events where you're free to talk about your challenges, because somebody else might have overcome them. I like structures with a combination of presentations and interactive sessions that you'll see in public events like DevOpsDays.

Mentor Teams

I normally rant against terms like “DevOps Team”. Most of the time this is another new silo or the rebranding of some other existing team.

“In a fit of rage caused by reading yet another email in which one of our customers proposed creating a ‘devops team’ so as to ‘implement’ devops, I tweeted that ‘THERE IS NO SUCH THING AS A DEVOPS TEAM.’” - Jez Humble

A team of mentors who will go out and embed with product teams however is perfectly valid.

You create a team of people who are further along with DevOps and Continuous Delivery. The individuals from that team spend the vast majority of their time embedded on product teams sharing their knowledge. Developers who have never learned about deployment are paired with people who can help them automate that as part of their normal work.

The team of mentors still gets together regularly to share their experiences. Once the product teams are up to speed, the mentor can rotate to the next one who needs help.

Pilot the Change

When choosing a project to use as a pilot, avoid the temptation to choose something “safe”. You don’t want to put your organization in jeopardy, but the project you choose needs to have enough impact that your success (or failure) can be a catalyst for ongoing organizational change.

Don't be discouraged

There is a scientific reason why we repeatedly make and break resolutions. Social science researchers have named this tendency “False Hope Syndrome”: because we believe self-change is easy, we set high expectation that aren’t realistic. In our context, set expectations but make sure they're reasonable expectations. Don't forget the small successes and don't get discouraged.

Summary

In these three posts, we went through some DevOps statistics and industry stories for you get buy-in, misconceptions and strategies to gain acceptance and patterns to drive and spread DevOps adoption. Having working in continuous delivery and DevOps space for several years, I truly understand that it’s really hard. I want to end this series with Robin Sharma’s quote:

All change is hard at first, messy in the middle and so gorgeous at the end. - Robin Sharma