Ops vs. Dev
It’s an understatement to say there’s been a huge amount of buzz around using DevOps as a solution to help solve operations and development problems.
DevOps eBooks, Books, Blogs, and Podcast are now flooding the Internet with content about a topic very few really seem to understand or agree on.
Shades of DevOps Culture
So far I’ve been a part of 3 implementations of DevOps, 2 of which failed in my opinion due to a lack of understanding, ego, grandstanding, and culture clash.
And the other is underway and seems to be working, so far…[update also failed].
On Shades of DevOps, we’ll visit the visible culture challenges and opportunities organizations have as they work through the pitfalls and mistakes of their DevOps implementation.
Why not just read a book and form a team?
Because DevOps is not an easy change for the legacy IT Department to make, and in some cases, it may not be worth the trouble.
But for those groups willing to press through, the value-add is a high-performing organization and better IT service delivery.
DevOps Culture at Meetup
3 Basic Shades: White, Grey, and Black
Let’s focus for a moment on the title “Shades of DevOps.” This title perfectly sums up DevOps because there is no one way of approaching it, however; to make things easy and beneficial we’ll look at 3 basic shades: white, grey, and black.
- White – Dipping your toe into the murky waters but not really ready to get wet. Now you can actually say you’re using DevOps skills but you really aren’t.
- Grey – Wading in slowly and learning from your mistakes but only going waste deep. No real value has been gained except finding the threshold where the pain is too much to bear.
- Black – Jumping in headfirst and chaos ensued from clashes between Ops, Engineering, and Development tribes. OMG, what have we done?
All joking aside, in my opinion, DevOps is more of a culture than a methodology, software tool, or even a practice.
Problems between development and operations have existed for years because IT Operations and Engineering see Development as a “THEY” instead of  “WE.” [We’ll go deep into this in later posts.]
#1 Obstacle – Are You A Control Freak?
I’ve been in closed-door meetings with executives and I’ve heard every excuse there is why IT can’t offer the level of service developers are asking for.
The main problem is, “How do you maintain control of your staff and resources” when the solution to solve the service problem is a sharing culture that collaborates extremely close with (development)?
Obviously, vendors would disagree with my views because they want to sell you software tools and training for how to use DevOps.
Sorry to rain on your parade but the real solution cannot be purchased; I will even go as far as to say it will be impossible for some organizations because the people trying to institute DevOps want to maintain absolute control.
“I will even go as far as to say it will be impossible for some organizations because the people trying to institute DevOps want to maintain absolute control.”
Control is Kryptonite
In DevOps, control is like kryptonite that drains the value-add from a DevOps seedling.
One day you don’t decide you are now a DevOps shop and form a team, it’s more of a decision you make to start changing how you think.
Retrospective
From a leadership perspective start communicating and considering the following:
- Development is your partner. Schedule meetings with them so you can start understanding what they need.
- Why are you protecting prima-donnas who nobody wants to work with? They are the biggest a-holes and roadblocks to progress [get rid of them]!
- Are you focusing on what is important based on delivering great services to your customer or are you building “The Great Pyramids” for egos so you look like you are accomplishing great things but in reality adding very little value to the company [but you look good]?
- Who benefits from the projects in the queue or backlog [time to re-prioritize]?
- Do you have any of your best talent meetings and work with your customers daily so osmosis is happening [seeing and feeling the problems will help solve them]?
- Are outside forces such as vendors or political agendas blurring your focus and causing you to make “stupid” decisions [an MBA doesn’t make you immune to STUPID]?
- Are your leaders, managers, and executives part of the problem? Are they telling you what you want to hear? [read the emperor’s new clothes]
- Does your hiring process weed out hiring staff that is counterproductive to a DevOps culture? [Here are 3 DevOps Interview Questions to get the focus on the right mindset]
- Are you rewarding those who collaborate and are cultivating a DevOps culture? [Bonuses are great incentives]
- Finally, did you ask yourself if you are the problem? If you are a prima-donna with a political agenda that has everyone buzzing around you building the Great Pyramids, then forget about DevOps solving problems. [change direction]
Wow, that should hopefully stir up some interest in what DevOps is about!
By the way, I’m not asking for you to agree with me because the bottom line is results. And hopefully, Shades of DevOps will help you think differently about – well – DevOps.
DevOps References:
- What is DevOps? Infrastructure as Code by  Mike Loukides (Download Free eBook)
- Adrian Cockcroft’s article ( Read: NoOps at Netflix)
- John Allspaw’s article (Read: Rebuttal)
- The Phoenix by Gene Kim
