Six Ways to Drive Your DevOps Transformation

From nimble startups to large enterprises, organizations across all industries are actively adopting and implementing DevOps practices to gain and maintain a lasting business advantage over their competitors. Making the transition to a DevOps culture is no easy feat, especially when comparing large enterprises to smaller companies.

Enterprises with more complex legacy software delivery processes that involve distributed teams and large, monolithic applications are geared for stability and predictability, which can further hamper the many changes needed to affect a DevOps transformation. Startups and other small companies, meanwhile, are typically free of the technical debt of legacy software and heavyweight processes, enabling them to rapidly apply new technologies to solve old problems in more modern, agile ways.

As markets evolve rapidly, the combination of cloud-based, instant-on resources and proliferation of continuous delivery (CD) and DevOps practices are enabling these smaller companies to compete head-to-head with organizations many times their size - and come out on top. That being said, large enterprises certainly can, and should, make the DevOps transformation if they haven’t already. Successful enterprise DevOps transformations share several common characteristics, strategies and techniques which enable an organization to break down the transformation into smaller, achievable steps.

Here are six ways to drive your enterprise DevOps transformation.

1. Get support from the top

DevOps requires management buy-in. While 100% buy-in from upper management is vital, it is not necessary to begin the adoption process. What is necessary, is that management is made aware early and often of the DevOps efforts and the resulting success, leading to a firm understanding of how valuable CD and DevOps are to the business. If not, then the entire undertaking is put at risk.

In practice, an organization may need a grassroots effort and a few early successes to secure management buy-in. Often, all it takes to demonstrate the value of DevOps is a single proof-of-concept project completed by a group with the flexibility and desire to innovate. If you view management support as a must-have in the earliest stages, you may never start. Instead, get going understanding that ultimately management support must be obtained.

2. Start with a pilot or proof-of-concept project

Start small and gradually gain acceptance. Keep in mind that it’s difficult to implement wholesale changes across an enterprise. In addition to disrupting schedules and team dynamics, such changes often forgo input from the those required to implement and fail to address their needs.  This approach also involves a degree of complexity that can paralyze the entire effort.  

For these reasons, take an incremental approach to implementing DevOps practices rather than a big bang approach. Successful organizations recognize that sweeping changes may be prohibitively difficult, and opt instead for incremental changes that enable teams to learn empirically what works best for them.

The preferable way to start is with a pilot project that implements and proves CD and DevOps concepts. Look for one that is relatively low risk and high reward and set clear goals for the expected outcome. Then, identify a team of cross-functional production personnel to establish and test the tools infrastructure, process, and culture needed for CD and DevOps. With support from the DevOps ownership group, this pilot team should undertake the following tasks:

3. Establish ownership of the transformation

With the plan for the pilot in place and the outline of activities understood it is imperative for one group within the enterprise to ownthe DevOps transformation. This group can be a newly assembled DevOps team, the organization’s tools group or even an existing development team with the necessary cultural and technical attributes to undertake DevOps adoption. Specifically, the group should be capable, innovative, collaborative and not bound by a critical production schedule.

Over time the need for this team will dissipate as the enterprise standardizes on DevOps practices and is more widespread. So, from the outset, communicate that the team itself is temporary and only exists to initiate and guide the transition. 

4. Communicate setbacks and successes

Throughout the pilot project, make an extra effort to identify and capture both setbacks and successes. Capture what the team learns and communicate this new knowledge openly and transparently not only with the team, but with the organization as a whole. Make the effort to share not only quantitative metrics such as KPIs, but also more qualitative results and observations. For example, updates might mention new additions to the team, parts of the process that have been automated or new tools that have been adopted.

Over time the ratio of successes to setbacks will increase and consistent communication will help build the enthusiasm and excitement needed to tackle even larger challenges later on. This will also lead to other’s asking how to achieve the same results, and enable best practices to be shared by teams “pulling” innovation in vs “pushing” change on the teams.

5. Continue to transform Incrementally and celebrate success

During and after the pilot project, keep an eye out for software delivery processes that can be automated or eliminated for a quick win. Keep in mind that success breeds success

A DevOps transformation cannot and does not happen all at once; rather it’s a series of ongoing, incremental improvements. Aligned with the agile development mindset, prioritizing incremental change enables an organization to make progress as it builds knowledge, and racks up successes that provide capital to further drive needed change.

Make sure to recognize and reward teams that consistently achieve their goals. Teams that see their coworkers being successful will soon want to make their own transition to CD and DevOps practices. The key points in acknowledging these wins are to ensure that teams that put in the work get the recognition that they deserve, and that the entire organization sees those teams being celebrated.

6. Scale across teams

With a successful pilot project and some wins in the book, the next step is to begin onboarding other development teams. As with the rest of the transformation, this process of scaling across teams is best done incrementally. As individual teams are trained and brought into the CD and DevOps fold, continue to make improvements to the tools, process and culture based on each new team’s needs as well as new insights gained from teams that have already been on boarded.

Finally, it’s important to note that a DevOps transformation is never completely finished. There are always steps you can take to further accelerate processes, improve automation and shorten time to market – even after your enterprise has fully achieved its original DevOps goals.

Brian Dawson is a DevOps Practitioner with CloudBees