I am starting to get annoyed with the direction of all the DevOps discussions that fly across my Twitter feed each day. I think people are focusing way too much on culture and not taking a pragmatic approach to solving business problems. I’ll be the first to admit that embracing the DevOps movement can be transformational and in some cases a major culture shock to large organizations. But there is much more to DevOps than culture.
News Flash! Culture change is nothing new in the enterprise. When service-oriented architecture (SOA) was the big buzzword, nothing killed SOA projects more often than resisting cultures (see my presentation on culture change from 2008). When business process management (BPM) was going to save the day for IT, you guessed it, culture got in the way. In fact, if you go back to the early days of the Internet or the shift away from mainframes to client-server architectures, it was culture that slowed things down. So when I see the daily DevOps and culture presentations with titles like “The Cognitive Neuroscience of Empathy,” I have to ask, are we missing the boat here?
Yes, empathy plays a role. Yes, we should study the words of Deming and other iconic thought leaders. Yes, we should break down silos. We get it already. But culture change is a side effect of something much bigger. Why don’t we first ask the number-one question every architect should lead with: “What problem are we trying to solve?”
Why DevOps?
Why DevOps? From my experience working with several large enterprises, the reasons are unique to each organization. The answer usually includes at least one or more of the following business drivers (these are actual customer drivers I have come across):
- Get products to market faster
- Improve overall reliability of IT
- Foster innovation, experimentation
- New way of building software as we move to the cloud
- Drive efficiencies and increase repeatability.
What prevents organizations from achieving these goals?
- Overloaded with maintenance, no time to innovate
- Outdated operational processes
- Ineffective existing SDLC (software development life cycle)
- Current organizational structures
- Competing incentives
- Lack of visibility in key metrics
- and the list goes on and on.
Fixing these issues does require changes to the culture. The problem I have is that all we seem to talk about is how to change a culture instead of how to fix the problems that require the culture to be changed in the first place.
When I talk to a CIO or CTO about their DevOps initiative, the last thing I am going to do is preach about empathy and offer quotes from Deming and Drucker. Instead, I am going to dig into the problem statement and identify what the opportunities (bottlenecks) are.
I think we all agree that incremental change fostered by quick feedback loops is at the heart of DevOps. Culture change should be approached the same way. When was the last time a big bang approach worked for anything in IT? We should stop going into enterprises leading with the culture change talk. We should start with identifying the problem statement; then, we should identify the blockers and put a plan into place to remove them, one iteration at a time.
Summary
Making DevOps synonymous with culture change does not help enterprises succeed with DevOps. Culture change is a byproduct or an output that occurs when embracing the DevOps movement. Focus on real business problems, not solutions. Put the Kool-Aid down, roll up your sleeves, and start solving business problems.
Yes, too much focus on culture and not enough on actionable steps. A clear indication that there’s more punditry than work going on in this area. My presentation next week at DevOps Summit directly addresses your assertion and moreover attacks the notion that culture needs to change but rather changes in response to process and organizational changes that accompany successful creation of the ideation-to-operate delivery system.