Development and Operations are inherently juxtaposed. Development tends to lean toward risky, new development and operations leans toward a more cautious approach with less updates and changes. This dichotomy drives a wedge between Development and Operations. You may be asking yourself how in the world you can accomplish a DevOps implementation if there is this ingrained diversity between the two departments. This article will briefly describe some of the key cultural considerations for implementing DevOps.
Ops as a Player in Dev
First and foremost, implementing DevOps is a cultural change and requires new ways of thinking by the groups in development as well as throughout the organization. Development must begin to include Operations throughout the development process. Every aspect of development should consider how the development they are undertaking will impact the Operations team. If we code this change, how will Operations be effected? Will they receive additional calls? Will the users need assistance in understanding what the change includes? Will the change require additional infrastructure that Operations will need to support?
When reviewing user stories or business requirements, the Development team must always include end-users as well as Operations as a user of the system/features being developed. It is imperative that Development see the Operations organization as having a seat at the table. For every requirement, Development should be reminded “How will this impact Operations?”.
The best practice is to actually bring the Operations team into the Scrum process. Bringing the Ops team into the regular Scrum rituals (i.e. Daily Scrums, Backlog Groomings, etc.) will ensure that Ops has the understanding of why development decided on a particular architectural approach while also having Development understand how Ops will be impacted by the changes made. Most companies, however, do not have the tolerance for this change. The organization may not want to pull Ops from their front-line duties (i.e. phone coverage) or simply may not understand the benefits from having Ops involved throughout the development process.
For those companies, Development should take the lead by having the Operations Team represented in all user story reviews/requirements by constantly considering Operations as having a seat at the table. Every user story/requirement, must include the Operations team as an actor in the process. For example, consider a user story constructed with an Ops support technician as the user: "As a support technician, the system must provide detailed error logs so that I can provide effective triage."
Motivated and Empowered Staff
In addition to always thinking about development from an operational perspective, a DevOps culture is cultivated by empowered and self-motivated teams. This level of empowerment comes from both leadership and individual team members. A top-down approach only does not allow the team to learn and grow from their own experiences. A bottom-up approach only may only be met with resistance, misunderstandings, and overall lack of buy-in.
The Role of Management
From a management perspective, it is imperative that leadership entrust their teams by letting decisions be made where the work is actually performed. Micromanagement will quickly extinguish self-motivation. Communication between management and the teams should be based upon an understanding of the team and how each team member learns and reacts. Forcing face to face interactions with teams that prefer online communications requiring teams to use online communication only when face to face communication is more productive for them will be met with trepidation.
The Role of the Team
Individual team members should be able to take control of their destiny and continually looking to improve the processes and knowledge with others. They must be willing to share their knowledge and not hoard it for fear of becoming disposable. Everyone on the team must be held accountable and should be trusted by their teammates. The moment that trust is broken on a team, the rest of the processes will begin to fail. While failure should be allowed, failure from a lack of trust can cause irreparable damage. Team members must also feel safe to ask lots of questions. The environment and culture should foster new ways of thinking, new approaches to old problems, and self-reflection.
Before embarking to implement DevOps within your company, it is necessary to truly assess the culture. Can you include Ops as a player in the development process? Does your leadership empower your teams? Are your teams self-organized? Are individuals really ready for open and honest communications? For a lot of companies, this is a dramatic cultural shift that can only be accomplished by individuals willing to make the investment in a mindset change.
