A DevOps adoption strategy should be an operational overhaul
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source – techtarget.com
When people struggle to bring their teams on the path to true DevOps adoption, the misalignment is usually obvious. I recently spoke to a developer who lamented that his DevOps team didn’t cooperate with the development team. I was dismayed their DevOps adoption strategy was reduced to simply coming up with a new team name instead of undertaking an actual operational overhaul.
DevOps, like Agile and other trends before it, suffers from an identity problem. A great deal of time and energy goes into debating what DevOps is instead of what DevOps does.
Often, teams in this situation have fallen for the age-old problem that plagues so much of software development; they’ve cherry-picked the fun stuff and focused too much on the tools. This problem, in part, appears to stem from a semantic misunderstanding. Some teams pick up better ops practices, such as configuration management. And then, they give those folks a DevOps engineer title — heck, it does sound a lot cooler than sys admin — and tweak the incident-management process to involve developers. Then they call it a day.
While this is a great leap forward compared to the Wild West of operations of old, these practices alone are a small part of the broader mindset that a DevOps adoption strategy should evangelize. Beyond bringing a developer mindset to the ops team with new techniques and better automation, it’s important to consider entirely new ways of working, collaboration models and even expansion into the business side.
So what do you do if you find yourself in this situation? How do you come up with a DevOps adoption strategy?
While tools can help work flow through parts of a system, they can only go so far without collaboration among all the people involved in software delivery — from idea to production and back again. The only way this can happen is through an explicit agreement, understanding and corresponding behaviors. You need organizational awareness and thoughtful leadership to ensure that this becomes the path of least resistance.
Switch: How to Change Things When Change Is Hard, by Chip and Dan Heath, is a fantastic mental model. In the book, the challenge of effecting change is broken into three components — direction, motivation and ease. If you understand which of these components is in play — and sometimes they all are — you can identify ways to change behavior. Let’s apply it to our DevOps adoption strategy.
Direct the change
To get teams on the right path, share examples of high-performing teams. If you don’t already have such teams within your organization, the talks from DevOps Enterprise Summit conferences should provide inspiration. These events feature passionate people from progressive enterprises across multiple industries sharing their real-life stories of DevOps transformation.
Another approach is to work with teams to assess where they’re at, paint a picture of where they want to be and then establish a program of incremental improvement. A roadmap for DevOps success clarifies the steps and guides them on their journey without becoming overwhelmed or unproductive by adjusting too quickly.
Motivate your team and build habits
Sometimes teams or individuals lack a compelling reason to work differently. In these situations, people need to recognize the need for change and see it as a desirable goal. While there’s a good deal of material out there that speaks to the reasons to adopt a DevOps mindset, it’s vital that motivational appeals match the desires of the team. While some tech professionals might care about competitive advantage and business outcomes, you’re more likely to gain support if you appeal to a sense of progress, remove regrettable or unplanned work and offer the promise of career advancement.
Identify pain points
Even with the right motivation and direction, your DevOps adoption strategy can still run up against resistance. These obstacles can come from a range of places:
- Business constraints. Arcane compliance rules come into play here. Engineering and risk teams have their hearts in the right place. When they come together and understand each other’s needs at a deeper level, it’s often possible to make compromises. Look for new ways to comply with regulations by understanding the underlying requirement and apply workflow changes that still allow teams to move fast. The best teams bring their security and risk stakeholders along for the ride.
- Organizational misalignment. It’s trouble when teams in your organization have conflicting goals. The best place to start is to get the affected stakeholders talking. The best organizations prioritize finding ways to organize themselves around the needs of each team — driven by business goals, as always.
- Architectural flaws. These prevent agility. For instance, some frameworks don’t lend themselves to automated testing. And brittle infrastructure that is managed with a manual change process will slow you down as well. For most, it’s a long and difficult process to address architectural limitations. It’s important that the broader team understands the need to dedicate the time to keep sustainable engineering health, allow time for it and consider it in their planning at every level.
- Poorly supported or configured tooling. Different roles may have different lenses into the overall system, but it’s important that everyone work with one integrated toolchain with a defined flow of work. It should be visible, efficient and tuned through experimentation. As with other points of friction, there is a balance to strike. You have to balance consistency and stability with flexibility so teams can work in different ways. When it’s time to scale across multiple teams, establish a foundational, flexible tooling layer.
If you find yourself in a situation where your organization has missed the mark when it comes to DevOps adoption, it’s worth taking the time to understand why. Provide clarity if there’s a misunderstanding. Appeal to desire if there’s a lack of motivation. And seek to remove obstacles if folks think it’s just too darn hard. With this mindset, it is far more likely that you’ll achieve the necessary convergence of behavior, culture and technical excellence.