Fear? Not If You Use DevOps The Right Way
The whole concept of Development Operations (DevOps) starts off with what do you want to accomplish?
We want to increase the value given to customers. We want our customers to enjoy the things that we’re giving them. So they stay customers so that they’re happy. Eventually, they give us more money, but the goal is to first increase the value to customers.
The one you can’t forget is respect for your people. If I do this by burning out my staff and having this high turnover rate or asking them to do inhumane work schedules or dangerous things, that’s actually still not achieving the goal here.
The goal is to increase value while making sure that your people are being successful, taking care of, and able to work to their maximum. I still want the most out of the people on my team, but I want to do it in a way that makes them feel valued and accomplished effectively.
The question you ask, even with things like software development, is what value are we adding from the customer’s perspective? A huge piece of this is eliminating waste. So, in DevOps, we work systematically to eliminate all non-value-added processes in order to achieve our goal with the least possible effort and waste.
One-piece flow recycle times are important here. The ideal batch size in DevOps is one. It means I go from building it to processing it, to shipping it, and that one team is able to process that. If I have one piece flow, have almost eliminated all the different types of waste. That’s the ultimate goal in DevOps. To apply that sort of one-piece flow to all business operations.
You also want to be shared, continuous learning, incremental improvement. That’s a core part of this is that, not only am I doing continuous learning, but it’s shared. I don’t have a single expert who knows things. I have the organization getting smarter. I have many people growing, learning the right way to do these sorts of things. I’m also eliminating some of the overburden of people. Just eliminating waste is only one part of making DevOps successful. Eliminating the overburden to people, even the equipment, and eliminating some of that unevenness, that lumpiness in production is as important as getting rid of waste. So I want to make sure my people are also being maximized in DevOps.
We have this idea of the theory of constraints. This is about three things:
• Finding bottlenecks,
• Removing those bottlenecks, and
• Recognizing that those things are constraints.
They’re things that are holding up the process. If I don’t improve the bottleneck, there’s no point in improving anything else.
Imagine an IT flow where I decide to make my development even better, and they’re amazing. I give them better tools, I rearrange their workstations, but I’ve done nothing to fix, let’s say, a QA team where things actually bottle up. So in that case, the dev team is working even faster, but my bottleneck is the same. That’s my constraint.
So my goal is to go tackle that constraint. Figure out how to make that better, elevate that, do whatever’s needed to improve the capacity. Because if I don’t fix that, it makes no sense to fix anything elsewhere. So the theory of constraints is a powerful model for actually going to fix the areas that make the most difference.
You can’t buy DevOps. There’s no product that should really be called DevOps. Automating something doesn’t matter if I don’t have the right culture in place. Automation is a big piece of it though.
I need to repeatedly automate activities that are redundant, that are human prone to error, or things that simply add waiting for waste because they’re things done by people that should just be done by automation. Once you have some of the cultural pieces in place, that’s when you can also use some tools to stitch together the core steps of your deployment pipeline.
We can’t take metrics out. This isn’t about a one-way directional flow. It’s about feedback loops. It’s about making sure that;
• I’m measuring progress,
• I’m measuring customer usage,
• I’m measuring things that are going wrong so I can improve that.
Any successful DevOps implementation measures all sorts of things. It has feedback loops between teams, from the technology back to the people who build it, to make sure you’re always able to improve. So again, I’m not just collecting all this data, but I’m learning it by sharing the knowledge.
Finally, for a successful DevOps implementation, the core part is the feedback loop. Creating a culture where people are sharing ideas. Where people say we’re critical. We’re going to swarm on that. We’re going to fix that. We’re going to do things together.
