There are many well and widely known benefits of DevOps, including rapid software delivery, a higher degree of enterprise agility, increased system resilience, and being able to swiftly identify and resolve problems.

But what unexpected benefits have been experienced by organizations that are already down the DevOps path? Kevin Behr, chief science officer at Assemblage Pointe, says that one is the move to continuous improvement. “We’re seeing organizations move to continuous improvement because, as it turns out, the DevOps teams lend themselves very well to continuous improvement and cross-functionality,” he says.

While working with a current enterprise, Behr explains how the company established a continuous improvement IT team in the same spirit as the continuous improvement culture at the automaker Toyota. “The development and operations teams are doing this and they’re solving some really, really crazy problems really quickly. You couple the collaborative mindset of DevOps with continuous improvement and you see stunning results,” he says.

One of those outcomes includes hybrid thinking among collaborating teams. “I witnessed a developer using a checklist the other day. That’s something you never see. Developers are typically all about how many scissors they can run with pointed at their eyes. They are about creativity and danger,” Behr says.

However, after working more closely with the operations teams, the developers tend to start adopting some of the tactics employed by ops teams. “The developer explained how the operations team provided a pre-handoff checklist, because items often were forgotten before release,” Behr says.

The tighter coupling with developers is also changing the perspectives of operation team members. “Operations people typically have this fortification versus resilience mentality. They build big turrets, and they’ll put a big gun down. Now, having worked with more nimble dev teams, they’re wondering how—when the big gun fails—they can react more quickly,” says Behr. “You never often hear ops people talk like that,” he says.

Another surprise is increased security. While some organizations fear that the rapid release cycles and the autonomy within DevOps would derail security efforts, many are experiencing quite the opposite. “I think that existential fear is present in security professionals, as well as a lot of test and QA professionals,” says Gene Kim, founder and former CTO at IT security firm Tripwire, and author of The Visible Ops Handbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. “In observation, however it is the exact opposite. No longer does infosec do the testing work. QA and infosec now will be the consultative authorities to help developers do the testing. They will either write the tools that help increase the quality or help developers write their own tests. We no longer become the bottleneck that people try to figure out how to go around. Instead, we are actively helping them do their daily work. It’s the opposite of preordained failure; it’s active involvement,” says Kim.

Another unexpected outcome that resulted from security becoming more integrated with DevOps is an emphasis on relevant metrics, explains Bill Burns, former director of information security for a U.S.-based major on-demand Internet streaming media provider. “If the security team identifies an important capability or service to build into a new service or product, then, just like other business units, security teams should proactively prepare to present metrics for the risk items they discussed,” he says.

As Burns explains, operations teams see this more clearly as development and operations capabilities merge: the business has an expectation to have key operational metrics available all the time to support decision making. Security is no exception. And having security metrics as part of the same dashboard or review process builds trust and credibility toward the security team. “It also forces the security team to really focus on what the key threats or risks are, how they to measure them, and why the business should care,” says Burns. “This level of relevancy is great, another way for security teams to communicate and work with business units—something every security (should) strives for,” he adds.

The next unexpected benefit—more work for the security team—is both good and bad news, explains Burns. “We’d engage with one team on one particular project, and out of the blue we would get that same person or one of his peers come to us proactively and request our input on other initiatives. Those were exceptional moments for me. You would have a small success with one engagement and you would build trust, and then you find other developers come to you and seek advice. That’s a huge indicator of success right there,”