You’re listening to the Humans of DevOps podcast, a podcast focused on advancing the humans of DevOps through the S K I L framework. Here’s your host, DevOps Institute, CEO Jayne Groll.

Hi everyone. I’m Jayne Groll, CEO of the DevOps Institute and I want to welcome you to the first episode of our new Humans of DevOps Podcast. I’m particularly excited about this series because it’s part of DevOps Institute’s mission to advance the human elements of DevOps through our S K I L framework. If you want to learn more about DevOps Institute, the SKIL framework, or to leverage other assets available to you as a member of our community, please go to DevOpsInstitute.com join our member community. It’s free.

So I want to kick off this series by sharing my definition of DevOps from the human perspective. And you may ask why human? Well, despite where you live, your role, your gender or other unique characteristics, we’re all human. And so despite what you might read or hear about DevOps, humans, power transformation through process, through automation, authoring, and through a cultural transformation, it’s the human element of DevOps.

That’s often the differentiator that helps organizations achieve their goals and to be able to compete in a disruptive and digital landscape. So as you may know, there are many definitions of DevOps circling the community and most have the same spirit that accelerates the software delivery cycle by trying to move faster and more frequently. And that’s true.

However, one of the reasons the community is still very, very confused about what DevOps is or isn’t, is that the model really doesn’t fit into our expectation of a traditional framework, a traditional method or a traditional practice. There’ve been many, many debates about whether DevOps is a philosophy, a movement, or a framework along the same lines as agile or ITIL, but in truth, it’s not really the same as any of those DevOps is. None of these, it’s a recipe. It’s a recipe for a new paradigm for IT.

I like to call it new IT, and it’s not a one-ingredient recipe. In fact, if you really think about it, there are very, very few one ingredient recipes in the kitchen or in the board room, right? DevOps is a recipe that’s built on a proprietary blend of ingredients from other sources, including some ingredients that are cultural and some ingredients that are procedural and many ingredients that are automated. But like all recipes on its own, DevOps is a name and a cookbook, right?

It doesn’t really have any substance until it’s brought to life through the right combination of its ingredients. And when done well, the DevOps recipe can be very, very powerful. Like all recipes, the most important ingredient is the chef, right? It’s the chef that knows how to bring that recipe to life, that has techniques that has tools that allow the chef to do something really remarkable in the kitchen. And the truth is, the same holds true in the IT department.

You know, interestingly enough, DevOps on its own only offers principles. It offers principles upon which to conceive the ingredients, right? If you’ve read Jean Kim’s book, the Phoenix Project, then you know that the principles of the three ways really in many ways underpins everything that’s associated or given rise to DevOps.

The first way is to increase flow from left to right. The second way is to shorten feedback loops from right to left. And most important of all, the third way is to continuously learn, practice, and experiment. I’m hoping that you can see that the three-ways really serve as the basis for the human interaction with DevOps, right? Increased flow, shorten feedback loops, continuously learn, practice, and experiment. Those are human elements that may be replicated by automation, maybe underpinned by process, but at the end of the day, they are purely 100% human.

So if DevOps is a recipe, what are the ingredients that could go into your proprietary blend? And each organization will have their own proprietary blend? Well, the good news is that is many cases, you probably have a lot of these ingredients on your shelf, whether it’s cultural ingredients, processed ingredient, or automation ingredients.

The recipe starts with, first of all, reorganizing your approach to software delivery. Moving from a project to a product approach. If you’ve not read Mick Kirsten’s book Project to Product I, highly recommend that — and that helps us move from agile, from waterfall development to agile software development and it gives the developers, whether they’re using scrum or scad agile or the like the first step in starting to go smaller, go faster, be iterative and incremental, right? It is the basis upon which everything else is going to happen, right?

