{"id":52104,"date":"2021-10-05T15:00:10","date_gmt":"2021-10-05T14:00:10","guid":{"rendered":"https:\/\/www.microsoft.com\/en-gb\/industry\/blog\/?p=52104"},"modified":"2022-02-10T20:47:19","modified_gmt":"2022-02-10T19:47:19","slug":"the-five-most-common-mistakes-approaching-devops","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-gb\/industry\/blog\/technetuk\/2021\/10\/05\/the-five-most-common-mistakes-approaching-devops\/","title":{"rendered":"The five most common mistakes approaching DevOps"},"content":{"rendered":"

\"An<\/p>\n

I’ve been using DevOps for a few years now and I love debunking myths and making things clear about it \u2013 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:<\/p>\n

\u201c\u2026from now on, DevOps all the things!\u201d<\/strong><\/em><\/p>\n

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.<\/p>\n

\u201cSo DevOps is basically Scrum!\u201d<\/strong><\/em><\/p>\n

DevOps isn\u2019t 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 \u2013 whoever this is \u2013 in a repeatable and predictable way, while also leveraging technology and processes \u2013 whatever those are \u2013 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\u2019t DevOps and experimenting to find the right balance to suit your specific requirements is essential.<\/p>\n

\u201cDevOps is the silver bullet which is going to fix everything!\u201d<\/strong><\/em><\/p>\n

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\u2019t about tools or technology, it is all about how people work together.<\/p>\n

\u201cIt is just for new technologies and rock stars \/ my team cannot do DevOps\u201d<\/strong><\/em><\/p>\n

Given the countless \u2018DevOps for mainframe professionals\u2019 whitepapers around I would reply with a firm \u201cno!\u201d 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\u2019t 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 \u2013 focusing on the value with something that works for us.<\/p>\n

\u201cThere is no need for testing in DevOps\u201d<\/strong><\/em><\/p>\n

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\u2019t mean \u2018developers do QA\u2019, it means \u2018developers and QA professionals work together to ensure a certain quality bar for the product from different point of views\u2019. Again, it’s a focus on the people.<\/p>\n

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\u2019t 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.<\/p>\n

 <\/p>\n

Learn more<\/h3>\n