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.
User Comments
Overall a thoughtful article. I would challenge a few things though:
The author wrote, "[implementing the technology is] relatively straightforward to do". No, it's not. The technologies of DevOps are extremely brittle and complex; and it is very easy to go down a path that creates great pain later.
Every time I see an article saying that to adopt Agile or DevOps methods, one must first change "the culture", I groan. What is "the culture"? - that is so unspecific. Is it the musical tastes of the employees? The kinds of food they like? Seriously, saying the problem is "culture" is saying nothing.
The author's comments about silos and other challenges are spot on.
Some of the advice is platitudes that should be followed with care. E.g., "giving [teams] the freedom to decide how they build software". Well, to a point. If you take this to an extreme, then you have chaos. So what is the right level? What are some of the issues? Situations? How do you manage freedom while preventing chaos?
My favorite assertion in the article, which I completely agree with, is this: "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 …"
From what I see in the many companies that I visit, is that programmers today have a hard time focusing. They cannot think deeply. The result is that they are less effective at building complex things. We see the results of that in production defects, bad technology decisions, things taking longer than they should, and a lack of really great technical ideas.
The open team room, and messaging apps that interrupt you, are the bane of programming productivity. Programmers need private offices. They had that until the 1990s. We pay programmers a-lot of money and give them $1000 monitors, but then give them the office space of a low level clerk. It makes no sense. I have worked in private office settings, and if a team's offices are located in the same general area, the level of collaboration is very high - people "pop in" to talk. The idea that private offices stifle collaboration is a falsehood.
Thanks for the comment and kind words.
Implementing any technology can be hard, but I do think that most of the DevOps ideas, CI, artifacts, automated releases, are relatively easy to implement. Could your implementation cause issues later? It can, but that is also the issue with most decisions in technology. The implementation is relatively straightforward, especially compared with culture.
In terms of culture, I do agree that I was a bit general here. In fact, defining culture is difficult as it’s a fairly nebulous item. It’s the customs, social institutions and achievements in the dictionary. This is a piece that covers some of the ways you can influence those items. You can avoid silos, which prevent collaboration and shared goals. Managing incentives is very difficult, but the more they are individual, the more you have issues.
In the end, perhaps I should note that culture involves everyone on the team, treating the team as the priority, while treating the delivery of software to the customer as the main goal. What does that mean? It could be implemented in many ways, but it really involves finding a way to ensure your staff work together to build software, not separately and knocking off tasks.