What DevOps culture means to me – and how you can help it grow

When I tell people what “DevOps culture” means to me, they want to know how they can help it grow in their organization. The term “DevOps” has been around for almost 15 years now. It’s still a widely misunderstood and misused term. We still see software organizations that have a siloed “DevOps team”, a complete anti-pattern.

A little history

When agile development started to get traction in the Noughties, many large organizations created small, cross-functional teams that included programmers, testers, designers, product owners, and other specialists – but not operations specialists. These development teams continued to throw their release candidates over the wall to an operations team. The operations team took care of releasing the new changes, monitoring to watch for problems, and dealing with those problems when they occurred.

The term “DevOps” was coined by Patrick Dubois at the first DevOps Days in 2009. The idea was to break down that operations silo and get operations specialists working together with development specialists. The mantra is, “We build it, we run it”. The software delivery team takes care of the product throughout the whole development life cycle, including releasing, monitoring, getting up at 3:00 am to respond to a production issue. Operations specialists like platform engineers help build infrastructure as code, and, the whole delivery team uses and maintains that infrastructure.

In my experience, the cultural aspect is the most important, and for me, it reflects the original intention of “agile”. We build teams that have all the skills needed to succeed around the infinite software development life cycle. Everyone takes responsibility for all aspects of quality and testing, including those related to deployment pipelines, monitoring, and observability.

My experiences in a DevOps culture

At my last full-time job, I was lucky to be in an organization with what I think was an ideal DevOps culture. Yes, we had platform teams and feature teams. The platform teams did the initial building of infrastructure. Developers from feature teams were embedded on the platform teams to help them do a good job of coding that infrastructure. Platform engineers were embedded on feature teams to help them learn to use and maintain the infrastructure.

Platform and feature team collaboration

Here’s an example of how we collaborated. The organization decided to switch to a different platform for deployment pipelines. The platform team put the new platform in place. They created scripts and other infrastructure for each feature team to use to create their new deployment pipeline. Our team was the first to make the switch. I was asked to come up with a test strategy. I had regular 1:1s with one of the platform team managers, and I picked his brain about what risks we should watch for. Our embedded platform engineer and one of my developer teammates worked together to set up the new pipeline, test it, and test transitioning over to it from the old pipeline. We documented the new deployment process and made sure everyone on the team knew how to use, monitor and troubleshoot it. Everything went smoothly thanks to all this collaboration.

Another example: The organization felt a new monitoring and observability tool would work better than the one everyone was currently using. A member of the platform team set up a weekly session to help us learn the new tool. This helpful engineer made example dashboards and showed us how to instrument the code. He worked alongside us as we created our first dashboard for a new feature. With his assistance, we created a good process for designing and experimenting with the dashboard, then automating the process once we were happy with it. Our team took care of our application in production. We did the monitoring ourselves, and if unexpected problems occurred, we made sure we had all the data we needed to understand and fix the problem. The platform engineers were always available to help.

Collaboration goes both ways

When one of our senior developers rotated to the platform team, he helped them learn leading coding and testing practices. They found ways to improve the stability and maintainability of their infrastructure code. A DevOps culture is, to me, the same as what an agile culture was meant to be. We don’t work in silos, we don’t wait for another team to do something for us. We share our knowledge and help others learn the skills, and are there to support each other as needed.

What you can do to grow a DevOps culture

“This sounds like lovely unicorn land”, you say. “How could I possibly get our ops people to work this closely with us? How can we move towards this collaborative culture?” It’s definitely much easier to transform to a DevOps culture if your organization’s enlightened leaders lay the foundation. Managers and executives can help teams along the way. Yet, even without that kind of support, you can have an influence. Don’t underestimate your ability as a change agent. The secret is to find your allies.

Build bridges

Build relationships one by one. Find a friendly operations specialist – a platform engineer or a site reliability engineer, for example. Ask them to have a virtual or in-person coffee with you. If it goes well, why not set up a biweekly 1:1? When you talk with them, ask lots of questions. “What are you working on currently?” “I’d like to understand the path that our code changes take to production, would you please draw out the pipeline for me?” “What monitoring tools do you use? Can I get access to them? Do you know of any good tutorials, or can you sit with me for a few minutes and help me get started? (OK, don’t bombard them with all these questions at once!) A request for help is a great way to establish a working relationship.

When your team has an operations- or infrastructure-related need, be brave. Invite a friendly developer teammate to join you and your operations specialist friend to talk about it. Brainstorm ideas to get the feature team and the operations or platform or DevOps team working together to solve your problem. Change is hard, and there will always be people who don’t want to go along. Accept that, and collaborate with those willing to experiment.

Keep learning

Learn about DevOps culture – whether or not your organization labels itself as doing DevOps, the principles work in many contexts. We’re lucky to have many resources to help us learn more. You may find this post on “Testing in DevOps” helpful. I highly recommend Katrina Clokie’s book, A Practical Guide for Testing in DevOps, to learn more about DevOps. I especially value her ideas on building relationships to help you and your team succeed. The “Holistic Testing for Continuous Integration” course that Janet Gregory and I developed is another good way to learn. You can find many more helpful resources, to learn about DevOps culture and more, on this page right here on my website.

The post What DevOps culture means to me – and how you can help it grow appeared first on Agile Testing with Lisa Crispin.