From time to time, you will hear the following two words mentioned together: tools and culture. And that's because DevOps necessitates many changes in the interactions of your team, department, and organization, which no tool in the world can change by itself. You probably know that culture is defined as the interaction between teams, within teams, and each person with others. So this week, I will explain how to foster each of these three different interactions.
Preliminary: Anti-social team members and introverts
Anti-social team members may get their share of work done in a closed setting, but they cannot work with other teammates in a DevOps setting if they do not like to communicate with other people. It is crucial to get these kinds of people warm up to their coworkers and anybody else they may have to talk to as part of their job.
You do not have to make them extroverts, since introverts can talk to people just fine if they have to, which is the critical part - try to avoid making these kinds of people speak to others about vain topics not strictly related to the project. In effect, everybody can be a great communicator about theirs and other people's roles, responsibilities, and accomplishments when the time for each of these things comes.
Interactions between teams
This is what you will see most DevOps books talk about, and this aspect is usually the one which companies who are transitioning to DevOps work on the most to improve, partially because it is the most visible.
Shared Goals
Each team must have a set of common goals to achieve. Of course, you can't make every faction have the same set of goals, but each team needs to envision how the final product is supposed to be like and work towards making that a reality.
Meetings
Representatives from all teams which are part of a project have to attend meetings that decide the project's future, and topics of such meetings should be relevant to all stakeholders. There can't be an entire department staying behind because the subject matter is beyond their obligations. For maximum efficiency, conferences should allow each participant to input what needs to be done or changed.
Since you must organize formal meetings in advance, sometimes the best place to catch everyone at once for discussion is in a hallway or cafeteria!
Deadlines
All teams should follow milestones and targets strictly, and they should make every effort to meet them. A non-streamlined team should not be an excuse for missed deadlines.
Each team should have their timeline augmenting the project's timeline just for setting deadlines on doing specific micro-tasks as part of meeting a milestone. It can be as simple as setting dates on a calendar. However, don't underestimate the power of calendar notes (just make sure everyone is aware of them).
Interaction within teams
While more subtle than interaction across teams, this aspect is more critical to achieving and should be worked on first because when you think about it, there is no "team" if the people in it aren't working together. Then it becomes difficult to talk about "teams working together" without the notion of a team.
Leadership
All teams should have a fluent leader in DevOps concepts and can steer them closer towards their adoption. This person should also be comfortable with doing one-on-ones and group sessions with all their team members and even with members of other teams who consult them about DevOps to get a better understanding of it. In a way, these people become the Subject Matter Experts (SMEs) of DevOps, who everyone in the organization consults.
Manageral Approval
The manager of a team can facilitate the transition to DevOps by approving the switch. Also, even more helpful if their manager's boss or even a director or vice president supports and encourages all the teams under them to shift to DevOps methodology.
Often, upper managers are the make-or-break point for DevOps adoption; their disapproval can kill the entire initiative.
Pilot Projects
Start with a mock pilot project for each team, appropriate to their duties, and have them accomplish it by using DevOps best culture practices and tools. The purpose of this is to sharpen intra-team interaction. Once done for all teams, start a small-to-medium - but not too large that it distracts them from current business processes - sized pilot project where all groups cooperate using the same techniques to complete it to shape the inter-team interaction.
Interactions between each person with others
Lastly, let's talk about how to foster a DevOps mindset within each person individually.
Aligned Responsibilities
Everyone must have a standard set of responsibilities on their shoulders, such as finish the project on time (which become liabilities to all if things go awry). Failure to do this will result in people blaming each other for problems that should be borne by the whole organization collectively.
It also decreases the morale of all teammates involved because they will start to feel that they always get blamed for things that aren't their fault, and results in less communication and interaction among them, making a DevOps work environment impossible to achieve.
Respect & Trust
For a DevOps initiative to be successful, each person must learn to be respectful to their peers. If some people are not respected, they cannot contribute to the project effectively since they will stop most communication, and as a result, the overall project suffers. Everyone must also trust that the rest of the organization is working towards the end goal and is not sabotaging progress in some way because if people don't have this trust, then how one can expect them to put their best effort into it?
The Where's and Why's
A business leader can't just walk in and say, "Alright, we're going to adopt DevOps practices, and we will make the whole division use them," they have to have a reason why they are shifting everybody to DevOps. It's not a good idea to take a smoothly running division and make them use DevOps just for the sake of it, or because Gartner said so. There has to be already a problem in the org that can be solved with DevOps. Otherwise, you are implementing a solution that doesn't have a problem, and then there will be at least one problem resulting from that change; the people under you won't understand why this is necessary. And this a catalyst for inhibiting their progress towards DevOps since they will be resistant to change ("Why do we have to change? Our current model is working just fine.").
Similarly, you have to know which teams to apply DevOps to first and the order to introduce cultural processes and tools. Just like a project needs a timeline and plan, so does a DevOps transition. In fact, you can consider DevOps adoption as another project; don't undertake it if it doesn't meet the business requirements.
Conclusion
DevOps does not work with only tools, but the people who use those tools have to have a culture adapted to DevOps. Inter-team interaction can be facilitated by having shared goals, following deadlines strictly, and involving all teams in joint meetings. In contrast, intra-team interaction starts with having team leaders and DevOps SMEs, approval from upper management for change, and initiating pilot projects. Finally, respect, trust, and shared responsibilities are essential for all individuals who participate in a project that uses DevOps. There must be a reason why to introduce DevOps and where to introduce it first.
Top comments (0)