The cover of the 2017 State of DevOps Report.

Last month was published the 2017 State of DevOps Report, an annualy published study by Puppet and DORA (DevOps Research & Assessment). This report is a must read for anyone, whatever its maturity in DevOps adoption.

The numbers are astonishing per se. DevOps works, high-performing teams compared to low-performing teams:

  • Deploy more and faster
    • 46 times more frequent code deployments
    • 440 times faster lead time from commit to deploy
  • Fail less and recover faster
    • 96 times faster mean time to recover (MTTR) from downtime
    • 5 times lower failure rate
  • Automate more
    • 33% more of their configuration management
    • 27% more of their testing
    • 30% more of their deployments
    • 27% more of their change approval processes
  • Are 2 times more likely to achieve objectives

And here comes my three highlights.

Maturity model and continuous improvement

My first highlight is not about the numbers or a key finding. It’s about their maturity model. They classify low, medium and high performers using a data-driven approach. The classification is a result of the yearly IT performance assessment, which prevents teams and organizations from falling into a “sucess trap”: after achieving the desired performance level, continuous improvement hangs, as the goal was a static one.

This DevOps maturity model is a moving target, not a static one and it’s truly aligned with Lean’s continuous improvement principle. High-peforming teams and innovative organizations knows that this is the key to excellence.

Architecture

The second highlight goes to architecture. From the report:

In teams with strong IT and organizational performance, the architecture of the system is designed so delivery teams can test, deploy and change their systems without depending on other teams for additional work, resources, or approvals, and with less back-and-forth communication. Therefore, we describe both the architecture and the teams as being loosely coupled.

And goes on:

Architectural approaches that enable this strategy include the use of bounded contexts and APIs as a way to decouple large domains, resulting in smaller, more loosely coupled units. The architecture should also enable the use of test doubles and virtualization to test services or components in isolation. Service-oriented architectures are supposed to enable these outcomes, as should any true microservices architecture.

It is not a surprise that Bounded Contexts from Domain-Driven Design (DDD) is listed as an architectural approach that supports these high-performing teams. For me, DDD should be part of your toolset in your DevOps adoption1.

It also supports naturally a microservices architecture. Sam Newman states, in his Building Microservices book (he is also a reviewer of this report), that Bounded Context is a way to model microservices with high cohesion and low coupling.

Sam Newman’s coverage of Bounded Context is too shallow. I recommend reading one of the Vaughn Vernon’s books for the right treatment on the subject.

Leadership

The characteristics of transformational leadership are highly correlated with IT performance. In fact, we observed significant differences in leadership characteristics between high-, medium- and low-performing IT teams. High-performing teams reported having leaders with the strongest behaviors across all dimensions: vision, inspirational communication, intellectual stimulation, supportive leadership, and personal recognition. In contrast, low-performing teams reported the lowest levels of these leadership characteristics. The differences we found were all at statistically significant levels.

You can’t underestimate how a bad leadership can undermine the performance of a team. I have the principle that everybody wants to do a good job, but managing people is hard. And software development is a techno-human effort, and without the human part, you don’t get the technological one.

What I hear from people are the same horror stories: managers who just use Agile as a moniker for a perpetual rush to throw code to production, disregarding quality, without slack to enable continuous improvement and a complete alienation of the development teams, which are just code monkeys. Unhappy people, crap code and slow delivery cycles.

The last four dimensions can be mapped directly to Daniel Pink’s three elements of motivation. If you aren’t prepared to work on people’s motivation or you don’t mind about the subject, make a favor to everyone: quit your job.

Closing remarks

The report is a quick, simple and insightful reading. DevOps, which started as a cultural movement, is now something bigger, highly publicized and moving on the hype cycle’s path. The report reminds us to focus on the results and emphasizes the technical practices.

As a side note, I really liked the graphic design of the report, which shows an interesting diversity on genre, color and ethnicity. It seems intentional, and it’s great! The infographic is worth the download too.

References

  1. I could coin the DDDevOps term, but for the greater good, I won’t. ↩