Micro Focus is now part of OpenText. Learn more >

You are here

You are here

6 hacks to scale your DevOps success

public://pictures/Christopher-Null-CEO-Null-Media.png
Christopher Null Freelance writer
 

So your team has a few successful apps under its belt, and executives have taken notice. Now they want you to spearhead a DevOps transformation across the enterprise. How do you build upon the processes and philosophies you've honed so the whole organization benefits?

Here are six tips from DevOps practitioners who have been there that can help ensure a successful start.

1. Be ready for resistance

Attempting to replicate the successes of one or two teams on a large scale will meet challenges from the get-go. Executives may be encouraged by the pioneers' transition to DevOps, but they shouldn't underestimate the resistance to change put up by more conservative teams, said John Steven, senior director of security technology and applied research at Software Integrity Group, part of security vendor Synopsys.

"It's easy to get 10% of an organization to do DevOps. But the last 50% will be a significantly greater challenge to convert, even with the demonstrated successes of the early adopters."
John Steven

That's because even though you're a step ahead in taking the initiative to create some wins for the business, you probably look like another silo to the rest of the organization, said Daniel Barker, who is currently leading the technical and cultural transformation for the National Association of Insurance Commissioners.

"This is better than starting with no evidence that this new way of working is more effective, but it looks like the methodology used flies in the face of a DevOps culture. I usually walk through some of the DevOps topologies when this comes up."
Daniel Barker

The upshot is that you are almost guaranteed to encounter cultural conflicts, competing priorities, and a general sense of FUD. Being diplomatic rather than dictatorial in your approach here will better set you up for success.

"When leading transformations, you aren't there to do anything to anyone else," Barker explained. "You're there to help others and guide them. Your best chance at success is as a servant leader." Sometimes you need to make decisions, but you should try to keep those to a minimum.

Instead, push those decisions back to the people doing the work. "They will eventually feel empowered, but first they may feel confused and frustrated. Keep steady and know that it will pass over time," Barker said.

[ See more: DevOps Enterprise Summit 2018 Las Vegas ]

2. Find some allies

When faced with this type of outsider situation, Barker said, he tries to find champions in the areas he needs to change who can help sell the benefits to their respective teams.

These people need to start getting involved in the work, he said. "They need to get training. Many will go out and actively learn with just a little guidance. These folks need to be people that others will listen to and whom they respect."

3. Show, don't tell

Simply telling colleagues you're going to initiate some changes that will make them more efficient and productive likely won't win many hearts. People will generally be resistant to change until they can clearly see the benefits of making that change.

Tesults founder and software engineer Ajeet Dhaliwal suggests showing them what has been achieved in your own projects and why you would never want to return to the old way of doing things.

"Have you reduced QA cycles from one day to two hours, allowing you to release faster at higher frequency? Tell them about it."
Ajeet Dhaliwal

Talk about how they can ship iterations faster, find bugs quickly, and ship a more robust product than before. "Great reporting is a big part of this," said Dhaliwal. "Test results data, build status, performance data, and currently active issues should be easily accessible."

4. Don't expect outcomes; enable them

A common pitfall when scaling DevOps success is treating the outcomes of the initial pilot projects as the definite outcomes for other projects, said Laura Frank Tacho, director of engineering at CloudBees.

No two apps are alike, and there is no path to cookie-cutter DevOps practices that can be shared across many different apps without modifications.

"Treat the initial outcomes as a guide, not a prescription, and give your teams the support and training they need to implement them on their own."
Laura Frank Tacho

5. Welcome failure

As difficult as it is, you need to let failure happen. The National Association of Insurance Commissioners' Barker said he'll often try to guide a team to a particular decision that he thinks will make them the most successful. Sometimes they get close and find an even better answer; other times they completely miss the mark.

“I know from experience that it will end poorly," Barker said. "But I have to let it play out. This can take months, and we may lose valuable time, but the experience they gain and the knowledge they learn are more valuable than the time lost, because they will now be more effective."

"Treat failure as a good thing and a learning opportunity."
—Daniel Barker

6. Ask for help early and often

Rather than waiting until you're in the soup, Barker recommended, reach out to higher-ups as early as possible. Even better, he said, is to reach out to leadership in many areas of the business at the start.

"I thought for a long time that these transformations could occur without executive buy-in, but I was wrong. Some simple transformation can occur within a small set of teams, but just as quickly it can all be wiped out by a single executive wanting something different."
—Daniel Barker

Bringing in DevOps consultants, trainers, and tooling experts can all be helpful, too, he said, but it’s important to strike a balance to ensure employees don't become overwhelmed or discouraged. "It's a good idea to bring in individuals for company-wide talks, executive roundtables or outings, and workshops, so you start developing shared experiences," Barker added. "These can then be referenced far into the future for mutual understanding."

Change happens, slowly

Don’t underestimate the time it will take for cultural change to occur. Even the smoothest transformation can be a protracted process.

Synopsys' Steven says a long game is critical.

"It’s not unreasonable to think that change this dramatic, and all the tool chain and lifecycle changes that underlie it, should take three to five years. Don’t be discouraged by the increase in time required for adoption beyond early adopter teams."
—John Steven

Want to know more about scaling DevOps in the enterprise? The All Day DevOps online conference on October 17 will have over 100 presentations. It's free, and you can watch the sessions after the event as well. For in-person networking you can't beat the DevOps Enterprise Summit, which will be held in Las Vegas from October 22-24.

Keep learning

Read more articles about: App Dev & TestingDevOps