The identity crisis
What I've been noticing, is that where Devops works, the level of organisational change and improvement that arrives, creates such an explosion of greatness, that people are shell shocked and only remember that Devops was the instigator.
Backblow
The negative effect of this, is that people have the word, Devops burned in their brains. The word only. For the few that follow up and try to grasp what changed and how everything got better, since it is a whole practice that needs to be comprehended, a few elements get anchored in the person's mind.
It's no surprise. Human beings are bad witnesses. People remember what they do, for reasons that are all their own. So hence, Devops takes a flavour, depending on the person hearing what it is. It's not unusual or extraordinary, new paradigms are hard to assimilate.
The good and the bad.
So there is a risk: that we have a business decision maker that realizes, rightfully, that they need to get ahead of this curve. But that they have only the faintest clue what it represents.
This is when they reach out for help, but they will probably rely on lessons of the past and proceed to plan bringing Devops in, like a project.
The hypothesis
If, continuous improvement was part of the business, deeply, it would be easy to see or even obvious that it is, yet another change. Just a different way to approach change. But my experience says it is not in a very important way. People are too preoccupied with their day to day activities to consider improving what they do. After all it would start with auto-criticism, and that most criticism, no matter the source, is to be avoided. And of course, we are too busy.
So, what differentiates the endeavors that will win and those that won't or don't, is pretty easy to see as well: change. Innovation, improvements and evolution are all synonyms for change. Those who adapt, improve and evolve are taking a risk, but between risking gaining ground on the competition and falling back on old habits, it seems that the actual risk of failure is pretty small.
As a matter of fact, DevOps requires manageable risk and success scoping. In the Jargon, we call it "Quick Wins". Changes are planned to give the maximum benefit for the smallest risk. And gradually these gains add up. Ans it all comes to a head, when it becomes a way of doing things.
Change is people.
What is more, the limits we set to our roles, often driven by titles are an obstacle to change. Just think how many times you've heard "that's not my job" or "it's not my responsibility". Think of it as a chain. Does it matter which link fails, for the whole thing to be a failure? No. Well projects live and die because of a single fault. And they live and thrive when everyone participates.
If there is a lesson to keep from blockchain, it is that having redundancies in our records and transactions insures a better future for our business. This is also true with human capital.
Individuals care as far as they can see. So proximity, in preoccupations and physical location can be key to improving work relations. We often speak in DevOps about "the wall of confusion". This metaphor for the existence of very different preoccupations in a single organisation is often due to the lack of proximity. If people are to change, they must be able to sense how things are and see how their contributions can make a difference. All of this is very difficult when we are separated or isolated, imaginary isolation or otherwise. This is why DevOps has to be a cultural shift.
Change is Process
On of the things I have great fun is at explaining how processes are supposed to be organic changing and living things. It is impossible to maintain growth and improvement if your processes and your rule-book doesn't adapt with it. Luckily, in IT and in software development, we are used to to keeping the sources of our programs in a repository.
Why is this useful? Well if you are to find a way to track your progress, not only will you need to measure it, but you will need to understand how it happened. You must be able to link changes in your way of doing things and progress made. This requires to have your processes documented and stored somewhere where they can be reviewed. So yet another obstacle to get DevOps adopted is to have visibility and traceability on procedural changes.
And don't even get me started on governance. I am incessantly amazed in organisations that preach holocracy and autonomy but don't clear a path for their teams to accomplish anything.
It's very simple: your entire velocity is dependent on the slowest part of your assembly line, figuratively. So if you have a supplier or an internal service that doesn't adhere to your model and that management doesn't ingrate them to your processes and keeps them apart, you will always be a victim of their preoccupations. We often forget that processes aren't there to make people slaves, but they exist to serve the people that are trying to get things done.
Change is Production
While this is probably the least of the mysterious aspects of DevOps, it has a tendency to overshadow the rest. Automation and integration techniques are no the most prevalent ones, but they often yield impressive results. Thus we are under the impression that we must get a hold of some technological guru, who can DevOptimize all the things, meaning automating and tracking fastidious aspects of software delivery. For technical people, using technical means to solve problems is natural. Creating yet another
Again, we tend to forget that these tools are there to support an existing and sometimes changing process.
Conclusion
We are all a bit victim of our ways or habits. To recognize this allows us to change. And change means to become a bit more permeable and empathetic to other people's preoccupations. In the end we are all trying to succeed together. If we take a moment to look at what and how we change, we can analyze what we do that makes us better. We have so much technology to help us, it behooves us to be judicious in our choices and sensitive to our peers' situation.
No comments:
Post a Comment