What exactly is technical debt? When discussing your organization’s technical debt - and possible changes to it - with various audiences, you need to articulate the key issues in plain terms. Here’s expert advice on how to do that.
How to explain DevOps in plain English
Having trouble boiling DevOps and all it encompasses down to a sound bite? Here are a few simple definitions and analogies that will help explain DevOps, even to non-techies
5. DevOps is a recipe – combining people, process, and automation
Jayne Groll, CEO at DevOps Institute, has a great cooking analogy for explaining DevOps: “DevOps is a recipe that relies on ingredients from three major categories – people, process, and automation,” she says. Most of the ingredients can be adapted from other well-known practices and sources such as Lean, Agile, SRE, CI/CD, ITIL, leadership, culture, and tools. The secret behind DevOps is how these ingredients are blended and in the right proportions (like any good recipe) in order to increase flow and value to the customer.”
6. DevOps teams are like NASCAR racing crews
“When I talk about desired outcomes for a DevOps initiative, I mention NASCAR or F1 racing,” says Chris Short, principal technical marketing manager, cloud platforms, Red Hat, and publisher of the DevOps’ish newsletter. “Crew chiefs for these race teams have one mission: Finish in the best place possible with the resources they have available while overcoming the adversity thrown at them. Race teams don’t think from start to finish; they flip the table to look at the race from the finish line to the beginning. They set a goal, a stretch goal, and then begin working backward from those goals to determine how to get there. Work is delegated to team members during race week to push towards the set of objectives that get to the desired outcome."
“Race teams practice pit stops all week before the race. They are in weight training and cardio programs during the week to keep them physically ready for the grueling conditions of race day. They continually collaborate to address any issue that might come up. Similarly, software teams should practice releases often. If the safety systems are in place and practice runs have been going well, release to production happens more frequently. Speed makes things safer in this mindset,” says Short.
“It’s not about doing the ‘right’ thing,” he adds, “it’s about addressing as many of the things that could keep you from your the desired outcome as possible. Collaborate and adjust based on the real-time feedback you observe. Expect anomalies and work to improve quality so the impact of those anomalies on the goal is minimized. These are the expectations for everyone in a DevOps world.”