5. Focusing on CI/CD can simply shift bottlenecks

Logan Daigle, director of DevOps strategy and delivery, CollabNet VersionOne: “Everyone in the marketplace talks about automation and CI/CD, but in reality, not focusing on those with systems thinking across a value stream will lead to shifting bottlenecks that mask the real problem(s) in an organization.”

[ Need a primer on continuous integration/continuous delivery? Read What is CI/CD? and Getting started with CI/CD: 6 pitfalls to avoid. ]

6. Source code is not documentation

Mirco Hering, APAC lead for DevOps & Agile, Accenture: “Against my previous experience and my gut feeling as a developer and DevOps advocate, I learned how wrong and potentially dangerous the notion of documentation in code is. As developers, we often feel like documentation is something unnecessary and something to be at best tolerated, as who matters most should be able to understand our well-structured and commented code. Well, okay, sometimes we don’t do that. But even if we do, we have forgotten that we are not the only people that matter.

“It restricts the understanding of our solution to an elite few and makes it unnecessarily hard for people with less technical backgrounds or only knowledge of other technologies. I have encountered several executives recently who could not explain the solution their team built because no generally understandable documentation existed. I have met teams who got in trouble because new joiners had to spend a lot of time understanding the code without documentation as a beginners’ guide. And yes, as a consultant I have often been prevented from reviewing solutions because nothing was available to review apart from source code.

“Generally, understandable documentation has a democratizing effect that we have somewhat forgotten about. I personally learned to appreciate documentation a lot more last year as I have seen what happens when documentation only exists in source code form.”

7. You don’t need people with DevOps in their title

Anders Wallgren, CTO, Electric Cloud: “When people say they do DevOps, I always ask them: Are you a developer, an Ops person, a QA person – what? Saying that you do DevOps doesn’t actually tell me anything. So, should people have DevOps in their job title? Should we have a DevOps team? The answer, in my opinion, is no. To me, it’s strange to have a DevOps team. DevOps isn’t a thing that you do – it’s a bunch of processes, cultural practices, and tooling that are in service of each other.

[ Is “DevOps engineer”  a useful title? Read The great “DevOps engineer” title debate. ]

There are development teams, QA teams, operations teams, product teams, etc. What these teams do collectively as an organization is what we would call DevOps. Leaders should align teams so that all the combined requisite skills needed within the organization are well-organized for collaboration and learning, and more frequently that means having teams aligned around the entire software delivery pipeline. Providing easy access to all the expertise that the organization needs, whether it’s dev expertise on one hand or operational, security, or deployment expertise, on the other hand, is vital to success.

Once an organization is doing all of those things and doing them well, then the company is practicing DevOps.

Of course, hiring managers are going to look to hire people with certain skill sets and keywords like ‘DevOps’ help identify past experiences they desire. But it is a bit contrarian to say that DevOps should be in people’s titles.”

[ What do great agile leaders do differently? Read How to be a stronger DevOps leader: 9 tips. ]

Pages