Companies that embrace the DevOps movement and implement the proper processes, tools, and culture change can greatly increase business agility and achieve higher levels of performance. What does high performance look like?
- Deploy more often
- Fewer failures
- Recover faster from failure
- React quicker to business requests
- Deeper understanding of system metrics
- Reduced complexity
Unfortunately, there are many barriers that are preventing companies from achieving these characteristics. It is important for companies trying to embrace the DevOps movement to understand what these barriers are and put plans in place to mitigate these risks.
DevOps Barriers
Resistance to change
As with anything new, many people won’t change unless they have a reason to change. A favorite quote I like to use comes from Michael T. Kanazawa, an author who discusses organization change: “People don’t hate change, they hate the way you’re trying to change them.” People need to know why the change is necessary. To help them understand this, they must be presented with a few things:
- What problem are we trying to solve?
- What will the future state look like when we get there?
- What is in it for me (WIIFM)?
- How will we get there?
Before diving into action, take some time to answer these questions, and expect to have to continually repeat the answers over and over during the life of the transformation. In other words, evangelize.
Lack of buy-in
Buy-in is important at different levels of the organization. The number one reason for failure in any transformational initiative is almost always lack of buy-in at the leadership level. For some companies, that may be at the C-level, or it may be the business or product owner, the high-ranking IT manager, or even an architect. Every company has its own unique center of influence. If the most influential people have not bought in, they will drag down the others. Get these influential people on board and they will help evangelize, whether they do it intentionally or not. Identify who the key influencers are, and help them understand their WIIFM question.
Value not clearly understood
Words like DevOps, much like cloud, architecture, and agile, mean many things to many people. This often leads to confusion and an inconsistent understanding of the true meaning and value. If people think that DevOps is a person or a role, then they obviously don’t understand the value. Simply creating a DevOps team or, my favorite, hiring a DevOps engineer, does not solve any problems. DevOps is a way of building software. It is not a person, a team, or a thing. Hiring a person does not equate to achieving business agility. Changing processes, practices, and mindsets is part of what is needed here. If people don’t understand that the value of DevOps is to deliver better-quality software quicker, they may not be willing to undertake the transformation required to achieve those goals. Once again, a heavy dose of evangelism is required to get everyone on board. The value must be transparent at all levels of the organisation.
Old habits getting in the way
Even if you get past the barriers mentioned above and get people on board, DevOps requires major changes to the traditional ways of building and delivering software. Automation is a key to success with DevOps, but automating bad processes helps nobody. Teams should take a step back and reevaluate their existing practices before automating anything. The companies that are having success with DevOps are delivering software in very different ways than we have delivered it in the past. Here are a few examples:
- Continuous Integration: Everyone checks code into a trunk each day, and the code only makes it into the build if all tests are passed.
- Continuous Delivery: Consistent environments are delivered with the build. Requires deep collaboration with dev and ops.
- Loose Coupling: N-tier apps are out; highly distributed, horizontally scaled independent components are in.
- Feature Flags: Deploy from a single source and have the ability to turn features on and off. No more branching.
- Proactive Monitoring: Establish baseline metrics and detect anomalies before impacts are felt by end users; application monitoring.
- Automate Everything: No more manual processes. Eliminate all bottlenecks. If it is not scriptable, don’t do it.
I could add many more, but the point here is that traditional practices do not lead to agility. It takes a different type of systems thinking to achieve the promise of DevOps.
Silos
The DevOps movement evolved as systems administrators and developers tried to break down the silos between them and create a collaborative team environment. Yet, so many companies rush out and create a new silo organization called DevOps. If you look up “facepalm” in the dictionary, it should say “creating a silo as a solution to your silo problem.” Don’t create a DevOps silo. Create a DevOps culture.
Summary
For those leading the charge to create a DevOps culture within their organisation, it is critical that you recognize the barriers to this adoption and put a strategy in place to prevent these barriers from limiting your success. Figure out who the key influencers are, and get them on board. Always be evangelizing. Celebrate and advertise all wins and incremental success stories. Always have success metrics in your back pocket as proof points to make whenever the value is being questioned. Challenge the way you do things today, and don’t automate legacy practices. Most importantly, be patient and pragmatic. This movement won’t happen overnight. Make incremental progress towards the end goal, and show value in short increments instead of going off in the dark for six to eight months without showing the business any progress. There will be ups and downs along this journey, but never lose sight of the future state. When you get to the future state, all of the battle scars accumulated along the way will be well worth it.