The baseball season is in full swing. There are 30 major league teams competing for a playoff spot, but, as I write this, only five of them—or 16.67 percent—qualify as elite performers with a winning percentage over .600.
The number is strikingly similar in DevOps, where, according to one survey, just 17 percent of organizations say they have fully embraced it. Most of the rest have only scattershot teams immersed in DevOps or only recently began adopting it company wide. Fifteen percent are saying, “Wait ’til next year” and have yet to undertake this agile methodology.
In baseball, teams struggle because of weak hitting, lousy pitching, poor defense, inept managing or all of the above. But why do some DevOps initiatives fail, who is at fault and what can be done to right the ship?
Baseball and DevOps: More Similarities Than Differences
Let’s dissect the differences between a DevOps program that hits the ball out of the park with a truly collaborative effort to build, test and release software faster and more reliably, and one that swings and misses.
Is It Understood There’s No “I” in Team?
Most DevOps initiatives fail because they are undertaken by a single practitioner within a single team. This is a strong personality who bulldozes the team to DevOps success, either out of career growth ambitions or genuine belief in DevOps tenets, only to have the team revert to their old ways when the practitioner leaves.
Ironically, many if not most successful DevOps initiatives also begin with a practitioner on a single team. The difference in the latter case is that the leader doesn’t operate in a vacuum but shares lessons and best practices across the organization. They understand that if you are going to do something transformational, you cannot do it in the shadows or within a silo. They consider the long term. They lead by example and demonstrate the way forward to others.
Are the Top Leaders Onboard?
Just as the best baseball teams tend to have smart, supportive, quality-minded owners, the most successful and sustainable DevOps initiatives have top-down leadership support or mandates.
Clear, consistent direction from the C-suite is necessary to motivate and incentivize people across the company and move DevOps initiatives from a patchwork of projects to an organizationwide philosophy.
“Without executive support,” a Forrester report warns, “agile transformation is limited to grassroots initiatives—a very slow and difficult road.”
Are the Danger Signs Recognized?
There are two telltale signs that a companywide program is floundering. One, success is occurring only in a single team. Two, no one outside the team knows much or anything about that success. DevOps can’t grow within an organization if it’s an isolated black box.
Starting DevOps is kind of like an entrepreneurial act. Startups become something bigger when the entrepreneur is successfully able to extend their vision. DevOps is the same: You need to infect other teams with your success. Winning begets winning.
Another indicator of failure is if a company claims to be adopting DevOps but clings to traditionally organized and siloed teams. You can’t have it both ways. DevOps personnel need to be aligned by product, outcome or value stream—not by specialized work function.
Is Success Measured?
How does a baseball team know it’s winning the game if no one is keeping score? Same in DevOps. If you can’t objectively measure success, you don’t know if your program is meeting its goal of accelerating the software life cycle.
Figure out how to measure the value of what is being done and delivered now so you can demonstrate its impact objectively. Examples could be application deployment frequency and time, error rates and mean time to detection.
Is Seeking Outside Help a No-No?
The DevOps community isn’t especially fond of vendors and consultants, but outside experts can bring fresh perspectives. No one tries to cure an infection or solve marriage issues by themselves, and solving DevOps challenges should be no different. Don’t be afraid to ask for help and if you have the budget pay of it.
Can the DevOps Advocates Speak Business Language?
DevOps folks often stumble when pitching for leadership support because they are unable to articulate their proposals in the dollars and cents language that business leaders understand. But if they can talk that way, practitioners may find leaders are much more willing to play ball than they realize.
Is the Blame Game in Fashion?
The biggest mistake organizations can make is bearing the classic IT coat of arms: arms crossed and fingers pointing. Don’t fall into the blaming trap. DevOps, after all, espouses the concept of learning from failure. So instead of pointing fingers, evaluate, consider, learn and move on with the lessons learned.
As legendary New York Yankess manager Casey Stengall said, “All blame is a waste of time. No matter how much fault you find with another, and regardless of how much you blame him, it will not change you.”
Does Failure Breed Success?
Not to sound harsh, but if you start an initiative and it fails, it is your fault. Sure, many company cultures aren’t ready for DevOps, but others are succeeding where you have failed. If your team lost the World Series, another team won it. Why? There is always something that can be done differently. Determine what went wrong, accept responsibility and learn from it.
Do People Bounce Back?
If your initiative wasn’t successful, don’t be discouraged. Pick yourself up and try again. Being a DevOps leader requires courage and persistence. You’ll get ‘em next time.
“Every day is a new opportunity,” Hall of Fame pitcher Bob Feller said. “You can build on yesterday’s success or put its failures behind and start over again.”
