Collaboration in DevOps

Collaboration in DevOps:

Small increments of Deliveries in DevOps was explained in detail in our previous tutorial.

We know that the key mantra of DevOps is collaboration and hence the word DevOps arrived.

                      Read Through => In-Depth DevOps Tutorials

Collaboration is to come together as a single team to address any problem in the program, which hinders the program goalkeeping customer focus in mind and solve them by owning them as their own problem as quickly as possible, without any blame game. 

Collaboration teaches everyone to talk to each other, meet each other face to face, involve each other in their meetings, discussions, understand each other’s tasks, dependency and have transparency in work and work proactively to prevent the problems.

VIDEO Part 2 Block 5: Collaboration – 15 minutes 36 seconds

Transcript:

The term collaboration is been repeated again and again in DevOps and the Devops mantra is collaboration. So, let us understand what ‘collaboration’ really means in the software development and DevOps context.

According to me, as soon as an organization says, we are implementing DevOps, automatically the thinking of collaboration which is attached to devops practice kicks off in everyone’s mind and makes them more focused and alert towards collaboration and they start feeling that they need to collaborate. That’s the magic of collaboration.

So, initiating DevOps collaboration right from the beginning of the project is very essential to the organization and the team. The team I mean, team members of the program.

I’m going to explain a couple of instances where I’ve seen Dev collaborating with Ops and ops collaborating with the dev team so that we will know what actually collaborate means in the DevOps context.

This is the representation of instance one.

There was an instance that there was some unknown problem in the installation script or configuration script that ops team was finding a challenge in installing the software on a particular set up of a cluster in a particular geography.

It was throwing some unknown error and was a pure production problem, which never occurred in dev environment and the operations team really spent a lot of effort in resolving them by themselves thinking that it is something related to the set up, and they need to solve it, which didn’t get resolved for quite a long time.

Then immediately the Dev team pitched in without even being invited to help out, though the time zone was different, it took the control of the production site, you know generally access to the production will not be given to everyone, Ops just shares the error details or any other information that the team needs for debugging purpose.

But this situation is called for giving access to one of the dev team member, who dedicatedly spent few hours in analyzing the issue on the live and provided immediate work around and hence the problem was resolved quickly.

This is the instance of the collaboration where the dev team voluntarily owned the problem and helped the ops team to resolve it. This is a pure instance of collaboration.

Similarly, another instance, let me show that diagrammatically, which I’ve drawn. Another instance is that things were working pretty fine after the software upgrade on a particular site for a few days, all of a sudden the performance of the application started slowing down.

End users started facing severe transactional losses due to this slow down. Lots of complaint calls started coming to CSR’s, I mean, customer service representatives and they, in turn, started following up with the team on the issue.

At this instance, immediately both the Dev and Ops team came together, and with the information and the telemetry details provided by the Ops team to the dev team, they could debug the problem and identify that there was some problem in the load sharing aspect and hence the performance was slow.

So, Both the teams worked together to fix the problem and bring back to normalcy within a few hours. So, here both the Dev and Ops together came forward and collaborated together for solving the issue instead of the Dev saying its Ops problem and Ops thinking that it is Dev’s problem and dev team needs to look at and fix it.

This is the clear instance of collaboration where everyone owns the issues, instead of playing the blame game, irrespective of whose issue it is or wasting time in finding out whose issue it is, keeping in mind that the end user is suffering and the issue needs to be fixed soon.

So, again here, the issue need not be just from the production, it could be any simple in-house software development issue, as simple as the day to day problem, or a design issue, or an architecture issue, or even a simple tool issue.

Any issue related to the program or any issue which the team knows that, is causing damage to the customer or slowing down the program needs to be owned by everyone, instead of isolating the issue that it is development problem or operations problem or testing problem, and contribute to get it addressed as fast as possible, is a collaboration.

So, collaboration in the DevOps context is development and operations coming together and working together to solve the problem as early as possible, keeping the customer focus in mind.

Collaboration is both Dev and Ops owning on what is happening in the live, monitoring and logging and performance checking being on top to solve the issue that occurs especially in production in the interest of the end user.

OR simply, I can say, that the entire team, working constantly together to solve the problem to achieve the program goals, keeping customer focus in mind is the collaboration. I repeat, working constantly together to solve the problems in order to achieve the program goals keeping the customer focus in mind is collaboration.

