Driving Improvements in Software Delivery Performance

Elite performers have a lead time for changes of less than 1 hour (from code committed to code successfully running in production).

Elite performers have a deployment frequency of multiple times per day.

Elite performers have an mean time to recover (MTTR) that is less than 1 hour.

Elite performers have a change failure rate between 0-15%.

For all production artifacts, including application code, application configurations, system configurations, and scripts for automating build and configuration of the environment.

The degree to which deployments are fully automated and do not require manual intervention.

Code is regularly checked in, and each check-in triggers a set of quick test to discover serious regressions, which developers fix immediately.

Fewer than three active branches; branches and forks having very short lifetimes (e.g. less than a day); teams rarely or never having "code lock" periods.

Software tests are run automatically (not manually) continuously through the development process.

Test data requires careful maintenance, and test data management is becoming an increasingly important part of automated testing.

Integrating security into the design and testing phases of the software development process is key to driving IT performance.

Software is in a deployable state throughout its lifecycle, and the team prioritize keeping the software in a deployable state over working on new features.

The extent to which a team can test and deploy their applications on demand, without requiring orchestration with other services.

Teams that can choose which tools to use do better as continuous delivery, and, in turn, drive better software development and delivery performance.

Actively and regularly seek customer feedback and incorporate this feedback into the design of products.

Teams should have a good understanding of and visibility into the flow from the business all the way through to customers, including the status of products and features.

Teams should slice work into small pieces that can be completed in a week or less.

Team experimentation is the ability of developers to try out new ideas and create and update specifications during the development process, without requiring approval from outside of the team, which allows them to innovate quickly and create value.

A lightweight change approval process based on peer review (pair programming or intrateam code review) produces superior IT performance than using external change approval boards (CABs).

Use data from application and infrastructure monitoring tools to take action and make business decisions. This goes beyond paging people when things go wrong.

Monitor system health, using threshold and rate-of-change warnings, to enable teams to preemptively detect and mitigate problems.

The use of work-in-progress limits to manage the flow of work is well known in the Lean community. When used effectively, this drives process improvement, increases throughput, and makes constraints visible in the system.

Visual displays, such as dashboards ir internal websites, used to monitor quality and work in progress have been shown to contribute to software delivery performance.

Hallmarks of this measure include good information sharing, high cooperation and trust, bridging between teams, and conscious inquiry.

Is learning, in your culture, considered essential for continued progress? Is learning thought of as a cost or an investment?

Reflects how well teams, which have traditionally been siloed, interact in development, operations, and information security.

This particular measure of job satisfaction is about doing work that is challenging and meaningful, and being empowered to exercise your skills and judgment.

Compromised of five factors: vision, intellectual stimulation, inspirational communication, supportive leadership, and personal recognition.