Oh c'mon! I know DevOps! (Culture) - Part 3/5

This article might sound like a philosophical one, but think about it in a way that we can relate to our everyday life.  In one way or other we are all part of a culturally transforming organisation that is faced with challenges to change for the better outcome. What on the earth is culture?! Are we talking about the life, where we continue to chat with people on social media but may not even smile at people sitting right next to us. Is this perceived as culture; forget about good or bad for now. Humans are social animals and we are bound by culture and this ‘culture’ is what makes us who we are in  a society. 

Let us take a minute to understand culture here. Culture cannot be misunderstood for a rule that is imposed on an individual or a group of people. Queuing up  to board a train is not a rule set by the government, it is culture that makes a group of people stay organised for quicker outcome for everyone. All the parties involved are happy and more importantly they are aligned to the bigger unsaid plans that the service operator might have set; in this case it is maintaining the schedule. As an individual, we all have a certain habits and characteristic traits that make us lead a life in this society. These habits or nature differ for each one of us, yet as a group of people we have formed a culture, from our analogy, it is about boarding the train by queuing up. Every person in the queue may have a different set of habits and nature that may or may not align with another individual right there. And there you go, culturally everyone's goal is achieved by staying organised that fit for purpose.

DevOps culture in an organisation is very similar to the analogy stated above. There is a difference between the process and the culture of a team. Imposing a rule to be followed is a crude way of defining what can be called as a process. Culture is an individual's responsibility in a team; for example, toxic attitude in the team can be a disaster for the culture. Some organisations ignore the fact that one bully in the team can be catastrophic for the team's culture and long term goals. While this can produce short term gains, like a production fix for the moment, but that bug can do "wonders" and stay as a bug forever, unless the bug is either tamed or streamlined and aligned to fit for purpose. This can be a huge set back given that organisations look for short term gains.

Collaboration (and sharing) is one of the most important aspects of the devops culture. This is not limited to a highly competent individual sharing the knowledge, but also about data and information sharing between the stakeholders, managers, team members, bringing about a high utilisation of "Wikinomics" that can generate the highest desirable outcome. Trust is another value, that would sound like it is easy but can end up being too much to ask given the current dynamics of most of the organisation and teams. Trust and collaboration were the major drivers for a successful team that we built and delivered the devops offerings. We were not bound by any limitation to show the learning from failure. No one plays the victim card; rather the victim was considered the torch bearer to show the way forward.

Buy in from the leadership on the change of culture is one of the key aspects for success of devops. If the top leadership ignores the long term issues, the next leaders, fail to acknowledge them as well and that goes down to members of the team. The outcome is predictable, but with a bad note on how efficient a recipe for devops failure can be made. I like the Devops Kaizen on bad leadership, from John Willis. "There are three types of bad leadership: 1. The ones who you love to hang out with but who don’t have a clue about how bad it is. 2. The leaders who know how bad it is but have an incentive not to change. 3. The leader who, for some unknown or rational reason, doesn’t seem to give a shit."

We as a team back then were in a hurry to package the DevOps offering in the best possible form that can be sold and serviced. The conversation between the team members were really interesting, given that delivering DevOps requires heavy collaboration of Dev and Ops teams. Imagine in 2012, the collaboration patterns when the offering was being built when the maturity level of DevOps was very low and there was hardly any content and guidance around this even in the industry, except for some great books from people like, Gene Kim, Damon Edwards, Jez Humble and Dr. Nicole Forsgren. Team members did not understand each other to various degrees, and I have to admit that it took us time to talk the same language. The majority of us were from Application development side of DevOps and there were few from Operations and they would go into hibernation when everyone else talks and vice-versa. We would relate that to real time scenario of Dev and Ops going on exile separately if they don't understand each other.

We as a team were to follow the vision I had set up for the DevOps offerings, it was critical to keep the diverse team together to attain the goal. It was quite a challenge at times, since they were struggling to understand the end state when we started. I was sure to have been cursed, as they did convey that later and that they had no clue where this was going to end. Most of the steps on developing the offering was done in silos to start with as there were pieces required to be built first and then establish compatibility and then integrate each of the components. Perhaps, there were a full load of process, budgeting and people that I had to follow and manage to make it happen and we were really patient for this to pan out in a good shape. We did some sprinting to get to the maturity where we opened ourselves for others to challenge and we took that in the right spirit to optimise and standardise the offerings. Credit goes to the devops culture we had, that we were able to accomplish the vision set to meet the objectives and goals to make a predictable outcome in the end!

Are you wondering why am I not writing
anything about "Technology" in devops!
End of the day, it is code! Really?
why so or why not?
Wait for the next one...4/5

Interested in my articles, find it here...

Note: I have referred several white papers, applied my common sense and experience in real time implementation of DevOps. Acknowledging all the image credits. Thanks to all the authors. Not calling out specific reference because, there is similar information contained on multiple blog sites. Please PM me, if you deem there is a need for credit.