“There are only two hard things in Computer Science: cache invalidation and naming things.” (Phil Karlton)
Let’s face it, devops is an incredibly bad name for what we are talking about. The origin and the development of devops has been mostly organic, which can cause problems when one tries to specify what something is and isn’t, especially when it comes to ways of thinking and how to approach problems. So, it is natural that something already hazy gives birth to even more haziness, in this case to DevXOps.
What the DevXOps assume, is that the devops is limited to the developers and ops personnel, and if we were to stay in the original idea to get the two, and ONLY the two, talking to each other, it would be absolutely right. For every additional field, there would then be yet another part added to the term and to include everything, the resulting term would be “DevQAUXSec… … Ops”. Whenever there would be only specific set in the team, there would be a different variation of it. Not only would this be impractical, it would also be highly confusing (which the current DevXOps terminology already can be).
Another interpretation is that the X represents what feature is emphasized in the overall process. This just raises more questions than it truly answers:
- why something needs to be emphasized over the others?
- does DevSecOps then mean that security goes above everything else, and quality assurance and user experience do not matter that much?
- is it necessary to use a different term rather than simply (and explicitly) state “devops with emphasis on security”?
- should the approach be changed from one to another, when the emphasis or the theme changes (e.g., from DevSecOps to DevQAOps or DevUXOps)?
The organic evolution of the devops also makes it much more difficult to understand, and it seems people are divided on what it contains and what it doesn’t. The thing is, devops does not really contain anything, but rather guides us to do things better. We need to remember that most of all, it is a way of thinking, a philosophy, and there can never be a product that could be counted, but it is possible to say that we follow the devops principles. But then, how to determine if something is or is not following the devops way of thinking?
Let’s take a look at my definition of devops from https://gofore.com/en/devops-101-pt-1-journey-to-enlightenment/:
“DevOps is an anthropocentric organizational and cultural movement, and a philosophy with a goal of improving organizational and SDO (software delivery and operations) performance, productivity and the quality of the service.”
I have defined devops by what it aims to achieve with two main constraints:
- People are at the center of it
- It is limited to software development
The first constraint aims towards sustainability. The intent is not to gain more by squeezing every possible ounce of will and energy out of employees, just to discard them afterwards. The second constraint limits the methods to the context of software development.
Now, to guide our thinking process, let’s ask some question:
- How can we improve the performance and the productivity…
- …of the organization?
- …of the teams and the individuals?
- How can we ensure the quality of the service or the product as it is perceived…
- …by the end users?
- …by the developers?
From these questions, we can design the following core mind map:
The next step would be to take some higher level aspects (culture, psychological safety, processes, security etc.) that we know to have an effect on the four objectives. By adding those to their right places (at least mostly), we get:
The goal matters
While the mind map is not all-encompassing, it should point out the key points, from which we can move towards the finer details and ask even more questions. In many cases on the performance and productivity side of things, the things to consider are applicable to other industries as well. However, as long as we keep in our minds on the why, we can say that they are part of devops philosophy as well.
A good example of when something belongs or doesn’t to the thought model is the automation. We can teach that it is a good practice to automate everything and that it reduces the amount of repetitive manual work, but alone, creating pipelines or tools is just plain old software automation. When we add the why to it so that we do it in order to leave more time for the developers to be productive, to make it repeatable, to reduce memory load and so on, then we can say it is practicing the devops way of thinking.
As an example, let’s add a few things to the mind map:
- Measurements (not strictly a process though)
- Culture of experimentation
- Culture of trust
- Well-being (see: https://gofore.com/en/devops-101-part-3-psychological-safety-and-recovery/)
- Stress and frustration (negative relation to well-being)
- Continuous Integration and Deployment
Yet again, not an all-encompassing view, but does give the idea how things are related and where everything could belong (notice that there are some shared aspects as well).
So… what now?
So now we can say that devops is everything and nothing. It is a software development-related phenomenon and a way of thinking aimed at being more productive through removal of silos, amongst many other things, while keeping the quality and the humans involved in a key role. The “need” for DevXOps might rise from the organic evolution of devops, the birth of folk models of the devops (more on this in https://gofore.com/en/devops-101-pt-1-journey-to-enlightenment/) and the bad name of it, but in the end, if we keep in mind what kind of problems the devops philosophy tries to solve and in what context, there is little that falls outside of it. This is the source of its inclusiveness. To understand the relations between all the different things, keep in mind the two constraints (anthropocentric phenomenon, software development) and the core questions:
How can we improve the performance and the productivity…
- …of the organization?
- …of the teams and the individuals?
How can we ensure the quality of the service or the product as it is perceived…
- …by the end users?
- …by the developers?
A successful DevOps culture requires a genuine and holistic change in behaviour through people.
In the last ten years in my own role, I have supported changes which have basically entailed the removal of various walls, fences, gaps and barriers blocking the view. When you dare to peek across to the other side, that is an achievement in its own right: “Oh, so that’s what they really do there!” In addition, if a conscious effort is made to engage in dialogue with those working on the other side of the fence instead of just looking, even more can be achieved. Prejudices and uninformed beliefs can be broken down into fragments of knowledge that can be put to use in a work community or organisation in many ways.
Knowledge of what others in your organisation do creates an understanding that in turn creates a foundation for interaction, empathy, and a generally humane approach. These things are elements of psychological security, to which we will return a little later.
Although what DevOps is may ultimately be easy to understand on paper, it may be more difficult to determine how to succeed in it. Most often, we start from a situation where fences between communication gaps and corporation culture have developed over long periods. A functional and productive DevOps requires the following, at least:
- A strong common will at the organisational level that is embraced by all individuals. For DevOps, however, the state of mind cannot be just anything; it must be related to working for customer value. Everything that is done is related in one way or another to making improvements for the benefit of customers. A common will helps in many ways. It can steer debate onto the right track, provide an opportunity to address situations where the common will may not materialise, and everyone knows that the work done is judged against the common will. Fair for everyone, and also pretty simple, right?
- Concrete action at both the individual and organisational level to remove walls, fences, communication gaps and visual barriers. Instead, efforts should be made to create seamless collaboration between software development, administrators and a multi-expert business team, where responsibility for the end result is shared. It’s not just a way of doing things together, of asking others for feedback from time to time. In my experience, leaving things to “asking sometimes, and seeing where it leads”, most of the time leads nowhere. How many fences are there for you to break down, and how high are they?
- Cooperation at its most authentic and intensive. In order to be able to say out loud in a work community that people are in disagreement, or on the other hand to reveal the weaknesses of one’s own work processes to a colleague, people need to be able to feel psychologically secure. When a solid psychological security is experienced in the work community, everyone can dare to be themselves. This creates the best possible basis for learning from others and for more productive work by daring to fail, whether faced with a colleague, supervisor of your own team or CEO. Rapid failure is also well known to be a prerequisite for inspiration and the emergence of new ideas. This is what DevOps also strives for. In the DevOps state of mind, everyone can make their voice heard despite differences, and in the end it is precisely because of these differences that the opinions of others are sought. Everyone’s voice is heard, and everyone’s voice counts. What could be a more effective way to create a sense of belonging, and a desire to succeed?
DevOps is described in several contexts as a culture, and points 1 to 3 above are each building blocks of culture. Culture is defined in various ways, for example as a body of shared attitudes, values, goals, and practices. And in an organisation, culture is embodied in various practices, for instance in recurring rituals such as meetings and gatherings around specific themes, different milestones, rewards, and organisational discourse. If one tried to describe the DevOps-style culture with adjectives, words like open, honest, permissive, self-nurturing, enterprising, imaginative and enthusiastic come to mind.
The first step toward a successful DevOps culture is to recognise and accept that the change needed in organisational culture and collaboration is potentially large, and that achieving it will require both sufficient time and change and a strong will to see the change through to completion.
In my experience, the best possible result in efforts toward any sort of change is achieved whenever it involves all the people who will be affected by it. When you get to be personally involved in defining your own future ways of working, it’s much easier to commit to them – and commitment brings success, always. Have you begun the transition towards people-oriented and productive DevOps work?