In my role I get to attend lots of conferences, meet with customers, give talks, and sit on panel discussions where the main topic is DevOps. I can report that while there has been a decline in folks asking, what is DevOps? ...it is a question that still lingers. For many, the conversation has moved on to discussing the challenges others have encountered in their DevOps adaptations.
For me, the fact we are still stuck on this same question is frustrating, so I have tried to take a new angle; Instead of trying to strictly define DevOps, I now describe it. Or, even more recently, I've tried to compare and contrast DevOps to every other tech silver bullet that has come before it.
Faster, Cheaper, and Better
At some point in my career, I came to the realization that we had been cost justifying everything in IT exactly the same way for years. We'd continually ask for some new tool and then explain how it will speed things up and thus save time and money. Then, we'd find how this new toy would improve quality by adding some new capability or becoming a more reliable process compared to the current process. These arguments were often easy to win in my app delivery space by multiplying that saving across the number of Dev or QA folks it would benefit, allowing us to produce large 'benefit' numbers to justify the cost. It's just simple math, right? Ironically, all of this flew in the face of the productivity paradox, which I first heard about from Nicole Forsgren at the DOES 2014 keynote - DevOps and the Botton Line. In short, you can't gain competitive advantage from these investments because your competitor can make the same investments. Therefore, any gains are not sustainable, and instead you're just, 'keeping up.' What I'll add is that many of those investments were being made in isolation, often impacting a narrow set of persona's
People, Process, and Tools
A simple example of the narrowness is as follows: we'd invest in a tool to improve or add a skill to a person that in turn improves a process. Grander efforts would invest in process, like agile, and then go buy the tools and train the people on the skill they needed to affect a broader set of personas. The recurring theme here is that people are all about their skills. Do they have all of the skills needed of the tools or the proces for them to be able to deliver value? Many of these IT investments raised concerns that the current people didn't have the skills needed, so now we need training or we need to hire from the outside. One example is the so many testing tools I've seen that required testers to be coders. After a while, you start to see people as Taylor-istic cogs, that represent a collection of skills which allow them to do their job on some small section of the value stream, intentionally isolated from the rest of the value stream.
DevOps is Culture is People
If you haven't read Lean Enterprise yet, you really should. Even if it is just chapter one, because this chapter talks about a joint venture between GM and Toyota. GM wanted to learn TPS and Toyota needed a foothold in the US due to rising tariffs on imports. GM chose its shuttered Fremont plant, which had been its worst performing plants in terms of quality and number of cars produced along with poor manager and worker relations. Incredibly, Toyota agreed to a requirement to rehire the union leaders from Fremont to lead the workers at this new plant's workforce. All of the union leaders were sent to Toyota City in Japan to learn TPS. In only a few months, this new plant was producing near perfect cars at a lower cost and in higher volumes than the Fremont plant ever had. This seemed to prove that it was the system - and not the people - that contributed to the Fremont's plant poor performance. There are even touching stories from workers about how having a job they took pride in affected their personal lives in positive ways as well.
Taylorism views people as cogs in a machine paid simply to perform their pre planned task quickly. DevOps puts people in a high-trust culture focused on continuous improvement (Kaizen) and provides an environment to explore and learn. It gives people pride in their work instead of telling them what to do and then using carrots and sticks for motivation. In DevOps, people are allowed to figure out the plan for themselves, making them invested in that process and in turn naturally motivated.
DevOps is Holistic
Unlike the isolated investments of the past, DevOps investments are holistic. DevOps doesn't just focus on one person or a small part of the value stream; it instead looks at the end-to-end value stream and all of the people involved. Instead of making our people fit into the tools and processes, we are flipping that around. And maybe that's why the DevOps reports can now show a connection between IT investments and the bottom line, because what we're really investing in is the people and we're empowering them to go improve the process and find the right tools.
