Since the inception of DevOps, the cultural movement and its identity have been debated. But today, DevOps is no longer an “IT thing” or a technology practice. It is a strong organizational-wide transformation journey that intends to break the silence between people, processes, practices, and tools.
Within each transformational journey, many have found that the behaviors which lead to an organization’s culture, the co-creating processes which focus on flow and agility and the adoption of tools and practices, can be a catalyst for change. The behaviors and how we adopt them can lead to improving the intended outcomes in any transformational DevOps journey.
So where does it all start: Top-Down or Bottom-Up?
While leading a DevOps transformation, I have come to understand that more than anything DevOps is a change management initiative. The first step in any DevOps journey is to prepare for change and have stakeholders committed to the journey.
Next for a transformation to be effective, change initiatives must be aligned to business outcomes, primary business goals, and objectives. Technology and operational efficiency initiatives are enablers that will maximize business outcomes. It is important to provide empirical evidence and get support from top executives. Without buy-in from the top-level executives, it can just turn up into another IT project. If you’re having trouble explaining DevOps to others in your organization, check out How to explains DevOps in plain English.
Once you get the stakeholders on board, the job has only just begun. The next steps can be to assess the following:
- Are existing operations and development practices deep-rooted?
- Is the organization intimidated by the adoption of new processes?
- Is there a hierarchy of communication and collaboration?
- Is the organization ready for the change?
There are multiple variables in every DevOps journey, but the answers to each of these questions can vary with the scale, maturity, and culture of an organization. It is up to you and your company to decide how to start and scale a DevOps adoption. You need to get to know the DNA of your company. From there, you can empower the associated teams and build a plan based on shared goals and objectives.
DevOps is not something money can buy, yet it is an investment!
DevOps is an investment but it is not something you can buy off the shelf. The mindset shift is the backbone of this movement of change.
While leading a DevOps transformation, I’ve seen how difficult it can be to get certain programs accepted within an organization. I’ve found that one of the best ways to enforce change is to incentivize the members of an organization and reward the behaviors aligned with your objectives. From there, you can break the physical silos between various hierarchies as a way to facilitate collaboration and communication. This makes the feedback process less painful and encourages people to reach out. Full Enterprise Adoption: Ways of Working will give you an in-depth look into the key constraints between technology teams and business teams and provides feedback on how to combat these issues.
Next, you can start to rethink the processes within your organization. How is the flow of work both integrated and visualized? Rethink some of your most common issues, like how many backlogs do you have for each product line and are they talking to each other? Are there five different ticketing systems in the company? Is your project management organization acting like a guarded border? How much “inventory” of features you have? How many product features are overproduction, which no one intends to care for?
Lastly, think about the IT tools and practices within your organization. Although DevOps is not solely technology-oriented, it has important aspects for which technology can act as an enabler. One way technology can enable your DevOps transformation is by optimizing the way you support your flow through the consolidation of applications. You can make your infrastructure transparent and seamless. Your tools and process should support each other. Keep in mind that selecting a tool without knowing how it will be integrated and used, will only deepen the gap. As you’re putting together your DevOps adoption plan, check out How to Future-Proof DevOps Skills to ensure far-reaching success.
Most importantly, when embarking on a DevOps journey, keep in mind that practices are not written in stone. You can adopt practices from other organizations, but you don’t have to define your own DevOps practices through existing ones.
Your DevOps adoption is your own and you can build your own plan for your organization. With each DevOps journey, we will continue to expand our understanding of DevOps metrics, best practices and continuous learning. There is no master plan, only your own plan.