The Role of the Business
In traditional software development environments, the business is kept, or chooses to keep, far away from the feature development process. The relationship with dev is transactional, where the business “throws a bunch of requirements over the wall to IT” and waits to see what comes out some months later. It’s the exact opposite in DevOps. The business is an essential central participant throughout the entire process, from idea to launch to enhancement.
Most business stakeholders love this idea and get excited about the opportunity to drive the process. But it comes with significant new responsibilities.
- Blameless Culture (No Blame Games): When problems occur in traditional processes, blame is usually the first thing to appear. The business blames dev for failing to deliver, while dev blames the business for omitting detail or lacking clarity. In DevOps, every member of the team shares in the success, and every member of the team shares when things don’t go as planned. DevOps recognizes that mistakes happen—the key is to identify them as early as possible and address them without delay.
- A Filled Seat: Having a seat at the table only works if someone is sitting in it! In DevOps, the business needs to be prepared to commit full-time resources—dedicated Product Owners—to gather and evaluate feedback from the user community, work with testers and developers to refine new features and improvements, and define specifications in the form of automated acceptance tests.
- A Full Pipeline of Value: DevOps means better features faster, driving business differentiation and value. The fast and efficient development pipeline needs to be fed continuously with new features and ideas. This is an area where there’s risk that the business itself can become a bottleneck. Early management of expectations and communication of the new responsibilities to the business are essential to realizing the potential of DevOps. Otherwise, the full potential of the well-oiled machine that is the new CD pipeline will go unrealized.
The Role of Culture
You don’t “do” DevOps with just a tool. DevOps is about people working together in a culture where collaboration is central to delivering value. It’s about breaking down barriers between groups. In DevOps, development and operations collaborate through a sense of shared responsibility. In traditional development models, individuals focus on their own small part of the process and care little what happens after they hand their piece off to the next stage and its team. But DevOps’ spirit of shared responsibility means that every member of the team stays involved with the solution over its entire lifetime.
Physical changes can facilitate cultural changes too. Co-locating cross- functional teams, from dev to ops and beyond, enhances their sense of shared responsibility. These are real people, not just some random team on another floor of the building or another city.
Dealing with Holdouts
It’s not uncommon to find critical individuals in an organization who resist the cultural and other changes that come with a DevOps transformation. They may be cynics who see DevOps as “just another trend” that management is foisting on them. Or they might be fearful of what the transformation means to them and their career. There’s a huge difference between “I am a developer” and “I am an ops person.” In many cases, an individual’s self- identity has been developed over years of professional life. That can’t be expected to change overnight just because of a proclamation that they’re now “doing DevOps.”
Once they’re identified, it’s important to offer holdouts lightweight, easy to implement, non-destructive/non-threatening approaches to align them with the efforts and—ultimately—provide value to the transformation. And it is important to share the results of the effort with them as it progresses. Everyone wants to deliver better software with speed and stability. There are few better ways to quiet the skeptics than with evidence that the entire team’s efforts are delivering that result.
- DevOps isn’t something achieved using a tool. It requires a cultural shift with buy-in from everyone involved.
- The role of the business is greatly increased in DevOps compared to traditional development approaches.
- Increased involvement means increased responsibility for the business.
- A DevOps transformation may not be welcomed by everyone at first. Understanding the holdouts and why they object helps to win them over.