Ranger4 DevOps Blog

#DevOpsFriday5 Round-Up 2: The Most Common DevOps Mistakes Made

Posted by Tejinder Sehgal on Thu, May 14, 2015 @ 12:05 PM

It's been over a year since we published our first #DevOpsFriday5 and to celebrate we're publishing collections of our favourite answers to each of the questions - and have launched a whole new set for the twelve months ahead. This week we're tackling Question Two:

When people 'do' DevOps, what's the most common mistake you see them make?

This question got many interesting answers and although there were a wide range of reasons, having gone back and reviewed theses responses it is clear that a pattern seemed to have emerged. Authors were answering with similar mistakes they were seeing made; we've grouped the responses below accordingly.

Trying to Automate Too Much, Too Early

"There’s a couple of obvious ones, firstly that DevOps means automation. While it can be one element, it cannot be the sole solution.  Secondly that it has an end point, there are levels of maturity but there should be a culture of continuous improvement."
Gareth Wharton

"I see two mistakes over and over again.  First, the focus is only on automating certain activities and second, no real thought is put into understanding the overall SDLC flow.  Separately they create subpar results but put together they have a devastating impact on the team’s initiative. 

The problem with “automating current activity only” approach is that its focus is too narrow.  Lean law follows the 80/20 rule.  20% of cycle time is considered to be productive “hands on keyboard” work and 80% is attributed to waiting, rework, waste etc.  If all you do is automating the “hands on keyboard”, then all you have done is impact the 20%.  The 80% remains untouched around.  No wonder teams end up scratching their heads as to why things are not moving faster. 

Which brings me to my second point.  DevOps is about streamlining the flow of your entire SDLC.  Starting an initiative without understanding / measuring the overall flow and the impact of your activity to that flow is a recipe for disaster.  If you don’t measure your current state (both the 80% and 20%), how can you tell if you have made progress and be able to communicate your benefits.

I cannot tell you how many times I have walked into the client site to find the team demoralised, frustrated, and in some cases ready to give up simply because of these two actions alone." Mustafa Kapadia

"I think the single biggest mistake when starting to "do" DevOps is the tendency to jump in and automate everything without first figuring out what actually needs improvement. Automating poor processes just means you do it poorly faster, which isn't what you want. And then there's knowing what you want in the first place. Some folks are looking for time to market improvements, others more frequently deploys, others just need more stability and the ability to standardise. If you don't know what you're trying to achieve, you can't really say that automation is going to get you there." Lori MacVittie

"Underestimating the organisational transformation required, and thinking that automation tools alone will solve the problem. If we keep the production line analogy it doesn't matter how good the tools are if the production processes and structures are not in place to use them to best advantage. So it's a synergy between having the right organisational structure and culture in place, underpinned by great tooling and systems."
David Upton

"People are preoccupied about creating new processes and set up automation everywhere it's possible. They tend to forget that without metrics, before and after the implementation of DevOps, it's all useless. What's the point of spending time and money to improve things if, in the end, you can't see the difference? People also tend to forget to communicate with everyone and in an efficient way about what they are trying to do. They just do it and assume it might be enough, just as if everyone would embrace everything new just because someone said it's better without saying why. -Communication-Collaboration-Culture." Bertrand Benard

"Organisations often don't approach DevOps holistically enough. They set up a DevOps team or focus too much on automation without looking at business change and collaboration aspects. I actually don't think these initiatives are a bad thing - DevOps Engineers as a job title is fine with me and DevOps Teams are often a positive initiative too. (I used to say DevOps Teams were a big mistake, but experience has shown me some very high performing DevOps teams creating a huge amounts of business value.) I just think you are missing a lot of the benefits if you don't look at it more holistically and try to break down this Dev/Ops silo in other, more substantial ways. A second mistake I see people make is not investing strongly in the right initiatives to make DevOps happen - both from a people and a re-platforming perspective. I expand on this more in the next question!" Benjamin Wootton

"I've certainly seen the usual answer here, which is customers renaming an existing team to be the 'DevOps' team. Then getting them to automate their current processes (which are often broken). This points to an under-appreciation of the core concept of DevOps (collaboration) and seeks to 'fix' current under-analysed enterprise process by just making it go faster.

Honourable mention here goes to not having a set of success criteria and metrics in place to measure their evolving processes. The overarching goal of DevOps is to enable the business to hit its changing goals by facilitating faster feedback loops. It's important that companies measure everything around their deliveries both from an internal (process development) and external (delivering customer and business value) viewpoint." John Harris

"They think DevOps is all about automation when really it was largely born out of frustration that humans wouldn't work together across organizational boundaries. It's inherently a socio-techical system with many principles in common with other trades like coal mining dating as far back as the later 1940's." Kevin Behr

Creating Another (DevOps) Silo

"The biggest mistake I see is projects/clients/organisations bringing in a 'DevOps expert' to help them get started and then not continuing to improve once they've left." Sam Marland

"Creating a DevOps silo – an organisation buys into the DevOps approach and they recruit a central DevOps team. Rather than improve the situation the organisation has created a ‘DevOps Silo’. The DevOps skills should be embedded within teams rather than becoming a separate entity." Paul Hancock

"Too much reliance on tooling as the sliver bullet and compounding it by giving the tooling responsibility to one person.  I see companies create a DevOps role within the dev team and give that role to one person who is responsible for developing, deploying and running the tools.  This does not address the problems of culture, people or process and simply creates another bottleneck silo.  It very common because it’s an obvious win that developers typically have control over." Richard Wadsworth

