4 minute read

Some people seem to think that DevOps is a buzzword. It is not. At all.

As part of my research for integrating concepts of risk, quality assurance, and continuous testing into the IEEE 2675 working group (DevOps standard), I am realizing that there is no one single articulation of DevOps that seems to fit all contexts. However, in the spirit of DevOps, I'll continue to iterate past this issue to explore aspects of the paradigm to provide value to people I meet and conversations we have. Here are three I've been pondering:

DevOps Is an Organizational Paradigm

DevOps is about breaking apart established paradigms, structures that worked for the prior generation of problems, management methodologies that are no longer the optimal solution for tomorrows problems today. DevOps is challenging institutional values that don't actually lead to value. DevOps is helping us to take ownership over our success.
We are learning for the first time, every time, and deliberately discovering what we should know as we build the future.
Collaboration, contribution, sharing, learning, improvement, alignment, focus, value. These are words that describe our homegrown methodology, one whose aim is to meet the pace of innovation better than agility alone. Self management, self organization, self improvement. Shared understanding, shared goals, shared vision. Many experiments, many failures, and many wins.
It is fine if a single team wants to "try out DevOps", but unless the organization is prepared to support and change to value the positive outcomes of that team, initiatives won't go very far. In this way, it is a relational paradigm that applies between individuals, between teams, and between organizations too.

If you want to go fast, go alone. If you want to go far, go together.

There's juice to that statement. Fast and far are relative to what needs to get accomplished (see this link for quote etymology).

DevOps Is an Operational Paradigm

Software tools are a huge part of DevOps conversations now. Why? Because automation and efficiency, sure, but also because its easier to feel confident and efficient in our own ignorance than to face the fact that most of software is about finding the right people to build the right software for other people.
Tools are only a part of our conversation. And more often, it's tools (I mean outspoken assholes here) that dictate how [little] we understand about DevOps. Just because he buys all the ski equipment and reads a lot about which slopes are best doesn't make him an expert. Practice matters, and practice means knowing the software landscape.
But tools and automation are only an enabler to the work, an outcome of good decisions; it is the team together which holds the capability to make better decisions tomorrow. And every day has new challenges which yesterday's solutions won't overcome, not to mention known challenges that demand experience and perseverance.
If you are automating the shit out of your pipeline, good for you. Is this truly helping you learn how to provide people value, or do you more often find employees arguing about which tool and approach is better? This is an example of how hyper-focusing on tools is counter to the goal of DevOps, to iteratively improve our ability to provide value to (and with) people.

DevOps Is an Orthogonal Paradigm

In this way, DevOps is a mindset that also encompasses those who may not necessarily think it applies to them. It must include everyone, each with our own skills and perspectives. It is not simply about developers and operations. It is about connecting contributors to consumption just as much as it connects consumers to contributions. It is about the whole supply chain, the whole delivery pipeline, and the whole collective of people impacting each other.
For DevOps to be really successful, its execution must be inclusive across boundaries. That includes more than just engineering teams, it involves recruitment, marketing, sales, customer support, HR, PR, and finance. In the IEEE 2675 working group, we are finding that these other groups are a necessary part of the supply chain that DevOps teams depend on. A few examples of the need for an orthogonal approach to DevOps are:
  • How can you go "faster" if your acquisition process takes many months?
  • How can you go "faster" if a supplier doesn't provide a way to validate that you integrated their product or service correctly?
  • How can testing be continuous if it isn't automated and therein scalable?
  • How can you expect marketing to crush numbers if you don't integrate them into your sprints (their work often needs weeks/months of lead time)?
  • If your onboarding process doesn't train new engineering recruits (dev/test/ops/PM/IT) on your lifecycle, how can you expect them to "go fast"?
  • If it takes days/weeks for customer feedback to reach development cycles, how can you expect to be building the "right thing" tomorrow?
Every one of these questions takes some kind of answer that includes collaboration, which you can't expect unless you foster positive work culture and encourage people to improve professionally and personally.

DevOps Is Just a Word

DevOps is a word we have now for the next set of ideas for how to sustainable move fast in the right direction. Unlike a manifesto, its goal isn't to constrain, but to evolve. Hopefully we can come up with a better name in the future, which is highly likely because we iteratively learn. But DevOps is what we have now and so far its doing us a lot of good.

[wonderplugin_slider id="1"]

You may also enjoy