Merge pull request #706 from dora-team/698-summarize-2016-report

Landing page for the 2016 DORA Report

firebase.json

@@ -106,7 +106,7 @@
                 },
                 {
                     "source": "/dora-report-2016",
-                    "destination": "/research/2017-and-earlier/2016-state-of-devops-report.pdf",
+                    "destination": "/research/2016",
                     "type": 302
                 },
                 {
@@ -227,7 +227,12 @@
                 },
                 {
                     "source": "/publications/pdf/state-of-devops-2016.pdf",
-                    "destination": "/research/2017-and-earlier/2016-state-of-devops-report.pdf",
+                    "destination": "/research/2016/2016-state-of-devops-report.pdf",
+                    "type": 301
+                },
+                {
+                    "source": "/research/2017-and-earlier/2016-state-of-devops-report.pdf",
+                    "destination": "/research/2016/2016-state-of-devops-report.pdf",
                     "type": 301
                 },
                 {

hugo/content/capabilities/continuous-delivery/index.md

@@ -74,7 +74,7 @@ the following benefits:
     as well as higher levels of availability.
 -   Leads to higher levels of quality, measured by the percentage of time
     teams spend on rework or unplanned work (as shown in the
-    [2016 State of DevOps Report](/research/2017-and-earlier/2016-state-of-devops-report.pdf)
+    [2016 State of DevOps Report](/research/2016/2016-state-of-devops-report.pdf)
     pp25-26, and the
     [2018 State of DevOps Report](/research/2018/dora-report/2018-dora-accelerate-state-of-devops-report.pdf)
     pp27-29).

hugo/content/capabilities/continuous-integration/index.md

@@ -126,7 +126,7 @@ general, you don't want to optimize for the speed at which developers can
 declare a large feature as completed on a branch. Rather, you want to be able to
 get changes reviewed, integrated, tested, and deployed as fast as possible. This
 process results in software development and delivery that is
-[faster and more stable](/research/2017-and-earlier/2016-state-of-devops-report.pdf#page=35)
+[faster and more stable](/research/2016/2016-state-of-devops-report.pdf#page=35)
 (PDF) when the changes are small and self-contained, and the branches they live
 on are short-lived. Working in small batches also ensures that developers get
 regular feedback on the impact of their work on the system as a whole—from other

hugo/content/capabilities/customer-feedback/index.md

@@ -29,7 +29,7 @@ When these capabilities are applied together, they help predict the following:
     market share, and productivity.
 
 DevOps Research and Assessment (DORA) research
-[shows](/research/2017-and-earlier/2016-state-of-devops-report.pdf#page=35)
+[shows](/research/2016/2016-state-of-devops-report.pdf#page=35)
 (PDF) that teams achieve higher performance when they work in organizations that
 utilize those capabilities and also do the following:
 

hugo/content/capabilities/pervasive-security/index.md

@@ -12,7 +12,7 @@ summary: |
 ---
 
 Security is everyone's responsibility. The
-[2016 State of DevOps Report](/research/2017-and-earlier/2016-state-of-devops-report.pdf)
+[2016 State of DevOps Report](/research/2016/2016-state-of-devops-report.pdf)
 (PDF) research shows that high-performing teams spend 50 percent less time
 remediating security issues than low-performing teams. By better integrating
 information security (InfoSec) objectives into daily work, teams can achieve
@@ -46,7 +46,7 @@ work with security and testing experts to design and deliver
 throughout the product lifecycle.
 
 Research from
-[DevOps Research and Assessment (DORA)](/research/2017-and-earlier/2016-state-of-devops-report.pdf)
+[DevOps Research and Assessment (DORA)](/research/2016/2016-state-of-devops-report.pdf)
 (PDF) shows that teams can achieve better outcomes by making security a part of
 everyone's daily work instead of testing for security concerns at the end of the
 process. This means integrating security testing and controls into the daily

hugo/content/capabilities/trunk-based-development/index.md

@@ -83,7 +83,7 @@ This is a significant change for developers who aren't used to working in this
 way.
 
 Analysis of DevOps Research and Assessment (DORA) data from
-[2016](/research/2017-and-earlier/2016-state-of-devops-report.pdf#page=31)
+[2016](/research/2016/2016-state-of-devops-report.pdf#page=31)
 (PDF) and
 [2017](/research/2017-and-earlier/2017-state-of-devops-report.pdf#page=40)
 (PDF) shows that teams achieve higher levels of software delivery and operational
@@ -153,7 +153,7 @@ improve trunk-based development:
     [Running builds with GitHub Checks](https://cloud.google.com/build/docs/run-builds-with-github-checks)
     tutorial shows  how to integrate
     [GitHub Checks](https://developer.github.com/v3/checks/)
-    with 
+    with
     [Cloud Build](https://cloud.google.com/build/).
 -   **Have a fast build**. The build and test process should execute in
     [a few minutes](https://www.infoq.com/presentations/Crazy-Fast-Build-Times-or-When-10-Seconds-Starts-to-Make-You-Nervous/).

hugo/content/capabilities/well-being/index.md

@@ -11,7 +11,7 @@ summary: |
     **Deployment pain** is a measure of the fear and anxiety that engineers and technical staff feel when they push code into production.
 
     **Rework** is reactive unplanned work, including any break/fix work, emergency software deployments and patches, responding to urgent audit documentation requests, and so on.
-    
+
     **Burnout** is physical, mental, or emotional exhaustion caused by overwork or stress.
 ---
 
@@ -23,15 +23,15 @@ Deployment pain is a measure of the fear and anxiety that engineers and technica
 Teams can reduce deployment pain by implementing the technical practices that drive [continuous delivery](/capabilities/continuous-delivery). Put another way, the technical practices that improve our ability to deliver software with both speed and stability also reduce the stress and anxiety associated with pushing code into production.
 
 ## Rework
-One measure of whether teams are building quality into their work is the  how they spend their time. Are they able to focus their time devoting effort and energy on developing new features and supporting infrastructure? Or do teams spend most of their time correcting problems, remediating issues, and responding to defects and customer-support work (that is, fixing issues that arise because quality was not built in up front)? We conceptualize this time into two categories. The first category is proactive or new work, in which we are able to design, create, and work on features, tests, and infrastructure in a structured and productive way to create value for our organizations. 
+One measure of whether teams are building quality into their work is the  how they spend their time. Are they able to focus their time devoting effort and energy on developing new features and supporting infrastructure? Or do teams spend most of their time correcting problems, remediating issues, and responding to defects and customer-support work (that is, fixing issues that arise because quality was not built in up front)? We conceptualize this time into two categories. The first category is proactive or new work, in which we are able to design, create, and work on features, tests, and infrastructure in a structured and productive way to create value for our organizations.
 
 
 The second category is called reactive unplanned work, or rework. Unplanned work includes any break/fix work, emergency software deployments and patches, responding to urgent audit documentation requests, and so on. Rework is fixing things that weren't done right the first time and, like change fail rate, is a proxy measure for quality.
-    
-In the [2016 State of DevOps survey](/research/2017-and-earlier/2016-state-of-devops-report.pdf), we asked people about the percentage of time they spent on rework and unplanned work, and on new work such as designing and building new features. High performers reported spending 49 percent of their time on new work and 21 percent on unplanned work or rework. By contrast, low performers spend 38 percent of their time on new work and 27 percent on unplanned work or rework. Thus, high performers spend 29 percent more time on new work than low performers, and 22 percent less time on unplanned work and rework.
-    
+
+In the [2016 State of DevOps survey](/research/2016/2016-state-of-devops-report.pdf), we asked people about the percentage of time they spent on rework and unplanned work, and on new work such as designing and building new features. High performers reported spending 49 percent of their time on new work and 21 percent on unplanned work or rework. By contrast, low performers spend 38 percent of their time on new work and 27 percent on unplanned work or rework. Thus, high performers spend 29 percent more time on new work than low performers, and 22 percent less time on unplanned work and rework.
+
 [Continuous delivery](/capabilities/continuous-delivery) predicts lower levels of unplanned work and rework in a statistically significant way, showing that implementing the technical practices behind continuous delivery drives higher quality.
-    
+
 In the [2018 Accelerate State of DevOps survey](/research/2018/dora-report/2018-dora-accelerate-state-of-devops-report.pdf), we asked our respondents how they spend their time and found that across the board, elite performers are getting the most value-add time out of their days and are spending the least amount of time doing non-value-add work of all groups, followed by high performers and medium performers. Low performers are doing the worst on all dimensions in terms of value-add vs. non-value-add time, as shown in the table below.
 
 <!-- TODO: #323 remove inline styles -->

hugo/content/capabilities/working-in-small-batches/index.md

@@ -136,7 +136,7 @@ When you break down work into small batches, you encounter two pitfalls:
 
 When you slice work into small batches that can be completed in hours, you can
 typically
-[test and deploy those batches to production in less than an hour](/research/2017-and-earlier/2016-state-of-devops-report.pdf)
+[test and deploy those batches to production in less than an hour](/research/2016/2016-state-of-devops-report.pdf)
 (PDF). The key is to decompose the work into small features that allow for rapid
 development, rather than developing complex features on branches and releasing
 them infrequently.

hugo/content/publications/_index.md

@@ -13,13 +13,13 @@ bannerSubtitle: "Findings from DORA's research program are made available throug
 
 <section class="publicationHighlight">
     <aside>
-        <a href="https://cloud.google.com/devops/state-of-devops" target="_blank"><img src="/research/2023/dora-report/2023-dora-accelerate-state-of-devops-report.png" alt="2023 Accelerate State of DevOps Report"></a>
+        <a href="/research/2023/dora-report/" target="_blank"><img src="/research/2023/dora-report/2023-dora-accelerate-state-of-devops-report.png" alt="2023 Accelerate State of DevOps Report"></a>
     </aside>
     <article>
        <p>For the last nine years, we’ve produced the State of DevOps report, hearing from over 36,000 professionals worldwide.</p>
         <p>We’ve outlined the DevOps practices that drive successful software delivery and operational performance, with a deep focus on user-centric design in the 2023 report.</p>
         <p>Use these findings to accelerate organizational performance while reducing burnout.</p>
-       <a href="https://cloud.google.com/devops/state-of-devops" target="_blank"><button class="secondary">Read the Report</button></a>
+       <a href="/research/2023/dora-report/" target="_blank"><button class="secondary">Download the report</button></a>
     </article>
 </section>
 
@@ -46,20 +46,20 @@ bannerSubtitle: "Findings from DORA's research program are made available throug
   (in partnership with Puppet)
   [Read PDF](/research/2017-and-earlier/2017-state-of-devops-report.pdf)
 
-- [![2016 State of DevOps Report](/research/2017-and-earlier/2016-state-of-devops-report.png)](/research/2017-and-earlier/2016-state-of-devops-report.pdf)
-  **[2016 State of DevOps Report](/research/2017-and-earlier/2016-state-of-devops-report.pdf)**
+- [![2016 State of DevOps Report](/research/2016/2016-state-of-devops-report.png)](/research/2016/)
+  **[2016 State of DevOps Report](/research/2016/)**
   (in partnership with Puppet)
-  [Read PDF](/research/2017-and-earlier/2016-state-of-devops-report.pdf)
+  [Download the report](/research/2016/)
 
 - [![2015 State of DevOps Report](/research/2015/2015-state-of-devops-report.png)](/research/2015)
   **[2015 State of DevOps Report](/research/2015)**
   (in partnership with Puppet)
-  [Download the report](/research/2015)
+  [Download the report](/research/2015/)
 
 - [![2014 State of DevOps Report](/research/2014/2014-state-of-devops-report.png)](/research/2014)
   **[2014 State of DevOps Report](/research/2014)**
   (in partnership with Puppet)
-  [Download the report](/research/2014)
+  [Download the report](/research/2014/)
 
 ## Additional Publications
 <!-- add publications as list items, using markdown syntax (list items are designated with a leading dash) -->

hugo/content/research/2016/_index.md

@@ -0,0 +1,25 @@
+---
+title: "DORA Research: 2016"
+date: 2024-07-30
+draft: false
+research_year: "2016"
+type: research_archives
+layout: single
+---
+
+[![2016 State of DevOps Report](/research/2016/2016-state-of-devops-report.png)](2016-state-of-devops-report.pdf)
+
+The 2016 State of DevOps Report reveals that high-performing organizations significantly outperform low performers in terms of IT performance and employee engagement. The report emphasizes benefits of integrating quality into every stage of development. The report also highlights the benefits of an experimental approach to product development, which involves breaking down products into smaller batches, ensuring visibility into the workflow, and actively seeking customer feedback.
+
+The report provides calculations for potential savings and discussing how these savings can be reinvested to foster innovation and drive business value. This work was later expanded in [The ROI of DevOps Transformation](/research/2020/) whitepaper.
+
+The key findings of the report are:
+* High-performing organizations significantly outperform low-performing organizations in terms of throughput, stability, and employee loyalty.
+* High performers deploy code 200 times more frequently than low performers, with 2,555 times faster lead times.
+* High performers have 24 times faster recovery times and three times lower change failure rates than low performers.
+* High performers spend 22% less time on unplanned work and rework, allowing them to spend 29% more time on new work.
+* High performers spend 50% less time remediating security issues than low performers.
+* An experimental approach to product development can improve IT and organizational performance.
+* Technology transformation initiatives can lead to significant cost savings for organizations.
+
+[Download the 2016 State of DevOps Report](2016-state-of-devops-report.pdf)

hugo/content/research/2017-and-earlier/_index.md

@@ -11,6 +11,6 @@ Prior to 2018, research was conducted in partnership with Puppet, as an extensio
 
 #### State of DevOps Reports published in partnership with Puppet:
 - [2017 State of DevOps Report](2017-state-of-devops-report.pdf)
-- [2016 State of DevOps Report](2016-state-of-devops-report.pdf)
+- [2016 State of DevOps Report](/research/2016)
 - [2015 State of DevOps Report](/research/2015)
 - [2014 State of DevOps Report](/research/2014/)

hugo/static/research/content/rework.html

@@ -3,7 +3,7 @@
 
     The second category is called reactive unplanned work, or rework. Unplanned work includes any break/fix work, emergency software deployments and patches, responding to urgent audit documentation requests, and so on. Rework is fixing things that weren't done right the first time and, like change fail rate, is a proxy measure for quality.</p>
 
-    <p>In the <a href="/research/2017-and-earlier/2016-state-of-devops-report.pdf" target="_blank">2016 State of DevOps survey</a>, we asked people about the percentage of time they spent on rework and unplanned work, and on new work such as designing and building new features. High performers reported spending 49 percent of their time on new work and 21 percent on unplanned work or rework. By contrast, low performers spend 38 percent of their time on new work and 27 percent on unplanned work or rework. Thus, high performers spend 29 percent more time on new work than low performers, and 22 percent less time on unplanned work and rework.</p>
+    <p>In the <a href="/research/2016/2016-state-of-devops-report.pdf" target="_blank">2016 State of DevOps survey</a>, we asked people about the percentage of time they spent on rework and unplanned work, and on new work such as designing and building new features. High performers reported spending 49 percent of their time on new work and 21 percent on unplanned work or rework. By contrast, low performers spend 38 percent of their time on new work and 27 percent on unplanned work or rework. Thus, high performers spend 29 percent more time on new work than low performers, and 22 percent less time on unplanned work and rework.</p>
 
     <p><a onclick="linkTo('cd');">Continuous delivery</a> predicts lower levels of unplanned work and rework in a statistically significant way, showing that implementing the <a onclick="linkTo('tech-practices');">technical practices</a> behind continuous delivery drives higher quality.</p>