October 24, 2020 at 12:00 am
Comments posted to this topic are about the item What's Causing the Pushback with DevOps?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 25, 2020 at 3:36 pm
Grant, I can tell you the reasons why DevOps has failed, in the past, where I work. And we're now in a second iteration to implement DevOps, but I predict DevOps will fail again for much the same reasons as it did before.
There are multiple reasons why DevOps fail where I work. Some of these I've mentioned before here on SSC, so won't go into detail. One of the reasons DevOps failed in the past and will likely fail again is because of the "stay in your lane" attitude. A couple years ago we had a Business Analyst who really championed DevOps. I am a strong proponent of DevOps as well, so I worked with that BA to try and get DevOps adopted. However, that BA left to pursue other opportunities. Even though I understand the principles of DevOps, have attended several trainings on DevOps and virtual conferences on DevOps, all of that doesn't matter. I'm a developer. At work, developers are perceived to only bang code, that's it. I don't know if they think this or not, but it's like being able to understand DevOps is beyond a developer's comprehension. Stay in your lane. You cannot help implement DevOps.
After that BA left, I witnessed the utter loathing my boss and colleagues had for DevOps. They are convinced that DevOps cannot work and will inevitably fail. My guess is that it is an example of what you discussed is people's resistance to changing how they work; the process they've followed for many years. It's what they know and understand. "Never talking with people in Ops" is just taken to be the norm. You have to fill out paperwork, submit it to management and teams for review, allow it to go up the chain of command until it reaches some high enough level where the Dev management can introduce the idea to an Ops management, and then it goes down the command chain, etc. Then follow the reverse process to return whatever was decided by Ops. This approach is sacrosanct.
The interesting thing is the BA who left has returned to work for us again. Now, the interest in DevOps by upper management has returned. (Going back to the first attitude, stay in your lane, someone who can comprehend DevOps has returned so we may now proceed with DevOps.) So, all teams are having to try and adopt it again. I'm sure this doesn't sit well with most teams. I don't believe they'll actively fight it; my guess is it will not be adopted with enthusiasm. Which is likely to prove that DevOps doesn't work. Plus, the need to have a complicated communication structure in place, as I've said and will not be removed, violates DevOps.
Furthermore, it appears to me that at least with some managers, their perception of DevOps is that it means they can get their developers or DBAs to work long hours on sprints. They overload developers and DBAs with more tasks than can be done by that person in a sprint. So, people have to either not complete their assigned tasks or work long hours to complete them. This builds resentment, so devs and ops eventually hate DevOps.
Another nail in the coffin is that automation is not encouraged. Yes, the build and deployment process are done, as that's a part of the tool. But that's as far as it goes.
Another consequence of needing to adhere to a lengthy communication chain, is that no one may ever deploy without getting approval from the change management board. And that's not just to production, but test as well!
There are too many institutional barriers in the way to prevent a successful DevOps process adoption.
Kindest Regards, Rod Connect with me on LinkedIn.
October 25, 2020 at 6:42 pm
Yeow!
That's like all the problems.
When I consult on this stuff, the one strong recommendation I make is to get champions at multiple levels on multiple teams. If there are people who do think it can work and are willing to cross-over to talk to one another, you can build the framework on these people. However, without them, just management saying "Do this". You're right. It's going to fail.
That's a shame.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 26, 2020 at 8:26 am
Dev Ops here is being used for our infrastructure team: Development is still silo'd as development. Nothing else has changed, mind: Infrastructure just do infrastructure, so there's no cross over there, and Dev is Dev is Dev, even though they do some Operations work and a small amount of Infrastructure (and then get told off for doing so).
So... it does seem more like Buzz-word bingo. Changing titles doesn't change anything. Much like 'Agile'... well, delivering 100% of the project on time is Agile, right? Even though the delivery date's slipped...
October 26, 2020 at 12:46 pm
A web development team at my company started using TFVC hosted in Azure DevOps. They took the opportunity to say they are "doing DevOps." What a joke...the silo walls are thicker than ever between DEV and OPS!
Really wish Microsoft didn't include DevOps in the product name.
October 26, 2020 at 3:05 pm
Oh boy, where do I start? The reason why DevOps left a bad taste in my mouth...
Where I used to work a new IT Director took over and somehow felt that DevOps was the end all and be all of IT. He saw it purely as an actual job title rather than a process to be adopted by several roles. So he sought to eliminate all jobs to become DevOps jobs. (I kid you not) He told Developers, Database Administrators, Operations, etc...that you now all have the same job of "DevOps". To be clear I don't mean you still have DBA responsibilities but are going to be referred to as 'DevOps'. No I mean he actually thought everyone should have all the same skills because one should only concern themselves about automating their job function through DevOps. (don't even get me started on how he thought Ansible should be used)
This is one of those situations where his old company was bought out by ours and was taken on as a Director because he did such a great job with his product. The problem is he worked on a single small application with two developers. I'm sure in that situation with such a small team everyone kind of had to know a little about everything. But this guy literally thought you never had to touch a DB once you installed it. His only exposure was using MySQL for that one specific application that did not require a complex database setup.
It's not a mystery that I no longer work there. Unfortunately, he caused a mass exodus of greatly talented people from that company before management realized he was not qualified for the position and eventually he was walked out of the door.
I agree with the philosophy of DevOps but people have such wild notions of what it actually means.
October 26, 2020 at 4:21 pm
The biggest push back I see where I work is that there's not really a notion of admitting maybe your part of the puzzle could be the problem. The initially reaction anytime there's a discussion among groups(even different groups that already have ops responsibilities) is that any problem must be because of the person complaining and not anything that another group should even look at without going through management. Without fixing that basic mentality dev ops is dead from the start.
A good example of that, we had a minor issue several weeks ago. Identified and fixed the issue and notified one of the other teams involved with the root cause mentioning that it would be a bigger problem if it wasn't addressed. Crickets.... then it happened again and became a bigger issue.
October 26, 2020 at 5:04 pm
In my experience the most push back against DevOps comes from people that don't understand it. There are a lot of people that think that DevOps has not controls and that anyone is allowed to do anything. Developers working in production for example is really scary until you realize that they can't really do anything in production. The have to check in their code to version control and let all of the tests run before deploying anywhere else.
Just think about being a DBA and being asked to write testing as the main part of your job. If you did that you can run testing automatically on every deployment. The tests a DBA would write might be for security, coding standards, performance, backups run\ran correctly or anything else you can dream up. Then if the code passes the tests they are free to fly.
Keep in mind that when people don't like DevOps, it because they don't understand it. It is your job to listen to their objections and understand their concerns. They are not the same thing! Most people have good intentions and by listening to them you can address their concerns and show them how this new thing is actually going to help and not hurt.
Changing to DevOps is a multi-year process! This change will not happen over night, so patient with people and play the long game.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply