More on this book
Community
Kindle Notes & Highlights
Common traps were stepped in—like trying a top-down mandate to adopt Agile, thinking it was one size fits all, not focusing on measurement (or the right things to measure), leadership behavior not changing, and treating the transformation like a program instead of creating a learning organization (never done).
acknowledging that work is work (don’t have a backlog of features and a backlog of technical debt and a backlog of operational work; instead, have a single backlog because NFRs are features and reducing technical debt improves stability of the product).
The capabilities are classified into five categories: Continuous delivery Architecture Product and process Lean management and monitoring Cultural
Our research collected over 23,000 survey responses from around the world. We heard from over 2,000 unique organizations, from small startups of under five employees to large enterprises with over 10,000 employees. We collected data from startups and cutting-edge internet companies as well as highly regulated industries, such as finance, healthcare, and government. Our data and analysis includes software developed on brand new “greenfield” platforms as well as legacy code maintenance and development.
Some key research questions were: What does it mean to deliver software, and can it be measured? Does software delivery impact organizations? Does culture matter, and how do we measure it? What technical practices appear to be important?
These were some of the research questions: Can we revalidate that software delivery impacts organizational performance? Do technical practices and automation impact software delivery? Do lean management practices impact software delivery? Do technical practices and Lean management practices impact aspects of work that affect our workforce—such as anxiety associated with code deployments and burnout?
These were our research questions: Does the integration of security into software development and delivery help the process or slow it down? Does trunk-based development contribute to better software delivery? Is a Lean approach to product management an important aspect of software development and delivery? Do good technical practices contribute to strong company loyalty?
Our driving research questions in year four were: What architectural practices drive improvements in software delivery performance? How does transformational leadership impact software delivery? Does software delivery impact not-for-profit outcomes?
To remain competitive and excel in the market, organizations must accelerate: delivery of goods and services to delight their customers; engagement with the market to detect and understand customer demand; anticipation of compliance and regulatory changes that impact their systems; and response to potential risks such as security threats or changes in the economy.
The key to successful change is measuring and understanding the right things with a focus on capabilities—not on maturity.
Most maturity models simply measure the technical proficiency or tooling install base in an organization without tying it to outcomes. These end up being vanity metrics: while they can be relatively easy to measure, they don’t tell us anything about the impact they have on the business.
To summarize, in 2017 we found that, when compared to low performers, the high performers have: 46 times more frequent code deployments 440 times faster lead time from commit to deploy 170 times faster mean time to recover from downtime 5 times lower change failure rate (1/5 as likely for a change to fail)
High performers understand that they don’t have to trade speed for stability or vice versa, because by building quality in they get both.
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. The classic example is rewarding developers for throughput and operations for stability: this is a key contributor to the “wall of confusion” in which development throws poor quality code over the wall to operations, and operations puts in place painful change management processes as a way to inhibit change. Second, our measure should focus on outcomes not output: it shouldn’t reward people for putting in large amounts of busywork
...more
Lead time is the time it takes to go from a customer making a request to the request being satisfied. However, in the context of product development, where we aim to satisfy multiple customers in ways they may not anticipate, there are two parts to lead time: the time it takes to design and validate a product or feature, and the time to deliver the feature to customers. In the design part of the lead time, it’s often unclear when to start the clock, and often there is high variability.
Analysis over several years shows that high-performing organizations were consistently twice as likely to exceed these goals as low performers. This demonstrates that your organization’s software delivery capability can in fact provide a competitive advantage to your business.
The fact that software delivery performance matters provides a strong argument against outsourcing the development of software that is strategic to your business, and instead bringing this capability into the core of your organization.
“in pathological and bureaucratic organizational cultures, measurement is used as a form of control, and people hide information that challenges existing rules, strategies, and power structures. As Deming said, ’whenever there is fear, you get the wrong numbers’”
organizational culture, there are several ways to define and model “culture.” Organizational culture can exist at three levels in organizations: basic assumptions, values, and artifacts (Schein 1985). At the first level, basic assumptions are formed over time as members of a group or organization make sense of relationships, events, and activities. These interpretations are the least “visible” of the levels—and are the things that we just “know,” and may find difficult to articulate, after we have been long enough in a team. The second level of organizational culture are values, which are more
...more
three characteristics of good information: It provides answers to the questions that the receiver needs answered. It is timely. It is presented in such a way that it can be effectively used by the receiver.
the way to change culture is not to first change how people think, but instead to start by changing how people behave—what they do”
A key goal of continuous delivery is changing the economics of the software delivery process so the cost of pushing out individual changes is very low.
No one should be saying they are “done” with any work until all relevant automated tests have been written and are passing.
having automated tests primarily created and maintained either by QA or an outsourced party is not correlated with IT performance. The theory behind this is that when developers are involved in creating and maintaining acceptance tests, there are two important effects. First, the code becomes more testable when developers write tests. This is one of the main reasons why test-driven development (TDD) is an important practice—it forces developers to create more testable designs. Second, when developers are responsible for the automated tests, they care more about them and will invest more effort
...more
We set out to discover the impact of architectural decisions and constraints on delivery performance, and what makes an effective architecture. We found that high performance is possible with all kinds of systems, provided that systems—and the teams that build and maintain them—are loosely coupled. This key architectural property enables teams to easily test and deploy individual components or services even as the organization and the number of systems it operates grow—that is, it allows organizations to increase their productivity as they scale.
was no significant correlation between system type and delivery performance. We found this surprising: we had expected teams working on packaged software, systems of record, or embedded systems to perform worse, and teams working on systems of engagement and greenfield systems to perform better. The data shows that this is not the case.
the following statements were more likely to be in the high-performing group: We can do most of our testing without requiring an integrated environment.1 We can and do deploy or release our application independently of other applications/services it depends on.
larger even than test and deployment automation—is whether teams can: Make large-scale changes to the design of their system without the permission of somebody outside the team Make large-scale changes to the design of their system without depending on other teams to make changes in their systems or creating significant work for other teams Complete their work without communicating and coordinating with people outside their team Deploy and release their product or service on demand, regardless of other services it depends upon Do most of their testing on demand, without requiring an integrated
...more
Unfortunately, in real life, many so-called service-oriented architectures don’t permit testing and deploying services independently
As the number of developers increases, we found: Low performers deploy with decreasing frequency. Medium performers deploy at a constant frequency. High performers deploy at a significantly increasing frequency.
OWASP Top 10,1
we want to make it easy for developers to do the right thing when it comes to infosec. This can be achieved by ensuring that there are easy-to-consume, preapproved libraries, packages, toolchains, and processes available for developers and IT operations.
Limiting work in progress (WIP), and using these limits to drive process improvement and increase throughput Creating and maintaining visual displays showing key quality and productivity metrics and the current status of work (including defects), making these visual displays available to both engineers and leaders, and aligning these metrics with operational goals Using data from application performance and infrastructure monitoring tools to make business decisions on a daily basis
We found that 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. Finally, teams that required approval by an external body achieved lower performance.
We found that where code deployments are most painful, you’ll find the poorest software delivery performance, organizational performance, and culture.
In order to reduce deployment pain, we should: Build systems that are designed to be deployed easily into multiple environments, can detect and tolerate failures in their environments, and can have various components of the system updated independently Ensure that the state of production systems can be reproduced (with the exception of production data) in an automated fashion from information in version control Build intelligence into the application and the platform so that the deployment process can be as simple as possible
People are at the heart of every technology transformation.
Our research found that employees in high-performing organizations were 2.2 times more likely to recommend their organization as a great place to work, and other studies have also shown that this is correlated with better business outcomes (Azzarello et al. 2012).
Being a leader doesn’t mean you have people reporting to you on an organizational chart—leadership is about inspiring and motivating those around you. A good leader affects a team’s ability to deliver code, architect good systems, and apply Lean principles to how the team manages its work and develops products.
Servant leaders focus on their followers’ development and performance, whereas transformational leaders focus on getting followers to identify with the organization and engage in support of organizational objectives.
we observed significant differences in leadership characteristics among high-, medium-, and low-performing teams. High-performing teams reported having leaders with the strongest behaviors across all dimensions: vision, inspirational communication, intellectual stimulation, supportive leadership, and personal recognition. In contrast, low-performing teams reported the lowest levels of these leadership characteristics. These differences were all at statistically significant levels.
Building trust with your counterparts on other teams. Building trust between teams is the most important thing you can do, and it must be built over time. Trust is built on kept promises, open communication, and behaving predictably even in stressful situations. Your teams will be able to work more effectively, and the relationship will signal to the organization that cross-functional collaboration is valued.
In all of our research, one thing has proved consistently true: since nearly every company relies on software, delivery performance is critical to any organization doing business today. And software delivery performance is affected by many factors, including leadership, tools, automation, and a culture of continuous learning and improvement.
