Taming the Cultural Transformation Beast during DevOps Evolution
At the heart of an organization’s DevOps evolution lies cultural transformation. The ways people within a company think, work and collaborate become vital for the successful adoption and execution of DevOps when a company merges its software development and IT operations teams to improve software quality and accelerate release cycles. However, it’s important to realize cultural transformation is the slowest and the most difficult to achieve, while also requiring a specific focus.
From the get-go, end customers must be figuratively placed at the center of any company’s particular DevOps approach. It’s important to relay that the company is transforming to become more agile to better address customers’ needs, as opposed to today’s industry adopting DevOps or because certain tools and methodologies seem interesting to explore.
With this in mind, here are several key focus areas designed to drive a DevOps mindset into the cultural fabric of an organization.
Embedding DevOps into your company’s culture is critical to a successful adoption and execution
1. Management Sponsorship and Drive
This may sound anti-Agile considering Agile’s complementary tenets to DevOps specific to team empowerment and breaking hierarchies and bureaucracy. However, you do need a personified, strong conviction that serves as the change catalyst along the journey. This conviction can manifest in the following behaviors and expectations:
• The sponsor(s) should have a clear vision on how a DevOps evolution will benefit the organization, its customers, and its employees.
• This vision should then be clearly articulated to all stakeholders.
• The sponsor(s) should be able to demonstrate their personal involvement and motivation to make DevOps adoption successful.
• DevOps adoption, and realization of its benefits, should be a goal that becomes part of performance measurement for sponsors and stakeholders alike.
• DevOps adoption should not be treated as a side initiative that does not disrupt “Business as Usual;” in reality quite the opposite should be anticipated.
2. Inclusiveness and Sense of a ‘Common Goal’
Product management, development and operations teams should have a common mission and goal for the product, release or sprint they are working on. The definition here should be the value delivered to the customer and not the value of code, test results, or individual deployment steps. Including operations roles within a close-working Scrum team benefits this cause by:
a. Bringing in a common view on what a product, release or sprint is intended to deliver.
b. Creating an opportunity to bring forward and address operations needs during the development cycle.
c. Creating a better understanding of mutual expectations and empathy for delivering outcomes that meet customer expectations.
3. Common Tools Environment
A well-integrated, engineering tools platform provides a common workbench for all team members (who are likely also geographically distributed), as well as a common instance of truth for everyone. It’s a powerful mechanism to eliminate ambiguity on “real status” based on hearsay.
4. Common View on Progress
The teams’ collective progress—what has already been achieved and what still needs to be done by when—is another powerful mechanism to bind development and operations teams towards a common goal. In a best case scenario where processes become so mature that an output of a sprint is deployable to production, it becomes imperative to be able to see progress in real time.
5. Open Seating
A former manager of mine used to say only your salary and performance ratings are confidential in a team. Evolution of open seating perhaps has its roots somewhere in this philosophy. It is a topic that draws vehement differences in opinion, especially in certain geographies and cultures. However, it does also provide for open, frequent and “boundary-less” interactions among team members.
6. Identify Non-Agile Mindsets, Make Changes if Necessary
All of us have worked with team members less than willing to change. Fundamentally, there is nothing wrong with differences in perspective and thought—all are welcome as a part of continuous learning and improving culture. The problem starts though when a parallel organization begins operating, which becomes counter-productive for the organization at large. It’s only fair to have constant, formal and informal discussions and mentoring sessions with people who express concern about change. However, if this proves futile, don’t feel shy about moving team members to something different that better aligns with their ideology.
The Big Question: How to Start?
A. Maintain a Charter
Develop a charter that is bold and clearly answers why and when the organization wants to adopt DevOps. The charter should also articulate what the transformed state may look like, as well as address benefits for the customer, the organization and its employees.
B. Form an Evangelist DevOps Team
While the perfect end-goal should be a well-formed, integrated development and operations team, it is practical to start with a small evangelist team of “DevOps engineers” that can bridge the two teams. It should be known upfront that the evangelist team can expect to have a short lifespan.
C. Invest in Training
The topic of cultural transformation is so wide and varied that there is nothing better than continuously learning from different, practical experiences.
D. Identify a Pilot
Identify a pilot project that already has a strong process and engineering orientation, led by a team with the capability and willingness to change. Learnings, successes and benefits gleaned from a pilot will encourage stakeholders and other teams to learn and adopt DevOps.
Embedding DevOps into your company’s culture is critical to a successful adoption and execution. The approach relies on each member of the team sharing the same mindset in all facets of their work. While the transition can be cumbersome, a clear-cut plan, driven by a broader transformation vision, and backed by a continuous improvement mindset, can set the right stage for such a journey—easing the pain and ultimately leading to improved software quality and accelerated release cycles.