The hard part of successful DevOps isn’t implementing the technology; in fact, that’s relatively straightforward to do. Essentially, the technology side is about automation, focusing on infrastructure as code, and creating (and enforcing) a pipeline process.
The difficult part is ensuring you have the right culture in your organization. You need to break down silos and align competing priorities and individual incentives to gain real benefits from DevOps.
First off, why should you move to DevOps? There’s clearly an increasing push behind it, coming from all levels of the organization, as well as major business thinkers. Economist James Bessen says that when software is core to business operations, it tilts the playing field in favor of those who use it most effectively. DevOps is one way to do this.
DevOps creates a more agile business that can respond more quickly to changing customer needs, helping ensure the company adds value and grows. At a developer level, we all want to work for cool companies like Spotify and Netflix that are built on DevOps and use technology as a business differentiator. And make no mistake, these companies know that encouraging a DevOps culture attracts talent that, in turn, helps them deliver more value to their business.
However, a major point about many of these cool companies is that, as digital-first businesses, they’ve grown up with DevOps. For those who work in established, more traditional organizations, there are three key challenges to face when implementing DevOps:
A need to overcome departmental silos: Silos inevitably create issues, like development not communicating with operations, projects competing for resources, and teams jealously guarding information. This leads to problems when updates are deployed, and a blame culture emerges
Clashing incentives: If your individual or team objectives (and bonus) are based on specific targets, it’s human nature that this is what you’ll focus on. That doesn’t normally fit with the more inclusive, open vision that DevOps requires. One team, for example, may want to focus on one feature, while another thinks a different feature is important and, in the end, both will be delayed
Competing priorities: Different roles have different priorities that can appear to be in opposition. For example, a database administrator or other member of an ops team is charged with keeping systems up and running and minimizing downtime. That means they’re going to be suspicious of faster development approaches that might lead to performance or dependency issues conflicting with their own goals and targets
Overcoming these challenges is about building the right type of DevOps team to suit your business and people. This will vary depending on your culture and on factors such as your product set (fewer products means fewer silos), the effectiveness of tech leadership, the appetite and ability to change, and your capacity and skills.
The excellent Team Topologies book and website gives some examples of the types of teams that can help you successfully introduce DevOps—and the antipatterns that undermine them. Of the nine examples they list, some of the most common models I’ve seen include:
Dev and Ops Collaboration: Think of this as a perfect Venn diagram, with dev and ops overlapping just so. While this is highly effective, embedding this model fully does require strong technical leadership and an open culture.
Fully Shared Ops Responsibilities: This is more of an eclipse, with little or no separation between dev and ops teams. This model tends to appear in digital-first businesses that have grown up around a single product and is difficult to sustain in more traditional organizations.
Dev and DBA Collaboration: This aims to bridge the gap between developers and database administrators (DBAs) by incorporating a database capability from the DBA team, complemented with a database capability (or specialism) from the dev team. This gives a more holistic view of the database and thus aids communication and DevOps flows.
In my experience, whichever model you choose, there are seven ways you can maximize your chances of DevOps success.
1. Allow autonomy
Empowering teams is one of the key tenets of DevOps. That means giving them the freedom to decide how they build software, rather than micromanaging them. Clearly this isn’t a recipe for anarchy; they still need to be held responsible and accountable, and to ensure their systems thinking and workflow matches that of other teams. It’s more about letting them agree among themselves how they’re going to work.
Will they be pair programming, for example, or using formal code reviews? Who are the best people to work on different elements of the project? If they’re using branching, how often will new code be committed to the shared repository? The answers to questions like these will give the team real ownership of the project, while at the same time improving the way they work.
2. Improve productivity
The biggest enemy of productivity is noise—not noise as in a loud working environment, but noise as in distractions like telephone calls, emails, meeting requests, meetings, questions from other teams, “urgent” messages on channels like Slack … you get the picture. All the stuff a normal working day throws at you.
The problem is that while this noise might appear to improve communication, it can also drive down the quality of code. Every interruption and unexpected diversion introduces stumbling blocks to the flow of coding, which can result in errors.
Solutions are to minimize meetings (and the length of meetings), introduce “no-interruptions time” on calendars so team members can focus on only the work, and have one person on the team each day handling any questions or problems that come up.
3. Require transparency
Information sharing and transparency is vital to breaking down silos and encouraging collaboration. Every team member should have access to source code, for example, so they can see what’s been done before, and the backlog, so they know what to prioritize next. Similarly, metrics should be shared, as well as information about incidents and lessons learned. This openness around code, knowledge, data, and best practices will bring walls down and contribute to real teamwork.
4. Encourage diversity
DevOps brings together people with different skill sets, and it only delivers results when you embrace this diversity. The alternative, often called groupthink, is a natural result of people congregating around others with the same mindset, but it can lead to teams either heading in the wrong direction or going nowhere because no one wants to upset the applecart.
Teams made up of people with diverse skills, styles, and ways of thinking lead to higher productivity because strengths in one area are balanced with strengths in others. This is particularly important with the rise of full-stack developers and the need for everyone to have a variety of skills.
5. Learn from failures
In the slow-moving, silo-based model of working, people are often afraid to shout out when they make a mistake or to share any lessons they’ve learned because it might hurt their careers. This is the antithesis of DevOps and is the perfect way to discourage innovation and prevent the kind of creativity that results in great code.
Instead, DevOps calls for recognizing mistakes and seeing them as an opportunity for everyone to learn, rather than an issue to be blamed for. A good approach is to embrace blameless root-cause analysis techniques and to enable constant improvements.
6. Recognize your peers
Everyone likes and responds well to justified praise, so make sure that the whole team recognizes and celebrates achievements. And this isn’t just about the consistent top performers; everyone in the team has a different level of experience and skill, so praise their major accomplishments equally.
7. Have fun!
You can’t expect to build a team by just bringing together a group of people from diverse backgrounds. You need to encourage a team ethos through bonding sessions that enable your people to get to know their colleagues as individuals in a less formal, more social environment. That will help team dynamics and underpin openness and understanding.
Changing your culture and breaking down silos is at the heart of successfully adopting DevOps. Move beyond thinking about technology alone and look at the people side of the equation. Then you’ll be able to create a successful team that delivers the benefits of DevOps, whatever type of organization you are.