What comes out of the scrum team, what comes out of the agile team is really going to kick off everything else that that happens. But it’s not enough, right? We use the term agile in IT to imply agile software development, but in reality, it’s more important to be agile than to do agile. And that’s the next part of the recipe. We have to add processes and practices like continuous integration and continuous delivery. We have to start automating and making testing much more pervasive. Certainly, security has to shift left. And if you’re familiar with DevSecOps, that’s an important ingredient in this recipe as well. And then you add processes from frameworks like ITIL or SRE or cobit or any of the other myriad of IT frameworks that help to control changes that help to build, test, and deploy and hopefully supplement that with automation as well.

You bake this recipe, right? You bake it through the building and the testing so that it’s ready to be deployed through release automation or, or manual, purposes. And the final product is ready for continuous consumption, alright, it comes out of the kitchen ready to be served. And then operational management takes over.

So well in many cases, DevOps kind of pretends to end at deployment. In reality, it is the consumption of that service by your customer. That’s where value is going to be delivered. And that’s where practices like site reliability, engineering, or ITIL or any of the other service management frameworks really become important ingredients in this recipe as well. You know, I have to give you a cautionary warning and that’s that one of the obstacles to making this recipe as successful as it should be, is legacy loyalty. Whether it’s loyalty to a particular platform, it’s loyalty to a framework like ITIL.

It’s loyalty to security practices. Sometimes we’re our own worst enemy. And so legacy loyalty or ingredient loyalty can actually be a constraint in making this recipe come alive. People process and automation in a DevOps environment has to be interoperable. And the interoperability has to be as close to seamless as is possible.

So if there’s a disagreement about an ingredient, whether it’s a tool, whether it’s a platform, whether it’s a framework, whether it’s how a process should be as executed, it’s really important to be open and adaptive in terms of whether that tool or the practice or their process is still relevant. And if it is still relevant, how do you adapt it to either a scaled approach, a smaller or something? That certainly starts to increase flow.

So having talked about all these ingredients from agile and lean and ITIL and SRE and CICD and of course a very healthy dose of automation, the real secret ingredient to any good recipe, particularly the DevOps recipe is the intentional effort to create a kitchen or a culture that empowers the humans to be successful.

As I said from the very beginning, the three ways are human principles, right? It is humans that are going to drive transformation. And so the secret ingredient in the DevOps recipe is a skilled, knowledgeable, innovative human. And so when a human knows how to blend the recipe with not only the right ingredients, but the right proportion of those ingredients, not too much say automation, not too little cultural considerations, then it is the human that actually brings successful transformation.

Many of the human tasks can be replicated through automation. That’s true, right? But it is actually the humans of DevOps that are the secret ingredient in the DevOps recipe. How will you know this recipe is successful, right? How will you know what a successful outcome looks like? What the definition of done and by the way in DevOps there really isn’t a definition of done for DevOps.

While there might be a definition of done for the software, how will you know your recipe is successful? Well, before you start creating this recipe, before you start blending those ingredients and before your goto position is to acquire new open source or enterprise software, I would encourage you to start with the value stream map, right? If you’re not familiar with the value stream map value stream mapping is a very, very powerful a tool that comes out of lean where you map all of the activities that are associated from an idea all the way to value creation for the customer.

So from ideation to value creation and it’s more than a flowchart. It’s not only looking at the time it takes for the activity to occur. It also looks at the time between activities and then, of course, the ultimate goal is to reduce the time while increasing quality.

All along that value stream, the shorter your value stream and the higher your quality, the more successful the value creation will be. So at the end of the day, if you want to understand how your recipe will be successful, first you have to map your value stream and then you have to manage it. If your recipe is on target, then the value stream will become shorter, but the quality of the product will be greater. And so the value stream is a very, very important part of this recipe as well.

So I hope you’re enjoying my analogy that DevOps is a recipe. You know, obviously I’m playing on some words as far as ingredients and recipes and blending and proprietary blends. And I hope that you’ve enjoyed that analogy, but there is some truth there. And I’m really hoping that you don’t see DevOps as a one-ingredient recipe, right?

