Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

by Nicole Forsgren

improvements in software delivery are possible for every team and in every company, as long as leadership provides consistent support— including time, actions, and resources—demonstrating a true commitment to improvement,

Velocity is designed to be used as a capacity planning tool; for example, it can be used to extrapolate how long it will take the team to complete all the work that has been planned and estimated. However, some managers have also used it as a way to measure team productivity, or even to compare teams. Using velocity as a productivity metric has several flaws.

Queue theory in math tells us that as utilization approaches 100%, lead times approach infinity—in other words, once you get to very high levels of utilization, it takes teams exponentially longer to get anything done.

A successful measure of performance should have two key characteristics. First, it should focus on a global outcome to ensure teams aren’t pitted against each other.

Second, our measure should focus on outcomes not output: it shouldn’t reward people for putting in large amounts of busywork that doesn’t actually help achieve organizational goals.

Lead time is the time it takes to go from a customer making a request to the request being satisfied.

Reducing batch sizes reduces cycle times and variability in flow, accelerates feedback, reduces risk and overhead, improves efficiency, increases motivation and urgency, and reduces costs and schedule growth

we settled on deployment frequency as a proxy for batch size

Traditionally, reliability is measured as time between failures. However, in modem software products and services, which are rapidly changing complex systems, failure is inevitable, so the key question becomes: How quickly can service be restored?

what percentage of changes for the primary application or service they work on either result in degraded service or subsequently require remediation

organizations with better information flow function more effectively.

accident investigations that stop at “human error” are not just bad but dangerous. Human error should, instead, be the start of the investigation. Our goal should be to discover how we could improve information flow so that people have better or more timely information, or to find better tools to help prevent catastrophic failures following apparently mundane operations.

Many Agile adoptions have treated technical practices as secondary compared to the management and team practices that some Agile frameworks emphasize. Our research shows that technical practices play a vital role in achieving these outcomes.

“Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place”

By splitting work up into much smaller chunks that deliver measurable business outcomes quickly for a small part of our target market, we get essential feedback on the work we are doing so that we can course correct.

Computers perform repetitive tasks; people solve problems.

It should be possible to provision our environments and build, test, and deploy our software in a fully automated fashion purely from information stored in version control.

Automated unit and acceptance tests should be run against every commit to version control to give developers fast feedback on their changes.

Developers should be able to run all automated tests on their workstations in order to triage and fix defects.

Testers should be performing exploratory testing continuously against the latest ...

keeping system and application configuration in version control was more highly correlated with software delivery performance than keeping application code in version control. Configuration is normally considered a secondary concern to application code in configuration management, but our research shows that this is a misconception.

successful teams had adequate test data to run their fully automated test suites and could acquire test data for running automated tests on demand.

Teams that did well had fewer than three active branches at any time, their branches had very short lifetimes (less than a day) before being merged into trunk and never had “code freeze” or stabilization periods.

having multiple long-lived branches discourages both refactoring and intrateam communication.

In teams which scored highly on architectural capabilities, little communication is required between delivery teams to get their work done, and the architecture of the system is designed to enable teams to test, deploy, and change their systems without dependencies on other teams. In other words, architecture and teams are loosely coupled. To enable this, we must also ensure delivery teams are cross-functional, with all the skills necessary to design, develop, test, deploy, and operate the system on the same team.

In the case of WIP, we’re not just asking teams whether they are good at limiting their WIP and have processes in place to do so. We’re also asking if their WIP limits make obstacles to higher flow visible, and if teams remove these obstacles through process improvement, leading to improved throughput. WIP limits are no good if they don’t lead to improvements that increase flow.

approval only for high-risk changes was not correlated with software delivery performance. Teams that reported no approval process or used peer review achieved higher software delivery performance.

external approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate.

if a development team isn’t allowed, without authorization from some outside body, to change requirements or specifications in response to what they discover, their ability to innovate is sharply inhibited.

six organizational risk factors that predict burnout (Leiter and Maslach 2008):3 Work overload: job demands exceed human limits. Lack of control: inability to influence decisions that affect your job. Insufficient rewards: insufficient financial, institutional, or social rewards. Breakdown of community: unsupportive workplace environment. Absence of fairness: lack of fairness in decision-making processes. Value conflicts: mismatch in organizational values and the individual’s values.

most organizations try to fix the person and ignore the work environment, even though her research shows that fixing the environment has a higher likelihood of success.

Complex, painful deployments that must be performed outside of business hours contribute to high stress and feelings of lack of control.

People are an organization’s greatest asset—yet so often they’re treated like expendable resources.

requirements are handed down to development teams who must then deliver large stacks of work in batches. In this model, employees feel little control over the products they build and the customer outcomes they create, and little connection to the organizations they work for. This is immensely demotivating for teams and leads to employees feeling emotionally disconnected from their work— and to worse organizational outcomes.

though we often hear stories of DevOps and technology transformation success coming from the grassroots, it is far easier to achieve success when you have leadership support.

Ensure that existing resources are made available and accessible to everyone in the organization. Create space and opportunities for learning and improving.

Establish a dedicated training budget and make sure people know about it. Also, give your staff the latitude to choose training that interests them.

Encourage staff to attend technical conferences at least once a year and summarize what they learned for the entire team.

Set up internal hack days, where cross-functional teams can get together to work on a project.

Encourage teams to organize internal “yak days,” where teams get together to ...

Give staff dedicated time, such as 20% time or several days after a release, to experiment with new tools and technologies. Allocate budget and infrastructure for special projects.

lateral move can be incredibly valuable to both teams. Practitioners bring valuable information about processes and challenges to their new team, and members of the previous team have a natural point person when reaching out to collaborate.

Encourage sharing and innovation by having demo days and forums. This allows teams to share what they have created with each other. This also lets the teams celebrate their work and learn from each other.

(what Lean practitioners call value streams). Each line of business is organized as a tribe delivering a portfolio of related products and services

(for example, the Mortgage Services Tribe). Each tribe is comprised of multiple self-steering teams, called squads, each responsible

Each squad is guided by a product owner, led (in case of IT) by an IT-area lead, and sized accord...

Most squads are cross-functional, consisting of engineers and marketers, collaborating as a single team with a shared...

There are also chapters, comprised of members of the same discipline (for example, the Data Analytics Chapter), who are matrixed across squads and bring specialized knowledge to promote learning and advancement among squad members.

And finally, there are centers of expertise, bringing together individuals with particular capabilities (for example, communications or enterprise architects

During the stand-ups, problems are not solved, but there is a routine in place to ensure they are rapidly resolved. If the problem requires collaboration with another squad member, it is noted, and those members will discuss it later in the day. If the problem requires IT-area lead support to resolve, the problem is noted and escalated. The IT-area lead may resolve it quickly, or take it to her/his stand-up to raise it with other IT-area leads or tribe leads to resolve. Once resolved, that information is rapidly relayed back through the channel. The problem remains visualized until it is resolved. Similarly, if the problem is technical in nature, it will be shared with the appropriate chapter or center of expertise.