I’m old enough to remember the myth of a paperless office. Yet, when I look at my desk today, I see more paper than ever. In fact, studies have shown that “the use of e-mail in an organization causes an average 40 percent increase in paper consumption.”

Is DevOps a similar myth? By now, we all know that unicorns like Facebook, Google, and Amazon can release software within seconds. Yet, many people in the software industry are getting tired of hearing “DevOps” day in and day out. They think that such frequent releases are fine for cloud-native applications — but no more realistic for their large enterprise organizations than the idea of a “paperless office.”

Maybe releasing applications every few seconds won’t be a reality in the foreseeable future for most large enterprises. But what about the ultimate goal of DevOps: releasing better software faster and more reliably? Wouldn’t it be great to release more often — for example, moving from biannual to monthly releases as a first step? Unicorn or not, DevOps principles can help you get there.

I was part of the team leading DevOps adoption across the 12 development teams here at Tricentis. I’ve also had the opportunity to work closely with many Tricentis customers and prospects as they rolled out and scaled DevOps initiatives across their enterprise. Here are some best practices based on these experiences:

1. Get Buy-In From Top Management

You need a sponsor who understands what you’re doing and why. Ideally, this sponsor can lend his or her own management skills as you kick off and drive this initiative.

2. Start Small and Focus on Learning How DevOps Works in Your Environment

I’ve never heard of a “big bang” implementation delivering the expected results. For a pilot, choose a product that’s important — but not so business critical that a few stumbles will immediately impact your bottom line. Expect that you will inevitably stumble in the beginning, and plan accordingly. Like a toddler, you will fall down often as you start to walk, but you will eventually learn by getting back up on your feet again every time.

During the pilot:

• Define clear, attainable goals. Be sure to start with goals you can reach — maybe not “unicorn” goals like releasing every five minutes, but “sparkly horse” goals like releasing monthly instead of every six months.
• Don’t forget about the testers. Testers are the perfect people to link developers with operations. Testers have worked closely with both operations and developers (especially if they’re already working in Agile teams), so they’re uniquely prepared to help you bridge the gap as you foster closer collaboration.

3. Extend to Selected New Teams

After your pilot succeeds and you have a good idea of how DevOps works in your environment, find three or four more top candidates. At this phase, focus on standardizing and optimizing tools and processes to meet the needs of the broader organization. This might involve evolving some of the practices developed by (and for) the initial pilot group.

Tooling becomes critical as you expand adoption. DevOps requires much more than tools, but professional “continuous” tools (build, deploy, test, monitor, and so on) are needed to systematically replace manual processes across multiple teams.

Why is “test” in bold? Because most people think that test automation is sufficient for continuous testing. It is very important to have a stable and reliable automation platform, but it’s not enough to know how to test. Knowing what to test is critical for sustainable success with DevOps. It’s important to have a structured approach for selecting the right test cases to cover your top business risks. Otherwise, you’ll end up with a bloated test suite that’s slow to execute and doesn’t provide a clear insight on whether the application is safe to release. Without this insight, you can’t have automated quality gates checking each release candidate; you will always need a human to interpret the test results and make the go/no-go decision.

4. Take It Enterprise-Wide

Now that you’ve optimized and standardized the process across several teams, you’re ready to roll it out throughout the company (with the help of your executive sponsor, of course).

Maybe you won’t end up as a unicorn — but if you end up faster than the other “horses” in your market, you win the race. And at that point, who cares if you have a pointy horn or not?