The five most common mistakes approaching DevOps
I’ve been using DevOps for a few years now and I love debunking myths and making things clear about it – after all, there was no agreed upon definition of DevOps for many years. With that in mind, here are the five most common mistakes I have heard from people approaching DevOps:
“…from now on, DevOps all the things!”
This is the most common mistake people make when approaching DevOps, courtesy of the enthusiasm brought by it. This kind of drive is usually detrimental, because DevOps often brings a huge change in how an organisation works. This cannot be executed in just one giant step, and instead must be diluted over a longer period of time. Calm down folks, and stick to a plan starting with the basics: having end-to-end control of the pipeline, automate as much as is possible, and focus on delivering value.
“So DevOps is basically Scrum!”
DevOps isn’t Scrum, or any other methodology either. DevOps itself is not a methodology at all, but rather a collection of best practices to bring value to the customer – whoever this is – in a repeatable and predictable way, while also leveraging technology and processes – whatever those are – in the process. You can cherry pick what you like and what you know is going to work, as there is no strict boundary to what is and isn’t DevOps and experimenting to find the right balance to suit your specific requirements is essential.
“DevOps is the silver bullet which is going to fix everything!”
DevOps is purely about people. Automation, Infrastructure as Code, these are all technologies and they can be applied everywhere in any way. The Phoenix Project is crystal clear with this: what really matters is how people deliver their stuff, knowing it inside and out. DevOps isn’t about tools or technology, it is all about how people work together.
“It is just for new technologies and rock stars / my team cannot do DevOps”
Given the countless ‘DevOps for mainframe professionals’ whitepapers around I would reply with a firm “no!” to the first statement. Also, the other way around is true as well: there is no impediment in DevOps itself for any team. It is also worth mentioning that doing DevOps doesn’t mean going full-blown with a large scale deployment of new, complicated and expensive tools. It is just about how the problem is approached and how the best practices are applied – focusing on the value with something that works for us.
“There is no need for testing in DevOps”
This is starting to come up too often for my taste. Testing is not only extremely important, it is actually embedded into the process. It doesn’t mean ‘developers do QA’, it means ‘developers and QA professionals work together to ensure a certain quality bar for the product from different point of views’. Again, it’s a focus on the people.
So, how do we avoid these mistakes? Let me be clear: there is no Implementing DevOps guide step-by-step, as every case has its peculiar requirements and perks. You cannot standardise what has worked elsewhere (with different tools, different mindsets, different groups and different people) but you can definitely learn from other people’s experiences. Also, I suggest always getting the basics right and in small steps: work together, find a stable way of regularly delivering value to the customer, automate what you do, don’t be dependent by manual interactions, approach the Minimum Viable Product mindset so you can quickly and iteratively build smaller portions of your ideas to be immediately validated by the customer. There might not be a silver bullet, but there are definitely tried-and-tested scenarios out there.
