More on this book
Community
Kindle Notes & Highlights
Read between
September 5 - September 5, 2021
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)
narrowed for tempo (deployment frequency and change lead time)
widened for stability (mean time to recover and change failure rate).
low-performing teams working to increase tempo but not investing enough in building quality into the process. The result is larger deployment failures th...
This highlight has been truncated due to consecutive passage length restrictions.
The result is larger deployment failures that take more time ...
This highlight has been truncated due to consecutive passage length restrictions.
trade speed for s...
This highlight has been truncated due to consecutive passage length restrictions.
building quality in they...
This highlight has been truncated due to consecutive passage length restrictions.
They do this by turning the right levers—that is, by improving the right capabilities.
Our research investigated organizations of all sizes, in all industries, using legacy and greenfield technology stacks around the world—
MEASURING PERFORMANCE
many frameworks and methodologies that aim to improve the way we build software products and services.
discover what works and what doesn’t in a scientific way,
framework and methods
Measuring performance
the inventory is invisible.
the way we break down work is relativ...
This highlight has been truncated due to consecutive passage length restrictions.
design and delivery activities—particularly in the Agile software development paradi...
This highlight has been truncated due to consecutive passage length restrictions.
it’s expected that we will change and evolve our design based on what we learn by...
This highlight has been truncated due to consecutive passage length restrictions.
First, they focus on outputs rather than outcomes. Second, they focus on individual or local measures rather than team or global ones.
lines of code, velocity, and utilization.
10-line solution to a 1,000-line solution to a problem.
incurs higher maintenance costs and higher cost of change.
accomplishing a task in a single line of code that no one else can understand is less desirable than writing a few lines of code that are easily understood and maintained.
software development came a new way to measure productivity: velocity. In many schools of Agile, problems are broken down into stories. Stories are then estimated by developers and assigned a number of “points” representing the relative effort expected to complete them. At the end of an iteration, the total number of points signed off by the customer is recorded—this is the team’s velocity. Velocity is designed to be used as a capacity planning tool;
velo...
This highlight has been truncated due to consecutive passage length restrictions.
Stories are then estimated by developers and assigned a number of “points” representing the relative eff...
This highlight has been truncated due to consecutive passage length restrictions.
capacity planning tool;
how long it will take the team to complete all the work that has been planned and estimated.
way to measure team productivity, or even to...
This highlight has been truncated due to consecutive passage length restrictions.
productivity metric has sev...
This highlight has been truncated due to consecutive passage length restrictions.
when velocity is used as a productivity measure, teams inevitably work to game their velocity. They
possible at the expense of collaboration with other
this destroy the utility of velocity for its intended purpose, it also inhibits collaboration between teams.
measure utilization as a proxy for productivity.
no spare capacity (or “slack”)
utilization approaches 100%, lead times approach
it’s essential that we manage utilization to balance it against lead time in an economically optimal way.
First, it should focus on a global outcome to ensure teams aren’t pitted against each other.
rewarding developers for throughput and operations for stability:
way to inhibit change. Second, our measure should
outcomes not output: it shouldn’t reward people for putting in large amounts of busywork that doesn’t actually help
delivery lead time, deployment frequency, time to restore service, and change fail rate.
elevation of lead time
key element of Lean theory.
time is the time it takes to go from a customer making a request to the request b...
This highlight has been truncated due to consecutive passage length restrictions.
not anticipate, there are two parts to lead time: the time it takes to design and validate a product
time to deliver the feature to customers.
Product Design and Development Product Delivery (Build, Testing, Deployment) Create new products and services that solve customer problems using hypothesis-driven delivery, modern UX, design thinking. Enable fast flow from development to production and reliable releases by standardizing work, and reducing variability and batch sizes. Feature design and implementation may require work that has never been performed before. Integration, test, and deployment must be performed continuously as quickly as possible. Estimates are highly uncertain. Cycle times should be well-known and predictable.
...more
Shorter product delivery lead times are better since they enable faster feedback on what we are building and allow us to course correct more rapidly. Short
product delivery lead time as the time it takes to go from code committed to code successfully running