DevOps is not your silver bullet solution. DevOps is the culmination of everything it has done to date, everything it should be doing in the future, and literally takes all of those ingredients to make them interoperable. So please don’t think of DevOps as being better than ITIL, better than automation, better than CICD, or the same as CICD It’s not better than anything you’ve done before. It is the glue that ties those together so that we can actually start to become a new IT for new age.

So let me leave you with a couple of thoughts. I’m hoping that you take away a couple of key messages, from this podcast. First of all, DevOps is a recipe, It’s not an ingredient. And on its own, it really doesn’t solve anything or have anything really new to offer. It’s a formula. It’s a formula, for blending everything IT has or should be doing to meet modern demands.

The only thing that matters is the value stream. So while there are lots of metrics that are associated with DevOps, it’s really time and quality that are going to be your differentiators. So when you’re starting to look at how do we measure success, you can granulate your way further down, but you really do need to think of time and quality as the only two things that count for everyone. Alright? For everyone.

Stop thinking about what DevOps is, right? Start figuring out how to leverage the benefits that have been proven by many, many case studies. And how are you going to do this for you, for yourself as a professional and for your organization.

Start assessing your ingredients. What ingredients do you have already? What ingredients can you use as is what ingredients do you need to, adapt? Are there APIs between your tools? You know, we’re very much in an API economy. What sort of ingredients do you already have? And then assess your gaps, right?

And I, again, I caution you to avoid legacy loyalties, whether it’s to tools, whether it’s to frameworks or whether it’s to anything else. I’ll also caution you to avoid change fatigue. If you change too many things at once, people, organizations, processes, really don’t have the bandwidth to handle that much. Change that quickly. So as you’re assessing your recipe, as you’re assessing how you’re going to introduce new ways of working, please be very, very aware that human beings only have a certain ceiling of cultural resilience. But a change has to be handled in a very, very conceptual and intentional way.

Human and cultural innovations, including upskilling are the key differentiators. If you’ve listened to any of the presentations from conferences like DevOps enterprise summit, if you’ve attended any, sessions, if you’ve read any case studies, then you know that these organizations are not showcasing their pipelines, right?

They’re not showing all that you all the cool things they did with Kubernetes or Jenkins. What they’re telling you is what they did within their organization. They establish Dojos for immersive learning. They set up squads to make them more, cross-functional. They created internal DevOps days or hackathons or did classroom training or invested in upskilling programs, right? That’s the differentiator between the high performing really elite organizations that are realizing the benefits of DevOps.

So automation is important, but automation underpins everything else. Please do not undervalue the need to upskill people, right? We need to update humans the same way that we update software, right? Avoid the “them and us” mentality, whether it’s them and us on the DevOps security side or them and us on the DevOps versus ITIL versus agile side. It’s not productive. And at the end of the day, it’s not them and us, it’s just them, right?

Or us. Um, so we are all part of them and we are all part of us. And so I hope that you recognize that DevOps is more than just a term. Don’t worry about whether it’s a philosophy, a movement of framework. It is a reality for many organizations that are trying to transform to meet modern demand.

In future episodes of the Humans of DevOps Podcast, we’re going to explore some of these aspects, concepts, and ingredients in more detail. And I really hope to get the help of some of the industry thought leaders, some of the enterprise practitioners, to join me on the podcast so that we can go from theory to reality and get some really good insight in terms of what some of these look like.

So I hope you’ll join me in future episodes of the Humans of DevOps Podcast. So stay tuned. In the meantime, I will encourage you to become a member of DevOps Institute’s global community. You are part of something bigger than yourself and you belong, right? It’s free. So go to www DevOpsinstitute.com. Join us today, optimize the other assets that we have available to you through our S K I L or SKIL framework. So I thank you for listening and look forward doing more of these podcasts in the future.

Thanks for listening to this episode of the Humans of DevOps Podcast. Don’t forget to join our global community to get access to even more great resources like this. Until next time, remember, you are part of something bigger than yourself. You belong.