Then a question arises, how do we develop this collaboration and when do we need to initiate the collaboration amongst the team, who are sitting miles away from each other??

Obviously, we know that both the Dev and Ops cannot co-locate. Ops team needs to be closer to the working site or data centers, and the dev needs to be closer to the software development center. So, how do we achieve the constant collaboration between both the teams??

First of all initiating DevOps collaboration right from the beginning of the project is very essential for the organization and the team. The team I mean here, is the team members of the program.

Practicing a couple of the following things would help in bridging the gap between the team and overcoming the constraint of virtual teams and helps in achieving the collaboration.

So, let’s see which are those practices which help in achieving the collaboration.

Involve Development in all the relevant meetings and discussions of Operations team and vice versa.

This not only brings them together but also helps in understanding each of their work area, their day to day problems and how their work is impacting each other, and what are the critical things that each one should take care of to avoid the issues later and hence brings them closer and initiates a comfortable discussion amongst each other every time.

Before the introduction of the DevOps practice, dev team never used to care anything about delivering the software to Operations. You know they used to be ignorant or never bother about things like infrastructure, configurations, server setups, network configurations, monitoring live performances etc.,

They used to think that all these activities are the responsibilities of the Operations team and the dev team never used to know about it. Earlier the delivery for development team was meaning to be delivery to the Operations team alone, but with the DevOps practice, delivery means to the production and not just to the operations.

Similarly, ops never used to care about the code that the development team was producing. Any issue that they face during software installation, functionality or performance issues in the production, they simply used to pass the buck to the Development team and ask them to fix and give it back.

So, knowing each other’s work and understanding their task and owning each others problem throughout the cycle helps the team to solve the issues quickly.

Because they know where is the issue and what is happening in the program and what is causing the problem in the production and hence can directly go and fix it without much difficulty.

So, collaboration means development team needs to understand infrastructure and configuration and operations team needs to bother about the code, quality, delivery, and timelines.

Understanding the dependency on each other will help in speeding up the work and delivering it on time.

Like during software installation, operations team depends on a development team to resolve any issues related to installation. Similarly, while coding the development team depends on a lot of preconditions that exists in live for the operations team to provide to take care during the coding process.

Another Example is the test team depends on the operations team to provide sample live data from production for testing. Environment configuration details to be set up in the development environment etc.

So, both the team need to collaborate with each other and understand the dependency on each other and provide the data or information on time without causing any delay by keeping in mind about the time zone factor.

Maintain transparency by adopting the DevOps practices like source control or version control which enables the team to understand everything about the program and helps in avoiding any misunderstandings.

So, this is basically maintaining the transparency within the team.

Team members need not have to depend on any individual or any particular piece of information say if someone wants to know the configuration set up at a particular node in the cluster, so they don’t need to wait for the operations team to wake up and provide these details to them, rather they can go to the version control tool and fetch this information and can complete their task without any delay.

Learning from each other especially from the others mistake is the greatest characteristics of collaboration. So that they don’t repeat these mistakes done by someone else already.

So, development is learning from the operation and operations is learning from the development, be it a new technology, tool, or doing something in a simpler and better way. Where in both of them are on the same page and hence they collaborate with each other by learning from each other.

Operations always used to feel that the dev team is very slow and they can not deliver on time, now that they are interacting with the development team on a day to day basis, they understand what is causing the delay, be it less clarity in the requirements, design problem, coding problem or any other tool problem.

Even they are pitching in and providing their valuable suggestions to improve upon.

Also, in case of any issue either from the production or from the development site, DevOps introduces a culture of first fixing the problem than trying to find out who or which team have introduced this issue. And so everyone tries to focus on fixing the problem rather than wasting time in finding out who caused the problem.

So, Stop blaming and considering each one’s issue as their own and coming forward to solve them together and supporting problem, supporting each other during their issues is again a collaboration.

So, I can say, stop blaming game, blame gaming is a characteristic of collaboration once again.

When everyone starts thinking commonly in the same direction, same mindset and working on the same aspects and practices is again a collaboration like whenever some new feature is developed, everyone thinking on how to test this, how to deploy this, how to monitor this, is a collaboration.

So, thinking commonly, within the team is a characteristic of the collaboration once again.

Let us take a break now and understand little more about collaboration in our next video.

PREV Tutorial | NEXT Tutorial