Culture shifts such as DevOps take a lot of hard work, because you need every single person to buy into the new culture. The most successful adoptions we've seen of the DevOps mindset start with an organic, bottom-up approach.
Where to start with DevOps culture
Start with a concrete, immediate problem. For example, at many cloud software companies, engineers are paged when an error occurs. Since no one enjoys being paged, the engineers who are frequently paged are motivated to figure out ways to get a more restful night's sleep. At one organization we worked with, an engineer realized that pages (errors) correlated with new releases of the application. So she decided to introduce “canary deployments:” running a new version with a small percentage of real traffic side-by-side with the old version and gradually increasing traffic over time. Other developers in the organization saw the success of this approach and adopted it for their own services.
[ For more advice on culture, see our related article, DevOps requires dumping old IT leadership ideas. ]
At this company, a developer – in search of more sleep – introduced an operational best practice that an organization then adopted.
We’ve seen this pattern repeatedly. At its core, it comes down to recognizing two facts:
- For IT pros, the most credible recommendation for a better approach comes from their peers. Managers, vendors, and technical journals are all good sources of information, but a peer recommendation carries special weight.
- Developers are biased to adopting solutions that make their immediate lives easier.
Based on what we’ve observed in DevOps environments (including within our own company, Datawire), consider these steps to nurture a DevOps culture:
1. Start small and solve specific, concrete problems
2. Support the problem-solving engineers
It’s essential to let the engineer who is experiencing the problem personally try to solve it. If that engineer doesn’t have the know-how or skills to directly solve the problem, give him or her the right resources (other people, training, time) to tackle the problem. The engineer who is closest to the problem will be able to validate that the solution actually works.
3. Create forums to share successes
Internal DevOps Days, lunch-and-learns, regular engineering meetings, and blog posts are all good ways to share successes and create awareness.
4. Make time to help spread the solution
The engineer who built the canary system wouldn’t have been able to drive adoption if she hadn’t been given time to document her approach – and coach other teams through it.
5. Encourage engineers to engage outside your organization
Valuable outside interaction happens through conference talks, speaking engagements, or public engineering blogs (e.g., the Yelp engineering blog or the Lyft engineering blog). External validation and recognition of an engineer’s work helps with internal advocacy (wow, all these other engineers love this person’s work!). It also gives the engineer a different type of personal satisfaction.
Cultural shifts are not successful unless they’re internalized by the entire team. So, think carefully about how you nurture grassroots efforts when adopting DevOps in your organization.
Here is short course on Udemy that sheds some light on DevOps toolchain. https://www.udemy.com/devops-with-git-jenkins-artifactory-and-elk-stack/