A seasoned DevOps practitioner with experience leading both HP and Macy’s on continuous delivery transformations, Gary Gruver has learned the ins and outs of implementing Agile and DevOps at enterprise scale through the “school of hard knocks.” Now the president of Practical Large Scale Agile, a consulting business designed to help other enterprises navigate similar DevOps journeys, Gruver stepped in front of the crowd at IBM InterConnect last week to offer up some lessons he learned in those processes. His experience provides some valuable advice for executives hoping to avoid pitfalls while leading the charge for DevOps.

Scrum Doesn’t Equal Agile

The scrum methodology may be useful, but Gruver explained that executives must understand that in the enterprise, Scrum does not equal Agile. The problem with leaning solely on Scrum is that it emphasizes teams locally optimizing their work, while the entire organization is still not fundamentally transforming its ability to release code for the highest priority features on a more frequent basis.

“If you don’t scale over time, you’re going to end up with the classic implementation that you see in most enterprises which is a water-Scrum-fall,” he said. “Your teams are sort of doing stand-ups, they’ve got burn-down charts, they’ve got burn-up charts, they’re collaborating and doing all that work. But they’re still trying to deliver plans that were developed a year or 18 months in the future. And then when you integrate your code it is still taking days, maybe weeks, maybe months or even quarters to release code.”

Too Many Hands On The Steering Wheel

Letting teams loose in the organization lead only by Agile coaches and without some executive and management interface to bring things together results in “too many hands on the steering wheel,” Gruver said, explaining the prevailing attitude.

“You’ve got a layer of management between the CFO and the teams and you know what their role in Agile transformation is? ‘Stay out of the way. Don’t bother us, you don’t know anything about coaching teams and you’re in the way,’” Gruver said. “Most Agile transformations completely disengage the management team. If you get this continuous improvement process going at the executive level and they’re engaged in setting objectives, and they’re spending time in the organization working with teams figuring out what’s working and what’s not,  that changes culture.”

Gruver says that executives and the management team should be working as “investigative reporters” looking for impediments to progress and helping to remove them.

Be Realistic About Architecture

It can be discouraging for DevOps champions in the enterprises who take lessons from organizations like Google or Netflix that thrive on the microservices model and then try to apply them within their traditional organization. The problem is that large, legacy organizations often have applications that are “too tightly coupled to the rest of the architecture to be independently developed, deployed and qualified.”

While organizations would do well to decouple these applications to allow for better incremental improvement, that’s not always realistic, Gruver said. This means enterprises will need a lot more coordination effort—led by executive prioritization—to scale DevOps, because “you can’t wait for a complete rearchitecture to fundamentally start improving your business. So you’re going to have to find a pragmatic balance between the two.”

Branches Are Evil

Gruver is a strong proponent for Trunk Based Development and used his executive oversight to set his enterprises on that path to efficiency in spite of strong push-back from the developer ranks.

“Branches are evil, branches are evil, branches are evil. They’re duplication in the process, and especially if you have any manual testing, they’re absolutely going to kill you,” he warned. “Try to avoid them where you can. I get that large, traditional organizations are very dependent on branches and it is going to take you a while to transform that. But every time you see a branch, you should think of it as waste in your system and try to figure out what’s the root cause for having it and how to eliminate that.”

Failing To Set Prioritized Backlog

Gruver advised enterprises that they shouldn’t start their DevOps or Agile transformations without having business managers who manage line of business “What is the business reason for transforming your organization.”

“This is going to be hard. It’s impossible to do everything at once, so you’re going to need to figure out where to start,” he said. “If you don’t have a clear business value for doing this, then it’s going to be hard to get momentum and have the vision for your organization to follow if it doesn’t know what to prioritize first.”