The journey to DevOps starts with solving problems
If you want to do DevOps, don't just follow the prescribed strategies and roadmaps that other companies lay out. Assess your own process, and start addressing your own problems.
For some companies, the journey to DevOps is fraught with difficulties. It's made even harder, though, when they don't understand the problems DevOps is supposed to solve.
It can be tempting for business leaders and managers to reach out for guides, frameworks and easy-to-communicate strategies. Some of these approaches may be helpful and useful but only if these guides, frameworks and strategies address the same problems you actually have.
So, what is DevOps?
It's made even more confusing by different interpretations of what DevOps actually is. Some of these guides and frameworks describe DevOps as a mindset. It's not. They might see DevOps as a linguistic construct that describes co-workers who sit together and happen to be development and operations engineers. Sometimes, DevOps is used to describe projects where developers and operations staff work together or even talk to each other.
I've even seen DevOps explained as development, test and operations coming together in a Venn diagram, the overlap being labeled as DevOps. Isn't testing part of development? I've heard of organizations renaming their development team to DevOps and declaring victory over DevOps, even though nothing has changed.
DevOps, it appears, can be anything you want it to be. And I agree, but underneath all of these labels, seating arrangements and Venn diagrams, it needs to solve problems.
DevOps is about problems
DevOps is about breaking down barriers between development and operations. It's about solving the many problems that come with trying to ship and maintain software and value for your customers. It's about removing the friction between writing the code and supporting the resulting service or platform.
The goal for most software companies is to design, build, deploy and maintain code with the least amount of friction possible. DevOps is the outcome of solving these problems. And no two companies will have exactly the same problem.
If you set out to solve problems and remove friction, you'll move toward DevOps naturally.
To succeed, you need absolute clarity over what your current problems are and where you want to get to. If you have no idea what your current friction points or problems are, how can you ever know whether you are solving them?
And this is why people rely on other's ideas of DevOps. These guides are easy to follow and make it easier to point others in your business toward them and say, "Yes, we're doing that." It's also easy to say DevOps doesn't work if you implement someone else's solution and it fails, which is highly likely given other company's problems will be different to yours.
Define DevOps on your own terms
If you set out to solve problems and remove friction, you'll move toward DevOps naturally. When you solve your current problems, new ones will pop up. Problems are part of business, and good businesses have good problems to solve.
When you remove friction, you're on the journey to DevOps. And whatever team structure, job descriptions, department names and org structure you have will be your version of DevOps. And if it works toward solving problems, it will be the right thing for you.
If your org structure or team names match what others are saying about DevOps, great. And if your version results in a DevOps that doesn't seem to match anyone else's, don't worry. As long as you're solving your problems and removing the friction in your process, you'll succeed.
