I remember the first time someone told me the company I was working for was looking at "doing DevOps". My first question was "what is that?" Long story short...no one actually knew. The truth is that most people just Google it and get the standard Wikipedia answer, "DevOps (a clipped compound of "development" and "operations") is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops)." While this is true this barely scratches the surface of what is means to "do" DevOps.
Depending on your company and it's model you will more than likely face completely foreign problems to anything you have seen before, no matter what industry you work in. Yes, you will see bloated processes supported by people instead of automation, you will see database jobs connected to database jobs all running out of sync on ancient hardware and you will see security vulnerabilities that make you blush. But mostly you will see every conceivable form of inefficiency known to humankind. This inefficiency will more often than not represent itself as security alerts you have always gotten and communication processes you have always followed. The processes themselves may not be bad, but they may be unwarranted, outdated or even ridiculously complicated. When you're looking at the company on the whole, if you decided to implement DevOps in your company to save on Operating costs then you have a very obvious process problem. And I hate to say this but it's happening at every level of your company, from executive heavy approval processes to the trickle down effect of over zealous documentation and "edge case" fear based solutions. The good news is that all of this can be fixed in a few simple steps:
1. Define a communication structure. Agile supports a more free-flowing communication structure where you can talk to anyone, anywhere. In theory everyone in this scenario is free to say what needs to be said to anyone they need to say it to. In practice very few people in lower profile roles will want to tell the Senior Vice President of Product Delivery, that the platform that was purchased can only do a tenth of what it needs to do and they will need to buy a solution for their solution. The real problem in this scenario is that the software selection process either ignored direct feedback from the technology teams or never actually asked for input. Don't hand your development team a fully baked solution without getting their input. Talk to your teams!
2. Get buy-in at the top and work your way down. Many companies like to start by enforcing all their process changes at the bottom first.This fails to address the problem that most executive level team members are the first to break these processes due to misunderstanding of their intention. Not only this but many times extra process is introduced to account for the fact that some groups refuse to adopt the changes that were never modeled by their leader. When feedback is brought forward that reinforces the need to change, embrace the solution and fix the problem.
3. Adopt a "learn to fail" culture. This means changing your mindset away from "failure is bad" to "failure is learning". This also means in many ways an organization that widely used to try to mitigate failure, needs to learn how to fail gracefully and then adapt. This is the part of 'fail fast' that many people miss, in a way you are being forced to evolve your product through failure (super scary in practice) which means until your product is done you'll probably laugh or cry at every demo. Just accept it, that's part of adapting!
Here's the thing. No one person in the world has all the answers on how best to move a company towards DevOps. But there are a lot of people with a lot of input that don't necessarily get heard. If you're one of those people and would like to share your ideas or feedback on my blog also, let me know, I'll be happy to welcome additional authors of Content.