A thriving DevOps culture should mean a thriving IT team, one that plays a critical role in achieving the company’s goals. But leave certain needs and warning signs unchecked and your DevOps initiative might just grind your team into the ground.
There are things that IT leaders can do to foster a healthy, sustainable DevOps culture. There are also some things you should not do, and they’re are just as important as the “do’s.” As in: By not doing these things, you will not “kill” your DevOps team.
[ Are you a DevOps job seeker or a hiring manager? Get our free resource: The Ultimate DevOps Hiring Guide. ]
With that in mind, we sought out some expert advice on the “do’s” and “don’ts” that DevOps success tends to hinge upon. Ignore them at your team’s – and consequently your own – peril.
Do: Remove friction anywhere it exists
One of the goals of the early days of DevOps, one that continues today, was to remove the traditional silos that long existed in IT shops. The name itself reflects this: Development and operations are no longer separate wholly separate entities, but can now function as a closely aligned team.
That’s a fundamental example of removing friction – in this case, between people and teams. But it doesn’t stop there, nor is eliminating friction a given just because you bring a bunch of people together under the moniker of DevOps (or DevSecOps).
Nate Berent-Spillson, senior delivery director at Nexient, says IT leaders must strive for frictionless workflows as much as possible to ensure the health of their DevOps teams. If something is unnecessarily slowing the team down or causing headaches, or simply isn’t serving a meaningful purpose, get rid of it.
“Ruthlessly prune useless activities,” Berent-Spillson recommends. “Get rid of policies that don't add value. Eliminate bottlenecks, especially handoffs across time zones.”
Do not: Retreat from failure
DevOps and the blame game don’t mix. You can’t tell your team to “fail fast” or some similar mantra about embracing failure and then punish people when they do just that. It’s a common killer of DevOps initiatives and teams.
“DevOps creates a path for us to improve, and organizations need to use those failures as indicators of areas that will provide the most business value in fixing,” says Robert Reeves, CTO and co-founder at Datical. “Instead of asking who is to blame, I would ask, ‘What are the next areas to improve using DevOps?’”
Declaring “we’re a DevOps shop!” while maintaining a failure-averse philosophy is a fence-sitting strategy – more on that kind of hedge position below – and people will see right through it.
Ed Price, director of compliance at Devbridge Group, sees this manifest in what he calls “AgileFall” shops: That is, organizations that say they’re embracing DevOps culture and Agile methodologies, but very quickly roll back to manual processes or waterfall development when they hit a rough patch. When your DevOps team is once again hamstrung by arbitrary deadlines or approval processes to get into production, for example, you’re gone astray.
“The biggest mistakes organizations make is to resort back to manual and waterfall deployment models because they think DevOps isn’t working,” Price explains. “The 'fail fast' mentality means you will have some bumps along the way and the leadership needs to ride out the wave.”
Do: Measure your efforts
One of the most glaring warning signs of imminent DevOps failure? When there are no warning signs, according to Reeves.
“The reason you have a DevOps initiative is to increase the speed and decrease errors of application deployments,” Reeves says. “But, if you aren’t measuring those, you can’t tell if you are improving, treading water, or backsliding.”
Reeves recommends measuring the following as musts:
- Mean time to recovery (MTTR)
- First-time success rate of deployments to production
- Number of production deployments
- Lead time (amount of time from code check-in to production deployment)
Metrics will vary by organization, but these may be a good foundation or baseline that you can measure against over time. When the numbers move in the wrong direction relative to your baseline and goals, something’s amiss.
Red Hat technology evangelist Gordon Haff stresses that DevOps metrics should reflect what’s important to the success of your organization - say in terms of customer experience and operational efficiency.
“If it’s customer experience, a metric such as Net Promoter Score might be appropriate. If it’s efficiency, more cost-centric measurements will be the better match,” he notes.
DevOps metrics should be tied to business outcomes in some manner, he says. There are plenty of technical metrics you could track, but what you really care about is “the degree such metrics can be correlated with customers abandoning shopping carts or leaving for a competitor,” notes Haff.
[ See the full story by Haff: DevOps metrics: Are you measuring what matters? ]
Do not: Ignore the warning signs of burnout
Burnout in the IT profession is real. A healthy DevOps culture should minimize burnout, but that’s not promised to anyone, especially if “DevOps” is a red herring for “making people work 24-7.” Burnout is something to watch out for even in less dramatic scenarios, especially as people get used to new ways of doing things.
“Burnout is one of the biggest, if not the biggest, risks in IT,” says, Dary Merckens CTO of Gunner Technology. “Tech people by nature are the kind of folks who will push themselves as hard as they can to complete something.”
[ Read our related story: 8 ways to fight burnout on IT teams. ]
Couple that with the driving forces behind DevOps – delivering products and services faster, more frequently, and with fewer errors – and you could be turning the heat up on a boiling kettle. You need to keep tabs on morale or risk significant negative consequences.
There are plenty of ways to do so, including simply becoming a better listener. But Merckens offers another metric you can track.
“You can get a pretty good sense of the mental energy of your team by looking at bug frequency,” Merckens says. “If you start seeing lots of bugs being deployed, you need to be wary of your team running out of steam.”
When you do see the symptoms, work to address them (and their underlying causes) head-on.
At Merckens’ firm, they’ll perhaps take an afternoon off to do something non-work-related as a team – “the new Solo movie being the perfect example of some fun, nerdy thing we can all do,” for example, he says. Or, give the team an extra day off after a particularly grueling stretch. Regardless, do something.
“There are lots of things you can do to prevent or remedy burnout, but the one thing you don't want to do is ignore it,” Merckens says.
