29 May 2019
The State of DevOps Report is an annual report that uses a statistical analysis of survey data to determine effective practices for software delivery organizations. Its principal authors are Nicole Forsgren, Jez Humble, and Gene Kim.
The report is based on surveys of tens of thousands of professional software developers. The survey consists of questions designed to identify components of a construct - something that can't be measured directly, such as organizational culture. In this case the constructs represent capabilities of a software delivery organization  such as practices (continuous integration) and environmental factors (team culture). For each construct survey questions are designed to identify these indirectly, so they don't ask "do you do continuous integration" (which we know would give very unreliable answers), but instead ask for concrete things that are part of CI (eg "does everyone push to a shared mainline daily"). They then use a variety of statistical techniques to test if the questions in fact measure the underlying concept. Further analysis can then test hypothesis about how these constructs link together.
One of the most striking results from this survey is how teams cluster into four standards of software delivery performance (elite, high, medium, and low). Elite performers deploy many times a day, taking under an hour to take a change completed by a developer into production. Low performers, in contrast, take months to deploy a change into production. This high throughput does not come at the cost of system stability, since elite teams have a change failure rate of less than 15% (compared to 46-60% for low performance teams) and can recover from a failure in minutes rather than weeks.
The best place to start reading more about this is the 2018 State of DevOps Report, which is freely available. For more depth on the results and the techniques used to discover them, I strongly recommend their book Accelerate.
1: Software delivery is the process from when a developer completes work on a change to a software system, to when that change is deployed in production. It doesn't include figuring what changes are required and how the development team works on the change until it is done within the development environment.