"The biggest mistake is people believe that DevOps is a title or team. DevOps is about breaking down organisational silos; as I said in my 10 Myths of DevOps post, hiring a "DevOps engineer" or "DevOps" team only adds another silo to the farm. Organisations need to stop thinking of DevOps as a "role" and start thinking of it as a philosophy." Seth Vargo

"Setting up a DevOps team. DevOps isn't a thing you can bolt onto your business, it’s something that needs cultural change to do." Mike Preston

"Many people have come to understand 'DevOps' as mostly just infrastructure automation or release management. They might start a 'DevOps Team' whose responsibility is to "automate stuff", but if that team remains isolated from other teams, it will become a new silo, pushing Dev and Ops even further apart. So beware of the permanent 'DevOps Team'; instead, use a short-lived team to reach a better place and then dissolve the team into product-aligned teams." Matthew Skelton

"The worrying trend I see is that 'doing' DevOps is sometimes construed as 'hiring a team of DevOps engineers' or 'implementing some DevOps tools' and nothing more. The whole ethos behind the DevOps movement is to change the default ways of working and culture within the organisation so that the traditional silos of software delivery and systems management are removed thus making the process of delivering and supporting IT change - be that software, hardware or infrastructure - highly collaborative, seamless and effective." Paul Swartout

"Becoming masters of software delivery is cited in recent research as one of the key concerns of the average CEO over and above competition from rivals. Yet the most common mistake I see is that organisations are not taking excellence in software delivery seriously enough. It therefore follows that they are not taking DevOps seriously enough either. Perhaps it is because, unlike Agile where there are specific prescriptive methodologies and frameworks to get your teeth into, DevOps is less prescriptive and actually requires a lot more thinking and strategy to get right.

If you consider the analogy that the processes and tools to build, deploy, test and ship code to be machines within a code factory, no other industry would put up with factory processes that are so antiquated and manual.

For the record, the worst mistake I have seen is a team badged as ‘DevOps’ who were acting as a proxy between Developers and Operations people, in effect making the collaboration between Dev and Ops even worse than before!" Jonny Wooldridge

"Focussing too much on the A for Automation in the Culture-Automation-Lean-Metrics-Sharing (CALMS) model and not enough on the Culture & Sharing aspects. DevOps is about communication and collaboration as opposed to silos and isolation.

So my first question for anyone who says that they are “doing DevOps” is: “Who have you included in your DevOps conversation?” – and if that list doesn’t include Dev, Ops, QA, HR, Finance, product owners, senior management (to understand the strategic direction) etc then you’re not doing DevOps!" Stephen Thair

"Creating a dedicated DevOps team to "be the DevOps." A DevOps team of this sort risks becoming yet another silo - exactly counter to the goals." Eric Minick

Focusing on Tooling Alone

"Ironically (for someone who is in the business of promoting and selling tooling), I think the biggest deviation (I can’t call it a mistake!) from the goal is to just assume that a bunch of tools can solve all your problems. This leads to a sub-team (or even a DevOps team in its own right) spending the majority of their time playing with the latest shiny toys and ignoring the day to day activities that still must go on in the journey to achieving the goals mentioned above. This is actually counter to what most definitions of DevOps subscribe to; breaking down those traditional silos between the development teams and the Ops teams." Rob Vanstone

"People think that DevOps is purely about the tools to support rapid release into production - DevOps is much, much more.  

The biggest mistake I see is to underestimate the amount of cultural change needed.  This cultural shift requires top-down executive support together with bottom-up buy-in and understanding."
Kay Johnson

"To focus too much on the tools instead of working on the right mindset to enable DevOps." Olaf Kilian

"Not addressing the people and culture part of DevOps and thinking that buying a deployment tool makes them “DevOps”.

The ability to provision infrastructure and automate releases is really important. However, it doesn’t go anywhere near far enough solving cultural problems where individuals don’t think about the greater good.

If you have great technology but don’t have great teams to operate them, then it’s all a bit of a waste of time." Jonathan Fletcher

"Leading with tools. If you lead with tools, the tools will end up dictating your process and culture. Tools solve nothing. The tool fit into the right process and the culture does. Along the same lines is the person who procure the tools, are not the ones who will realise the benefit. Influencers need to be empowered." Chris Riley

"Putting tools above culture, and enforcing hierarchical silos." Magnus Hedemark

Ignoring the Cultural Aspects

"Too much focus on Automation, Lean and Metrics, and not enough on Culture and Sharing. Particularly if you're a technical person, it's easy to be attracted by the cool stuff, and neglect the people dimension. One of the guys who coined CA(L)MS, John Willis, once sent a frustrated Tweet "I am officially pulling the "C" out of CAMS... Nobody gives a shit about it anyway. It's always about the tools... #devopsIsDead"." Mark Smalley

"They underestimate, undervalue or do not understand what it takes to instill a new IT culture. Culture takes time and cannot be mandated or automated." Jayne Groll

"Hiring for a DevOps position instead of bringing in the culture. It's a culture that should be practiced by everyone in the company." Nitin Gonslaves

Last week we looked back at Question One: What's Your Preferred Definition of DevOps?

Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5,click the button below.

Get Involved in #DevOpsFriday5    

 

Topics: DevOpstastic, #DevOpsFriday5, DevOps