I recently attended the PGA Championship golf tournament in St. Louis, Missouri. In the golf world, this is considered a "Major" event, one of the top four tournaments of the year, along with The Masters, U.S. Open, Open Championship ("British Open" to folks in the United States,) and the PGA Championship. While the professional golfers have tournaments almost every week from January to September, the Majors are considered to be the greatest challenges, on the most difficult courses.
While some people might hear about this event and think, "Ugh, sportsball!," the reality is that golf and business go hand-in-hand. And since IT and business also go hand-in-hand, it’s not unusual to see many IT organizations hosting events around these major championships. Often times these events will involve some amount of discussion about technology trends in the morning, and then the afternoon is spent around golf-related activities.
When Red Hat’s partner World Wide Technology invited us to join them in St. Louis, I was tasked with the challenge of trying to keep a room full of eager golf fans' attention with talk of bits and bytes, when they were thinking about birdies and bogeys.
One trick I’ve learned over the years is that most people won’t remember the majority of things they hear in a talk, but they often remember a few things if they are in the context of their mindset or culture for that moment in time. Maybe it’s an analogy. Maybe it’s a story about their industry or their town. So I challenged myself to explain DevOps, agile software development, and automation in terms and stories that golf fans (and daytime IT professionals) might relate to and maybe remember.
Here’s how I did it. It just might help you explain DevOps, agile, and automation, too.
When we watch the professional golfers on TV, they are playing an individual game. They are the only person hitting shots and they are entirely responsible for their own score. In essence, they are a golfing silo of one. But for many people, especially at outings or charity events, the format is called a "scramble." This allows a group of people to collectively play together, with their combined efforts resulting in a single score.
The format allows each person to attempt to contribute, even if they are only skilled at a certain aspect of the game (e.g. they can make a putt but not hit a long drive).
The scramble format is not unlike what we see happening with companies adopting DevOps practices and culture, with shared goals, blameless post-mortems, and the combination of skills with a single measured result. While the best players may not always love the overhead of a scramble format, the ability to include players of all skill-levels often results in more fun for more people. And in the stressful world of IT, having a little fun is a good thing.
The more I talk to companies in every industry and every geography, the more they say that their business is represented in the market with a digital (software-centric) presence. It’s mobile apps instead of physical stores. It’s analytics-driven recommendations rather than gut assumptions.
And in order to be successful in this new world, the companies need to figure out how to experiment and react to market interactions in faster and more frequent ways. In essence, they need to be able to put new software and features in front of the market and make next-step decisions based on their responses.
This means some ideas will be a hole-in-one, and others will be a slice out-of-bounds. And for those bad ideas or missteps, they would love the concept of a "mulligan." A mulligan is a do-over, a try-again.
The good news is that today’s agile software development environments, combined with powerful technology like containers and Kubernetes, let developers try out new features with a subset of the marketplace without messing up all of what already exists. Sometimes this is called A/B testing, or canary deployments. But in essence, it’s the option of a mulligan for software releases.
[ Why do containers and Kubernetes pair so well? See our related story: How enterprise IT uses Kubernetes. ]
"That’s good!" "It’s inside the leather, pick it up." For most golfers, these types of sayings are a welcome relief on the putting green. You’re left with a short putt and someone in your group trusts you enough to assume that you’d make it 100 percent of the time. In other words, it’s "automatic." That’s a nice feeling, because messing up that short of a short of a shot can not only be embarrassing but also add to your score.
This is very similar to the common, repetitive tasks that we target with automation technologies. Yes, we all know that you know how to provide something manually, you’ve done it hundreds of times. But what if you screw it up this one time, just before leaving for PTO? That would be embarrassing and potentially costly to the company. You need the equivalent to a gimme putt. In many cases, that’s what automation is. Sure, automation can be used for highly complicated tasks as well, but it’s usually best to start with lower-hanging tasks that are the equivalent of that two-inch putt.
I know all of these analogies and comparisons aren’t perfect, and I’m sure some golf purists will tell me that things like Mulligans and Gimme Putts go against the rules of golf. Yes, this is true, but most of you aren’t PGA Tour golfers either. You do want to have fun, make your working environment more efficient, and maybe even help the company’s bottom line.
And if golf is your hobby of choice, maybe a few of these comparisons will help you explain to the management team why adopting things like DevOps, agile, and automation would make a lot of sense – in a language they understand. Or maybe you’ll just be better equipped to explain these concepts to non-techies, which we all have to do more and more. Either way, good luck on the course.
[ Are you a DevOps job seeker or a hiring manager? Get our free eBook: The Ultimate DevOps Hiring Guide. ]
