DevOps: enough knowledge to be dangerous

DevOps grew from a desire to knock down the silos between development and operations teams, making it easier to deliver increasingly more complicated software on a more reliable basis. Project management tastemakers are starting to see potential to apply DevOps principles to a much broader range of activities. That doesn’t mean you need to rush out and hire a team of consultants, but it would be handy to load up on just enough DevOps knowledge to be dangerous.

Like any hot trend, that’s easier said than done.

“It’s hard to get an understanding of it from researching online,” says Paul Witt, DevOps engineer at Fanatics. “You find a bunch of companies who talk about ‘DevOps’ as a buzzword, pat themselves on the back for doing it, but don’t explain what they’re doing.”

Witt became a “DevOps engineer” via immersion 18 months ago when a new leader came in and implemented his spin on the discipline at Fanatics, but his experience wouldn’t be replicated everywhere. “If you polled 100 organizations on their experiences implementing a DevOps strategy within their existing business processes, you’d likely get 100 different answers,” says Vincent Geffray, senior director of product marketing at Everbridge.

Much of the difference stems from the unique historical and political challenges each organization faces in bringing together their fractured development and operations personnel. Those issues cloud the greater potential for DevOps to inspire improvements in broader project management. Here’s how you can look past the internecine clutter and wrap your head around the DevOps message.

 

DevOps prioritizes automation and self-service

One of the DevOps hallmarks is to automate as many manual processes as possible. In the context of DevOps software projects, that means a heavy emphasis on automated testing. This frees up a lot of resources and budget that otherwise would have been spent manually testing a build, and ensures that the testing actually happens to specification.

Project managers can heed that example by being aggressive about automating the check-ups and check-ins that fill too many of their days. DevOps also emphasizes self-organizing teams which come together to meet challenges and fulfill requirements, which saves a PM from having to manually break down a task and beg, borrow, or steal the resources to meet the milestone.

Note that most of the time, somebody will bristle at this push, because of a misguided belief that tedious manual tasks justify their jobs. “There are often politics in the way, and a lack of budget around automation,” Witt says. “A lot of infrastructure people can feel threatened, as though they are going to lose their positions, but the reality is that you still need them on the team.”

 

DevOps emphasizes continuous delivery

DevOps strongly emphasizes continuous delivery. Continuous delivery sounds great until it runs aground on the shoals of your conventional deadline-based system. Everybody has their own continuum between rigidly pre-planned milestones three years in advance with no wiggle room, and a completely open, self-motivated approach, but you have to be aware of the trade-off you’re making in your organization.

“Traditional project management tends to be rigid, based on milestones and formal deadlines, where DevOps is more dynamic, agile, and open to rapid changes,” Geffray says.

 

DevOps frowns on the mic drop

DevOps evangelists laud the discipline for encouraging developers to be more accountable not just for their own individual components and milestones, but for the project’s overall success and health into the future as well. It takes contributors out of the mic-drop mindset, where they see their role as simply delivering their payload and striding purposefully away.

Project managers can take advantage of this cultural shift to point out that the world is becoming a more accountable place. DevOps is just one of many examples.

 

Project managers already have vital skills some DevOps leaders lack

Project managers outside the pure coding realm understand things many IT leaders have to learn on the fly, including the basics of good resource management and the right amount of force and finesse to apply with each contributor and client are still important. “The IT staffer who has experience and skills in this area is in the minority for sure,” said Ron Webb, APQC executive director, in an interview with The Enterprisers Project.

 

Listen for more

If you prefer absorbing knowledge through your earbuds, the team at Arrested DevOps podcast has you covered. There are dozens of episodes, and they promise that they “probably won’t destroy your career with bad advice.”

Jason Compton
Post by Jason Compton

Jason Compton is a writer with over 15 years of experience covering marketing, sales, and service. Based in Madison, WI, he is a regular contributor to Direct Marketing News, previously served as executive editor of CRM Magazine, and has been published in over 50 outlets.

One Response to DevOps: enough knowledge to be dangerous

Leave a Reply

Your email address will not be published. Required fields are marked *