The Problem with DevOps
DevOps has been a transformational change in the world of product development.
DevOps can be defined in a lot of ways. I like this definition:
To put it simply, DevOps = you code it, you own it.
Back in the day, before Agile development took over the software world, developers would deploy software, and other operations engineers would be responsible for keeping it up and running. I’m using the past tense here, but in reality a lot of companies still use this technique today. Needless to say, when you have a group of people who lack context and are trying to fix code that other’s wrote, a solution is not often developed very quickly.
Enter DevOps, the answer to all of these problems. Here, the developers who shipped the code now have to maintain it. So when something breaks, they can fix it quickly. They wrote the code, so they have much more context and a better understanding of what is happening.
I think this makes a ton of sense. But that doesn’t mean there aren’t any issues with DevOps.
From a product management prospective, DevOps can be hard to manage. Your team of say seven engineers not only has to build and ship new products, but they have to maintain and be on-call for everything they have built in the past. In this way, the most productive teams get inherently “penalized” for producing a lot of successful products. Extending this logic further, at some point, the team is not going to be able to sustain both development and operations roles. A tipping point is reached where after so many features and products have shipped, it becomes impossible to maintain the existing product line while continuing to iterate and pump out new product. I think a lot of teams find themselves in this overwhelming situation. They have too much to maintain, too little time to meet their new product commitments, and work within a company that is unable to adjust resourcing fast enough.
As a PM, there is a constant struggle between trying to move a project forward while still supporting the developers in maintaining existing products. It’s really difficult to keep project velocity high when you never know how much of your team’s time is going to be consumed by bugs or incidents that crop up out of nowhere. And for developers, it can be a tough life trying to build a new product when these issues keep stealing your attention.
Making matters a little more complicated is that most people want to work on the new and shiny stuff. Addressing bugs or being on call for incidents is not the most enthralling work. It’s high stress and often thankless. No one gets a pat on the back for not causing a Sev-1.
So what is the solution? In my opinion, the biggest issue with DevOps is that it lacks focus. I mean, according to people like Bill Gates and Warren Buffett, focus has been the single most important factor in their success. So how can a team possibly focus on their goal when they are constantly being bombarded with bugs, incidents, and technical debt?
Rotating DevOps
A possible solution could be for developers to rotate between development and operations activities within the team. In this way, your team of seven might have five engineers working on the new product, while the other two are on-call and addressing the issues that will inevitably pop-up. At the end of the sprint, everyone rotates, ensuring that the knowledge transfer continues to happen and guaranteeing that everyone gets to work on the shiny new things.
This is obviously just my opinion. The awesome thing about working with software teams is everyone is always open to try new things in an effort to continually improve the way we work.
