There’s lots of confusion about what DevOps is. This has resulted in the emergence of DevOps “antipatterns”—DevOps patterns of behavior that will not result in success. Having worked with many organizations to successfully implement DevOps principles and practices, there are often clear signs that what you are doing isn’t going to work. Let’s delve into some of them in hopes you can avoid these mistakes and effectively embrace DevOps.
Creating a DevOps Organization
DevOps is about tearing down the silos that exist between development and operations. The last thing you want your DevOps initiative to do is create a new silo. Doing so will just make it more difficult to get your business, design, development, testing, security, and operational personnel working together effectively.
I have seen organizations successfully build a DevOps pilot team responsible for working across the organization to educate everyone on DevOps principles and help the enterprise think through how to best improve its value streams. However, if this team’s goal isn’t to transfer DevOps knowledge to cross-functional teams that include release management and operational capabilities and ultimately empower DevOps over to these teams, you will struggle. Don’t let your DevOps pilot teams become an organization!
For organizations seeking to standardize on a set of automated tools to help streamline your delivery process, there is nothing wrong with having a shared services group responsible for building and maintaining tooling to supports DevOps, but expect to spend a significant amount of time understanding the delivery process of your teams. In larger organizations with multiple product lines, it is unlikely that a single continuous integration or delivery toolchain will support all delivery processes.
Focusing Solely on Speed
Many equate DevOps with continuous delivery, and while a key goal is to accelerate our ability to deliver code changes into production, that doesn’t mean the faster you deliver, the more you “are DevOps.” Often when speed is the sole focus of a DevOps initiative, quality suffers, as testing is deemed to be too expensive or slow to be useful during the delivery process.
Instead of focusing solely on delivery speed or turnaround time on defects found in production, focus also on shifting testing activities to the left so identified defects are fixed as early in the process as possible. By failing fast, your team can accelerate its delivery process while maintaining the quality standards your customers demand.
Shifting quality assurance earlier in the delivery process is greatly helped by making every development and testing environment you use as production-like as possible. The more similar to production your environments are, the more late lifecycle testing activities you can perform earlier in the process.
Forgetting to On-board Teams
Even if you have your development and operational personnel working together day to day as a team, don’t forget that your teams need support in order to successfully leverage the changes to their delivery process a value-stream analysis might recommend.
It is common when moving to a DevOps delivery model for some pretty radical changes to be made across the delivery process that impact how software developers, testers, release managers, and operational personnel do their jobs. For example, seeking to move toward a continuous delivery process in which all code changes are promoted into production will often dictate changes to how code is branched and merged during software development and check-in. If an appropriate branch/merge strategy is not followed, your teams are going to struggle to accelerate delivery.
Those responsible for enabling DevOps within your organization must take the time to teach, mentor, define processes, and set up enabling technologies for those who must wield new DevOps capabilities.
Focusing on Tooling instead of Systems Thinking
When moving to DevOps, the first thing many organizations do is slap together a set of tools to support continuous integration and continuous delivery activities. Effort is also often expended too early on automating environment instantiation and provisioning. While automating these items will often provide some DevOps benefits, automating a bad process isn’t going to fully solve your problems.
Instead, start by understanding your value streams in order to identify bottlenecks, constraints, and critical path risks before investing heavily in automation. Once you’ve identified where inefficiencies are, redesign your value stream to solve those issues. Only after you have an optimized process (or at least one iteration of one!) should you begin automation activities. These activities should focus first on accelerating processes that are rote, take the longest to perform, and are easily automated.
Thinking of DevOps as a Process
Much like agile, DevOps is a set of principles that guide the way we work. Unfortunately, many organizations focus on trying to “do DevOps” instead of becoming DevOps.
Beyond following the agile principles when shifting toward DevOps, consider the three DevOps principles defined in the seminal DevOps book The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford. They call these DevOps principles “the Three Ways” and define them as such:
- The First Way: Systems thinking—focus on optimizing the entire business value stream
- The Second Way: Amplify feedback loops—make feedback as quick and visible as possible
- The Third Way: Create a culture of continual experimentation and learning—allow for risk-taking and continually learn from your successes and failures
By focusing on the cultural aspects of DevOps first, your teams and organization will learn to “be DevOps” and resist the urge to focus primarily on process and tools.
This is a repost of a AgileConnection article.
