Tag: DevOps

The hardest part of transforming to a lean, efficient process is the culture change necessary to get a team to work together. It doesn’t matter if the team builds software or vehicles, the change to working in a new way, into disclosing problems, admitting issues, working without blame to fix them, these are very, very difficult changes to make.

Dr. Edward Deming and his work with the Japanese have been the source of many ideas on how to improve a manufacturing process and increase quality. The ideas and principles are incorporated into The Goal, a novel that inspired The Phoenix Project. I recommend both those books for people interested in DevOps because building software is very similar to the manufacturing process used for other goods.

Toyota has been one of the leaders of quality manufacturing and the Toyota Production System has been used as a model and adapted by many industries, including software. One of the ideas used in manufacturing is the ability of anyone to highlight potential problems. In car plants, this has been implemented with an andon cord, a way to stop production and have others help diagnose and solve a problem early in the process.

Some have thought this is a culture issue where the Japanese might be more willing to highlight problems and work as a team, something that many Westerners have struggled to do. At the lean blog, they talk about how this isn’t the case. In fact, the Japanese, in general, seek harmony and might be less likely to raise potential issues. In fact, I think most workers are hesitant to raise potential issues, for a variety of reasons. Often anything that slows down work is frowned upon by management, which often leads to issues lingering on, or substandard products being produced. This also happens in software.

I might argue that changing culture for developers is hard, but even harder for managers. We often don’t train managers well, and certainly we don’t often have good systems for coordinating work between and among knowledge workers. The systems that help with manufacturing give us a base, but they don’t apply quite the same way when your “machinery” is another human. Culture change for DevOps must include management and that means less oversight and interruptions, blameless reviews, and embracing mistakes and small failures. Those are often very hard for managers but necessary if you want to improve your software.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

It seems like just a few weeks ago that I went over the 2018 results with Gene Kim. That was an exciting few weeks for me, running over the report in prep and then having the opportunity to host a webinar with Gene Kim. Exciting times, but it’s been almost a year and the 2019 report is out. You can download the 2019 Accelerate: State of DevOps Report from the DORA site and read it yourself, but I found a couple interesting things in the report.

As expected, companies adopting DevOps are outperforming those that don’t, at least in the metrics measured. In fact, it appears that the high performers continue to outperform low performers in two major ways: speed and stability. What’s interesting, and as was pointed out by Kendra, is that these aren’t on the same scale, meaning there isn’t a trade-off between the two metrics.

You can move fast and achieve higher stability. In fact, moving fast can lead to higher stability if you are learning and growing from your efforts to build and deploy software. This includes the database, though that’s not called out in this year’s report. Instead, the report talks about ways to achieve speed and stability.

One of those is tools, and more importantly, easy to use tools. Staff will turnover or change positions. Knowledge can be hard to share in busy environments, so tooling is important. Bespoke, bought, homegrown, open-source, it’s important that the tooling is easy to understand and that it performs at some job in an efficient manner.

There are other items in the report, but one thing I think we often ignore is that sticking with your old process and people doesn’t mean you’ll fail. You clearly have some people and process in place that works, as you’re in business now.

However.

Both speed and stability help you work more efficiently. They help you compete better against others, and should ensure you reach your goals sooner. Speed increases value for customers, which in turn should help you improve how your organization functions. Stability makes both customers and staff happy. One thing the report points out: productivity has a positive impact on workers. They deal with stress better and burnout less.

Happier employees are hopefully helping your organization with more creativity in solving problems, more engagement with customers’ success, and less turnover. DevOps is better for your software, and your staff.

If you want to learn more, I’m hosting a webinar next week with Jez Humble to go over the report.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.