days
1
1
hours
1
8
minutes
1
7
seconds
0
7
search
A DevOps transformation is never completely finished

Seven ways to drive your enterprise DevOps transformation

Brian Dawson

From nimble startups to large enterprises, organizations across all industries are actively adopting DevOps practices to gain and maintain a lasting business advantage over their competitors. Making the transition to a DevOps culture can be difficult, however, especially for enterprises.

Compared to smaller companies, enterprises have more complex legacy software delivery processes that involve distributed teams and large, monolithic applications. Enterprises are geared for stability and predictability, which can further hamper the many changes needed to effect 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.

While smaller companies have some inherent advantages in implementing DevOps, it is certainly not impossible for enterprises to make the transformation, indeed many already have. Successful enterprise DevOps transformations share several common characteristics, strategies and techniques. Collectively these enable an organization to break down the transformation into smaller, achievable steps, each of which provides an opportunity to learn, to see incremental improvements and to gradually build momentum.

Here are seven ways to successfully drive your enterprise DevOps transformation.

Get support from the top

DevOps requires management buy-in. If management does not have a firm understanding of how critical CD and DevOps principles are to the business, then the entire undertaking is put at risk.

Although 100% support from top management is vital, it is not necessary to obtain this support from the outset. 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 CD and 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 must-have in the earliest stages, you may never be able to get started. Instead, make a start and keep in mind that ultimately management support must be obtained, and it must be unequivocal.

Establish ownership of the transformation

It is imperative for one group (or center of excellence) within the enterprise to own the 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 unburdened by a critical production schedule. Because this team will help drive adoption across the organization by other teams, selecting a product development team for this work is not optimal. Such a team is unlikely to have the necessary cross-team visibility and commitment needed to propagate changes across an enterprise.

SEE ALSO: David Barnes interview: “DevOps doesn’t take away developers’ jobs”

Over time the need for this team will dissipate as the enterprise standardizes on DevOps practices. So, from the outset, everyone should know that the team itself is temporary, and only exists to initiate and guide the transition – not to continually oversee and manage DevOps practices in the long term.

Start with a pilot or proof-of-concept project

It is difficult to implement wholesale changes across an enterprise. In addition to disrupting schedules and team dynamics, such changes often appear to disregard the needs and opinions of those affected and involve a degree of complexity that can paralyze the entire effort.

For these reasons, it’s a good idea to 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. Then identify or assemble 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:

  • Assess – Evaluate where the team is today, in terms of tools, processes and challenges.
  • Align – Establish shared goals and objectives; determine where the team is going.
  • Write a mission statement – Author a straightforward statement that encapsulates your goals, such as increasing release frequency, improving job satisfaction, working collaboratively, increasing customer satisfaction and so on.
  • Map – Create a high-level plan with objective key performance indicators (KPIs), milestones and specific, achievable goals. For example: “Automate manual QA processes and eliminate redundant processes to reduce QA time by XX% by end of year.”
  • Move – Begin implementing; don’t wait until everyone has expert knowledge of the new approach before getting started.
  • Measure – Continually gauge and monitor progress.

Communicate through 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. Use a shared wiki, dashboard or newsletter to spread the word. Over time the ratio of successes to setbacks will increase, and communication will help build the enthusiasm and excitement needed to tackle even larger challenges later on.

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.

Look for quick wins to transform incrementally

During and after the pilot project, keep an eye out for software delivery processes that can be automated or eliminated for a quick win. Each of these incremental gains for accelerating the software delivery process translates to an incremental gain for the business. 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 rack up successes that provide capital to further drive needed change.

SEE ALSO: The dirty secret about “DevOps culture” — Interview with Paul Reed

Quick wins put wind in the sails of the overall effort. They also enable teams to learn the practices and principles that work best for their organization, and build confidence throughout the organization that a full DevOps transformation is achievable.

Scale across teams

With a successful pilot project and some easy wins in the books, 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 onboarded.

Celebrate loudly and proudly

Success breeds success. 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. Recognition can take many forms; pick one that fits within the cultural norms of your enterprise. A company-wide email touting the achievements of one group may make sense for one organization, while a corporate outing or a CEO’s mention at a quarterly meeting would be better for others. The key points 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.

Arriving at your goal

When working heads-down to drive an enterprise transformation, it can be easy to lose sight of the finish line. How do you know when your organization has arrived? There are several ways, but here are three key indicators that your organization has been transformed:

  • Your teams can deploy software at will. Your organization may not want to automatically deploy new updates to production, but any time a new piece of code is written, the software should be in a release-ready state.
  • You’ve met your KPI goals. Steady improvement is demonstrated by improving KPIs that you’ve been tracking by measuring, measuring and measuring some more.
  • Customers and end-users as well as employees are more satisfied. Use surveys, user feedback forms and other methods to gather qualitative data that complements your quantitative KPI data.

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.

Author

Brian Dawson

Brian is currently a DevOps Evangelist at Cloudbees where he helps the community and customers in implementation of Agile, CI, CD and DevOps practices. Prior to Cloudbees Brian spent 22 plus years as a software professional in multiple domains including QA, Engineering, and Management. Most recently he led an Agile Transformation Consulting practice helping organizations small and large implement CI, CD, and DevOps. Prior to Cloudbees, Brian worked at CollabNet, VA Software, Sony Computer Entertainment, Sega, Namco and Apple. His roots are as a programmer, but while functioning in various other roles he found is primary job has always been gathering and distributing knowledge and using shared solutions to solve unique problems.


Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of