Accelerate
Kindle Highlights: >-
Highlights
refutes the bimodal IT notion that you have to choose between speed and stability—instead, speed depends on stability, so good IT practices give you both. — location: 147 ^ref-58563
moving to outcome-based team structures, knowing our cycle time (by understanding our value stream map), limiting the blast radius (starting with one to two teams vs. boiling the ocean), using data to drive actions and decisions, 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). — location: 172 ^ref-26233
capabilities are classified into five categories: Continuous delivery Architecture Product and process Lean management and monitoring Cultural — location: 199 ^ref-63430
shifting to a capabilities model of measurement is essential for — location: 386 ^ref-47161
Once utilization gets above a certain level, there is no spare capacity (or “slack”) to absorb unplanned work, changes to the plan, or improvement work. This results in longer lead times to complete work. 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. — location: 480 ^ref-26970
measures of delivery performance that meet these criteria, we settled on four: delivery lead time, deployment frequency, time to restore service, and change fail rate. In — location: 492 ^ref-16083
organizational culture predicts the way information flows through an organization. Westrum provides 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. — location: 689 ^ref-22529
How organizations deal with failures or accidents is particularly instructive. Pathological organizations look for a “throat to choke”: Investigations aim to find the person or persons “responsible” for the problem, and then punish or blame them. But in complex adaptive systems, accidents are almost never the fault of a single person who saw clearly what was going to happen and then ran toward it or failed to act to prevent it. Rather, accidents typically emerge from a complex interplay of contributing factors. Failure in complex systems is, like other types of behavior in such systems, emergent (Perrow 2011). Thus, 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. — location: 786 ^ref-63550
team’s ability to achieve the following outcomes: Teams can deploy to production (or to end users) on demand, throughout the software delivery lifecycle. Fast feedback on the quality and deployability of the system is available to everyone on the team, and people make acting on this feedback their highest priority. — location: 890 ^ref-54949
loosely coupled, well-encapsulated architecture (this is discussed in more detail in Chapter 5) Teams that can choose their own tools based on what is best for the users of those tools — location: 896 ^ref-11703
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. — location: 946 ^ref-52544
DevOps is all about better collaboration between teams, and we don’t mean to suggest teams shouldn’t work together. The goal of a loosely coupled architecture is to ensure that the available communication bandwidth isn’t overwhelmed by fine-grained decision-making at the implementation level, — location: 1073 ^ref-30912
ALLOW TEAMS TO CHOOSE THEIR OWN TOOLS — location: 1092 ^ref-17676