I sometimes see organisations attempt to climb the DevOps mountain in one large step. They plan big. They start big. The execute big. It is a big play all over. But when it comes to DevOps, bigger is not better.
DevOps impacts developers, operations, testing – and of course, the business. Starting big puts pressure on all these areas.
There is a learning curve for engineers who are used to cutting Java code and then need to get adjusted to a DevOps platform such as Docker or Kubernetes. Training and time are needed for the dev team to achieve productivity with a new toolset. And developers are a valuable resource that are not at their most effective when troubleshooting a server issue. Moving a lot of developers into DevOps, quickly, is an expensive exercise. Don’t make big DevOps moves unless you are ready to face disrupted developers, and likely resignations.
Many IT departments struggle to keep pace with environment changes, even in organisations with minimal automation and (relatively) infrequent change cycles. DevOps puts the pressure on IT Ops to speed up the pace of change, and frequently this leads to undetected human errors that cause larger issues at a later stage. Change processes get discarded or bypassed as roadblocks, but aren’t replaced with any other check or balance. Increased Configuration Drift is a particularly common negative outcome of faster paces of change without the correct monitoring and management.
DevOps shifts testing responsibility away from a designated testing teams or specific individuals to a shared responsibility model – backed by automation. This can displace people who were in specialist testing roles, who don’t fit well into the new way of working. Getting rid of testers is not the answer, either: it takes time for any new testing workflow to become productive and effective. DevOps can be the best thing that ever happened to your testing function, or the worst – depending on how big you go to start with.
Clients, users…the Business
If your business regards DevOps as ‘an IT thing’, and believe they do not need to change as well, your DevOps initiative mustn’t start off big. The business needs time to learn and adjust to the new world that DevOps brings them. If you start too big, it will fail hard and IT will be blamed. And good luck getting the next DevOps change off the ground after that.
A DevOps initiative will always encounter resistance to change. DevOps will end up off the rails if you go too big: avoid the disaster by starting slowly and deliberately.
Know the goals. Know the scope. Know where you are going. Know how you will get there. Work through challenges. Achieve small success. Build on this success. Once you have witnessed predictable success, then build and scale.