Red Hat’s Chief Agilist on being the ‘reasonable voice’ in DevOps

Why DevOps is never just a box to check – an interview with Red Hat's Jen Krieger.
29 June 2020 | 8 Shares

Red Hat logo and sign on open-source software company office in Silicon Valley. Source: Shutterstock

“All companies are tech companies, we can say it over and over again,” said Red Hat’s Chief Agilist, Jen Krieger.

“Target is a perfect example of that, right? […] if they didn’t have an app, and they didn’t have their technology in their store, they wouldn’t be as competitive as other stores that have that experience.

“And when I look at Red Hat, or I look at any other company that’s in this in any space where they have competitors, being able to deploy or pivot and change the direction or add a feature at a moment’s notice, is what sets you apart from any other company.”

Around four years ago, Jen Krieger was part of a team at the open-source software giant tasked with “getting DevOps right”. Even then, the methodology was something of a “box to be ticked,” but Krieger – already with close to 15 years’ experience in software development behind her – knew successful DevOps could not be considered a prescriptive practice.

DevOps emerged from agile software development, a methodology that itself emerged as a group of developers sought to gain control over the product development lifecycle. Framing the concept in an Agile Manifesto, they wanted to break down the wall between them and the customer, cut out the middleman, and to use that direct line to create and deploy better products faster.

But despite that manifesto being laid down, development processes still snagged on interference from those that didn’t really know what they were doing, and didn’t make time to understand anything about the technical process of how software is made.

What was hoped to be achieved with agile is not different to what DevOps is trying to achieve today, Krieger explained. “It’s literally the same mission. It’s just that I feel like DevOps is the developer and the operations person saying ‘okay, project managers stop trying to co-opt what we’re trying to fix’.”

“DevOps is about getting to the true ‘nuts and bolts’ of software development, and putting power back in the hands of the people who actually own that process and making sure they get what they need, both professionally and from a technology perspective.”

DevOps at Red Hat

Introducing DevOps to Red Hat was, like within any other company or team, no simple task, but one that Krieger and her team achieved through a series of small wins, making processes between departments connected, and “a little bit more streamlined,” and steadily starting the conversation around DevOps methodology throughout the business.

From early goals of making technical debt “feel a little less heavy”, over time, the team built a fully-functional pipeline that deployed code automatically based on container technology: “our division held the keys to putting things into production for other teams that were not inside of it,” Krieger said.

“And so they would toss code over the wall, and test it in a new environment and it would, like nine times out of ten, blow something up, right, because that’s just how it happens.

“But having them all come together to be able to deploy code without having that manual check in place, or that manual deployment in place was a huge success for the company, both from a cultural perspective and also from a technology perspective.”

There’s no ‘right’ way

For many companies today, DevOps has become a buzzword, the checkbox to be ticked, and while the core concept of interdepartmental agility is something no competitive company today “has the luxury of not having,” failure or ineffectiveness comes with the belief that DevOps is a prescribed framework, rather than a process or philosophy tailored to the culture and operations of the individual business – or even the individual developer.

A project manager may “move cards on a collaboration board or put story points on a user’s project and think it amounts to some sort of agile workflow”, Krieger explained, but without doing the hard work of understanding how people interact together, and understanding what was causing them to not interact the way they should, the practice won’t become established, understood or provide a meaningful benefit to the efficiency of the company’s production process – the result can be fatigue.

“The problem is that if you don’t start from that mindset to think differently about how we work, and what we choose to do, you miss a lot of the points of DevOps,” Krieger said. “A lot of shorthand has happened in the industry because of that; ‘you should do Scrum, because it will make you more agile’, when in reality, it actually doesn’t feel very agile if you put it in place in a situation in which it’s not needed.”

Hands can’t be forced in DevOps; project managers must assume the role of ‘servant-leaders’, ensuring how the methodology is implemented suits the nature of the company, its various projects and individuals, and achieves effective and efficient production, and happier, more productive development teams.

That means knowing when, for example, to “put an entire Scrum process on top of the team” when a simple work breakdown schedule will do.

“People adopt these processes without really understanding why they would ever do them,” said Krieger, or worse, they understand ‘the why’ to be that someone told them to do it, yet they aren’t getting any value whatsoever from the process – “and that is dangerous.”

The reasonable voice in agile

As the “reasonable voice in Agile” at Red Hat, Krieger tasks herself with orchestrating a measured approach to agile processes and the techniques the team uses. It’s a non-prescriptive, fluid perspective on the development process: “I’m the one that, when somebody says, you know, ‘hey, we’re having a half an hour standoff’ – asks is that what we should be doing? Or is there some other thing that we could be pursuing to make that a little bit more successful? I’m that voice of reason.”

With Red Hat’s teams distributed and working together across the world, from India to the west coast of the United States, a standup can mean you’re either forcing someone to stay up late or you’re forcing somebody to get up early, Krieger explained: “sometimes having that doesn’t feel like the best way to spend peoples’ time”

When implementing DevOps, leaders must start with what they want their teams to do and how they want them to work together. “It’s not, ‘I want Scrum’, it’s asking ‘are people going to be happier? Are people going to be more capable of getting work done? Are people going to feel a bit more empowered?’”

“I always go back to the one tenet that I feel is most important, which is what are you actually trying to fix or solve – what is the problem that you’re having?”

Faced with ever-mounting pressure to become ‘agile’ and adopt DevOps methodology, companies make a mistake by embracing a prescribed notion of what it looks like without asking the questions whose answers will be unique to the individual outfit and its needs. This forced approach insidiously breeds fatigue in the process and the work of the developer, and that can be more damaging than not employing the approach in the first instance.

Allowing teams to own processes and fix or change them if they’re not working for them, and ensuring they know their value and are trusted, is key to ensuring they don’t slip out of the backdoor – and developers won’t struggle to find work elsewhere. Like the aims the Agile Manifesto set out to achieve, successful DevOps implementation is about putting the power back in the hands of the developers.

“It’s scary to allow teams to fail. But that’s essentially how you have to make it. You have to have to release the control and you have to make sure the team has the ability to make decisions without fear,” said Krieger.

“And then, and then you have to stop saying things like, ‘we’re all going to do the process this same way’ […] I frankly, have never seen value over everybody doing things the same way.

“The only time that I’ve actually seen true transformative change is when people actually own their process and make it good for them. That is when I’ve seen folks actually embrace the whole tenet behind agile and get the value out of it.

“Otherwise, it’s just a box to check.”