When talking with customer about what DevOps means in practice, there are 3 key elements that I consider incredible important in this discussion:
- Collaboration of People
- Convergence of Process
- Creation and Exploitation of Tools
The audience I speak with are IT professional and they seem to have a clear understanding of the values #2 and #3. After all, handling tools with some kind of process, it’s what most people do every day in IT departments around the World.
However, in terms of handling people (and in DevOps context) we want them not only to cooperate themselves but also, we want them to understand what must be delivered and who we need to please to at the end of the day: The customer, the End User (whoever will benefit from our solution). Ask anyone to do something differently (especially if they are doing the same thing for several years) and you might get a very aggressive reaction and several justifications on why the current process should *not* be changed.. So this particular task seems hard and it might become more close to impossible one.
Before diving into *why* we need to change, let me explain what I mean by “Collaboration of People” in regards to DevOps. It is often understood that DevOps means (Developers & Operations working seamless all together), but that it’s an oversimplification of what must happen. What we’re actually looking for a way to get Developers to learn about Operations procedures, tooling and technologies. Concurrently, we’re looking for ways to teach Administrators (or so called SysAdmins/Ops) to learn about Developers procedures, tooling and technologies. It’s important to understand that Developers won’t become Operation’s experts overnight, nor SysAdmins become Developers overnight due to lack of experience. In essence, we just want them to share each other’s knowledge and concerns, so everyone understands their role in delivering a solution.
Here are some key points regarding what “Collaboration of People” means:
- Culture Paradigm Shift
DevOps imposes a totally new way to work and deliver product/solutions, that we definitely need a new way to do everything. We need everyone involved to leave their comfortable zone and to start learning each other’s capabilities.
- Cross-training of Skills.
In order to speed up the process, some degree of training might be required to bring your team up to speed. In general, the training should be focused on avoiding the gaps of everyone on the team. A good example of that might supply developers with Operations tooling and procedures, so they can get a grasp what an Operation concerns are.
- Collaboration and Involvement of teams across all aspects of design
Most of organizations tend to design around Conway’s Law and silo several departments into a specific task (and that made sense back in the day, because most departments were designed as a production line in a factory). However, in DevOps we need a group of people cooperating in the project inception all the way into production. By working together, we assure a level of cross-capabilities will emerge inside the team.
- Shared Responsibility
Once any solution goes into production, we need this cross-capability team to be in charge of the whole process. The information generated during the production phase can feed the whole team with enough information to improve the solution as fast as possible. Whenever a problem arises, the whole team is responsible for the problem and the solution. Experience shows when a shared responsibility is in place, something magical happens: People stop pointing fingers when a problem arises *AND* the problem goes away much faster (as nobody like to be called on Sunday night).
- The end of the day question: “Is my application driving business value based on the state it is in now ?”
When you work outside of Conway’s Law, one must answer a very fundamental question: “Is my application driving business value ?” or “Is my customer/end user is enjoying my work ?” or “Is the product of my work helping others to fulfill their goals ?”. By working together as cross-capability team, we need to have those questions answered as a team (and not by a Product Manager nor the CEO of your company).
A possible solution
But all of this is easier said than done. Now the question that comes to your mind it is: “How exactly do I do that ? Is it possible to change my current team into a more DevOps oriented ?”
As Kennedy once said: “Change is the law of life. And those who look only to the past or present are certain to miss the future”. In a DevOps context: Change will be the key of your success.
Simon Sinek, who is popular with for his TED Talks, propose an very interesting approach called “The Golden Circle”. This particular approach can help us understand how we align our tastes based on what we believe. If the idea in question aligns with something that we believe, then we immediately make a connection to our experience and we embrace the proposed idea as truth. However, if the idea doesn’t align with our belief, we tend to be suspicious and handle the idea as a Marketing gimmick.
It seems The Golden Circle seems a good model to start your Culture shift, based on what someone believes you need to create inside your organization. By applying some cross-capability training, learning each other’s capabilities and getting the reaction of everyone on the team, might be a good start to see if a transformation might occur.
However, handling computer tooling and handling people are completely different matters. Some people will embrace new changes easily. Others will be suspicious and after much deliberation, they might turn in the right direction. However, I bet a few people would never accept new ideas or new ways to deliver a work.
So the problem that bares in mind it’s should be is why some people refuse to embrace new ideas and how to convince them to work differently.
Well, specific on “why” people do that, I would say it’s a simple matter of a staying in their “comfort zone”. Some people are so comfortable doing the same thing over and over that they become so good at what they do. By doing some different, it means they let go what they know and spend some time learning something totally different. Is it worth it? Well, for those minority maybe they don’t want try something new or maybe they don’t want to see something new that threat they currently know-how.
Consequently, it comes down to what to do to revert those people to a new way of software delivering. Well, it seems there are only 2 options available here:
Option #1: Give every opportunity for those minority to understand what must happen in the organization by reading, learning, mentoring… all possible way to enable them to engage into something new.
…if that doesn’t work:
Option #2: Show him the door because you exhaust all possible options and it’s just wasting time of your team, who wants to see those changes in place.
Organizations today must think how they going to change themselves into a technology delivery maker from now on. Changing tooling and processes seems to be relatively easy compared to changing people’s mind and know-how.
This isn’t the final response on how to change (or to implement a more adequate) culture in order to response to Market changes. I hope it’s a good start to get a discussion and ideas on how to do that and share in the community.
Hope you can join me in this discussion.