The DevOps Movement

In the 2000s, cloud infrastructure lowered the barriers for product development teams to provision hardware and deploy software. Traditionally, product development teams owned shipping new features, and operation teams owned stability in production. The development and operations teams had opposing goals that sometimes resulted in frayed relationships, slower throughput, and lower performance.

Breaking out of hardware provisioning bottlenecks dropped the lead time for deploying new software. However, the more rapid pace of change created friction between fast-moving product development teams and operations teams accountable for stability. 

The term “DevOps” was coined by Patrick Debois in 2009. It emerged in companies like Etsy and Netflix and described principles and practices for how some companies reconfigured themselves to take advantage of the new hardware and software provisioning capabilities. The reconfiguration cut across people, process, and tools.

Rather than separating functions between product development and operations teams, DevOps encourages establishment of cross-functional teams that can own the full stream of activities required to get a new idea into production. These teams often include specialized development, operations, and even security capabilities.

Research into these cross-functional teams found that they employ certain DevOps practices when building software. These practices increase safety when making changes to software. Ultimately, the safety allows for teams to continuously deliver small changes to production so they can get feedback from users faster. 

‍

Four key software delivery metrics

These 30+ practices have a causal relationship with four key software delivery metrics that are predictive of company performance.

These key metrics balance throughput and stability and are:

• Delivery Lead Time – Time it takes to go from committed code to successfully running in production
• Deployment Frequency – How frequently a team deploys working software to production
• Time to Restore Service – The average time it takes to restore service during a service outage
• Change Fail Rate – How often deployment failures that require immediate remedy (rollbacks) occur

These delivery metrics can be measured in any software team and they balance the team’s throughput with the stability of the software product. Focus on improving these metrics through deepening a team’s DevOps practices leads to better outcomes and contributes to job satisfaction, which are two aims of the DevOps movement.