Book: Accelerate

“Accelerate: Building and Scaling High Performing Technology Organizations” By Nicole Forsgren, PhD, Jez Humble, and Gene Kim

• “The key to successful change is measuring and understanding the right things with a focus on capabilities–not on maturaity.”
• “First, maturity models focus on helping an organization ‘arrive’ at a mature state and then declare themselves done with their journey, whereas technology transformation should follow a continuous improvement paradigm. Alternatively, capability models focus on helping an organization continually improve and progress, realizing that the technological and the business landscape is everchanging.”
• “Second, maturity models are quiet often a ‘lock-step’ or linear formula, prescrie a smilar set of technologies, tooling, or capabilities for every set of teams or organizations to progress through.”, “In contrast, capability models are multidimensional and dynamic, allowing different parts of the organization to take a customized appraoch to improvement, and focus on capabilities that will give them the most benefit based on the current context and their short- and long-term goals.”
• “Third, capability models focus on key outcomes and how the capabilities, or levers, drive improvement in those outcomes–that is, they are outcome based. This provides technical ledership with clear direction and strategy on high-level goals (with a focus on capabilites to improve key outcomes).”
• Performance metrics:
  • Line of code:
    • “Rewarding developers for writing lines of code leads to bloated sofware that incures higher maintenance costs and higher cost of change. Ideally, we should reward developers for solveing busienss problems with minimum amound of code–and it’s even better if we can solve a problem without writing code at all or by deleting code (perhaps by a business process change). However, minimizing line of code isn’t an ideal measure either. At the extremem, this too has drawbacks: 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.”
  • Velocity:
    • “First, velocity is a relative and team-dependent measure, nota an absolute one. Teams usually have significantly different context with render their velocities incommensurable. Second, when velocity is used as a productivity measure, teams inevitably work to game their velocity. They inflate their estimates and focus on completing as many stories as possible at the expense of collaboration with other teams (which might decrease their velocity and increase the other team’s velocity, making them look bad).”
  • Utilization:
    • “The problem with this method is that high utilization is only good up to a point. Once utilization gets above a certain level, there is no spare capacity (or ‘slack’) to absorbe unplanned work, changes to the plan, or improvement work. Queue theory in math tells us that as utilization approaches 100%, lead time approach infinity–in other words, once you get to very high levels of utilization, it takes teams exponentially longer to get anything done.”
  • Lead time:
    • “Since lead time–a measure of how fast work can be completed–is a productivity metric that doesn’t suffer from the drawback of the other metrics we’ve seen, it’s esential that we manage utilization to balance it against lead time in an economically optiamal way.”
    • “Lead time is the time it takes to go from a customer making a request to the request being satisfied.”
    • “there are two parts to lead time: the time it takes to design and valid a product or feature, and the time to deliver the feature to customers”
    • “However, the delivery part of the lead time–the time it takes for work to be implemented, tested, and delivered–is easier to measure and has a lower variability.”
    • “Shorter product delivery lead time are better since they enable faster feedback on what we are bulding and allow us to course correct more rapidly. Short lead time are also important when there is a defect or outage and weed to deliver a fix rapidly and with high confidence.”
    • “We measure product delivery lead time as the time it takes to go from code committed to go successfully running in production”
  • deployment frequency
    • “Reducing batch size reduces cycle time and variability in flow, accelerates feedback, reduces risk and overhead, improves efficiency, increases motivation and urgency, and reduces costs and schedule growth.”
    • “By ‘deployment’ we mean a software deployment to production or to an app store.”
  • time to restore service
    • “Mean Time to Restore (MTTR)”
  • change fail rate
    • “what percentage of changes to production (including, for exasmple, software releases and infrastructure configuration changes) fail.”
    • “Change Fail Percentage”
  • “Analysis showed that only lead time, release frequency, and tiem to restore together form a valid and reliable construct.”
• Organiztional Culture
  • “Pathological (power-oriented) organizations are characterized by large amount of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.”
  • “Bureaucratic (rule-oriented) organiztions portect departmetns. Those in the department want to maintain their ‘turf,’ insist on their own rules, and generally do things by the book–their book.”
  • “Generative (performance-oriented) organizations focus on the mission. How do we accomplish our goal? Everything is subordinated to good perofrmance, to doing what we are supposed to do.”
• Good culture
  • “First, a good culture requires trust and cooperation between people across the organization, so it reflects the elvel of collaboration and trust inside the organization.”
  • “Second, better organizational culture can indicate higher quality decision-making. In a team with this type of culture, not only is beter information available for making decisions, but those decisions are more easily reversed if they turn out to be wrong because the team is moe likely to be open and transparent rather than closed and hierarchical.”
  • “Finally, teams with these culture norms are likely to do a better job with their people, since problems are more rapidly discovered and addressed.”
• “They expected to find a combination of individual traits and skills that would be key ingredients of high-performing teams. What they found instead was that ‘who is on a team matters less than how the team members interact, structure their work, and view their contributions’ (Google 2015). In other words, it all comes down to team dynamics.”
• “Thus, accident investigations that stop at ‘human error’ are not just bad but dangerous. Human error should, instead, be the start of the inestigation. Our goals 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 prvent catastrophic failures following apprently mundane operations.”
• “what my . . . experince taught me taht was so powerful was that the way to change culture is not to first change how people think, but instead to start by change how people behave–what they do”
• “Continous delivery is a set of capabilities that enable us to get changes of all kinds–features, configuration changes, bug fixes, experiments–into production or into hands of users safely, quickly, and sustainably.”
• key principles at the heart of continuous delivery:
  • “Build quailtiy in.”, “In continuous deliery, we invest in bulding a culture supported by tools and people where we can detect any issues quickly, so that they can be fixed straight away when they are cheap to detect and resolve.”
  • “Work in small batches.”, “By splitting work up into much smaller chunks that deliver measureable business outcomes quickly for a small part of our target market, we get essential feedback on the work we are doing so taht we can course corect. Even though workin in small chunks add some overhead, it reaps enormous rewards by allowing us to avoid work that delivers zero or negatie value for our organizations.”
  • “Computers perform repetive tasks; people solve problems.”, “one important strategy to reduce the cost of pushing out changes is to take repetitve work that takes a long time, such as regression testing and software deployments, and invest in simiplifying and automation this work. Thus, we free up peole for higher-value problem-sovling work, such as improving the deisgn of our systems and processes in response to feedback.”
  • “Relentlessly pursue continuous improvement.”
  • “Everyone is responsible.”
• Foundations of continuous delivery:
  • “Comprehensive configuration management.”, “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. Any change to environments or the software that runs on them should be applied using an automated process from version control.”
  • “Continuous integration (CI)”, “Following our pinciple of working in small batches and bulding quality in, high- performing teams kep branches short-lived (less than one day’s work) and integrate them into trunk/master frequently. Each chagne triggers a buld process that includes running unit tests. If any part of this process fails, developers fix it immediately.”
  • “Continuous testing.”, “Automated unit and aceptance tests should be run against every comit to version control to give developers fast feedback on their changes. Develoeprs 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 builds to come out of CI. No one should be saying they are ‘done’ with any work until all relevant automated tests have been written and are passing.”
• Teams that did well at continuous delivery achieved the following outcome:
  • “Strong identification with the organization you work for”
  • “Higher leels of software delivery perofrmance (lead time, deploy frequency, time to restore service)”
  • “Lower change fail rates”
  • “A geenrative, perfromance-oriented culture”
  • “Lower level os deployment pain”
  • “Reduced team burnout”
• Continuous delivery practices
  • Version Control: “What was most interesting was taht keeping system and application configuration in version control was more highly correlated with software delviery performance than keeping application code in version control. Configuration is normally considered a secondary concern to application code in cofiguration managmeent, but our research shows that this is a misconception.”
  • Test Automation:
    • “Having automated tests that are reliable”, “One way to achieve this is to put automated test that are not reliable ina separate quarantine suite that is run independently.”
    • “It’s interesting to note that having automated tests primarily created by maintained either by QA or an outsoruced 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 reason why test-driven deelopment (TDD) isa an important practice–it forces developers to create more testable designs. Second, when developers are responsible for the auotmated tests, they care more about them and will invest more effort into maintaining and fixing them.”
  • Test Data Management: “In our data, successful teams had adequate test data to run their fully automated test suites and could acquire test data for running automated tests on demand.”
  • Trunk-based Development:
    • “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 stabliztion period. It’s worth re-emphasizing that these results are independent of team size, organization size, or industry.”
    • “We sould note, however, that GitHub Flow is suitable for open source proejcts whose contributors are not working ona  project full time. In that situation, it makes sense for branches that part-time contributors are working on to live for longer periods of time without being merged.”
  • Information Security: “High-performing teams were more likely to incorporate information security into the delivery process. Their infosec personnel provided feedback at every step of the software delivery lifecycle, from deisgn through demos to helping with test automation.”
• “Those who agreed with the following statement were more likely to be in the high-performing group:
  • We can do most of our testing without requiring an integrated environment.
  • We can do deploy or release our application independently of other applications/services it depends on.”
• “We define an inegrated environment as one in which multiple independent services are deployed together, wich as a staging enviroment. In many enterprises integrated environments are expansive and require set-up time.”
• The biggest contributor to continuous delivery 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 test environment”
  • “Performing deployments during normal business hours with negligible downtime”
• “The goal is for your architecture to support the ability of teams to get their work done–from deisgn through to deployment–without requiring high-bandwidth communication between teams.”
• “When teams can decide which tools they use, it contributes to softare delivery performance and, in term, to organizational performance. This isn’t surprising. The technical professionals who deelop and deliver softare and run complex infrastructures make these tool choices based on what is best for completing their work and supportin their users. Similar results have been found in other sudies of technical professionals (e.g., Forsgren et al. 2016), suggesting that the upsides of delegating tool choice to teams may outweigh the disadvantages.”
• “That said, there is aplace for standarization, particularly around the architecture and configuration of infrastructure. The benefits of a standardized operational platform are discussed at length by Humble (2017).”
• “What tools or technologies you use is irrelevant if the people who must use them hate using the, or if they don’t achieve the outcome and eanble the behaviors we care about. What is imprtant is enabling teams to make changes to their products or services without dependign on other teams or systems. Architects should collaborate closely with their users–the engineers who build and operate the system through which the organization achieves its mission–to help hem achieve better outcomes and provide them the tools and technologies that will enable these outcomes.”
• “We found that when teams ‘shift left’ on information security–that is, when they build it into the software delivery process instead of making it a separate phase that happens downstream of the development process–this positively impacts their ability to practice continuous delivery. This, in turn, positively impacts delivery performance.”
• “How can we ensure that paying attention to security doesn’t reduce development throughput? This is the focus of the second aspect of this capability: information security shoudl be integrated into the entire software delivery lifecycle from development through operations. This means infosec experts should conribute to the process of designing applications, attend and provide feedback on demonstrations of the sofware, and ensure that security featrues are tested as part of the automated test suite. Finally, we want to make it easy for devlopers o do the right things 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.”
• “We found that high performers were spending 50% less time remediating security issues than low performers. In other words, by bulding security into their daily work, as opposed to retrofiting security ocncerns at the end, they spent significantly les time addressing security issues.”
• Lean management practices
  • Limi Work in Progress (WIP): “Limiting work in progress (WIP), and using these limits to drive process improvement and increase throughput”
  • Visual Management: “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”
  • Lightweight Change Approvals: “Using data from application performance and infrastructure monitoring tools to make business decisions on a daily basis”
• A lightweight change management process
  • “Teams that reported no approval process or used peer review archived higher software delivery performance. Finally, teams that require approval by an external body achieved lower performance.”
  • “We found that external approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate. In short, approval by an external body (such as a manager or CAB) simply doesn’t work to increase the stability of production systems, measured by the time to restore service and change fail rate. However, it certainly slows things down. It is, in fact, worse than having no change approval process at all.”
  • “First, when any kind of change is committed, somebody who wasn’t involved in authoring the change should review it either before or immediately following commit to version control. This can be someone on the same time This person should approve the change by recording their approval in a system of record such as GitHub (by approving the pull0request) or deployment pipeline tool (by approving a manual stage immediately following commit).”
  • “Second, changes should only be applied to production using a fully automated process that forms part of a deployment pipeline. That is, no changes should be able to made to production unless they have been committed to version control, validated by the standard build and test process, and then deployed through an automated process triggered through a deployment pipeline. As a result of implementing a deployment pipeline, auditors will have a complete record of which changes have been applied to which environments, where they come from in version control, what tests and validation have been run against them, and who approved them and when.”
  • “What are the chances that an external body, not intimately familiar with the internals of a system, can review tens of thousands of lines of code changes by potentially hundreds of engineers and accurately determine the impact on a complex production system? This idea is a form of risk management theater: we check boxes so that when something goes wrong, we can say that at least we followed the process. At best, this process only introduces time delays and handoffs.”
  • “We think that there’s a place for people outside teams to do effective risk management around changes. However, this is more of a governance role than actually inspecting changes. Such teams should be monitoring delivery performance and helping teams improve it by implementing practices that are known to increase stability, quality, and speed, such as the continuous delivery and Lean management practices described in this book.”
• Lean product development practices
  • Work in Small Batches: “The extend to which teams slice up products and features into small batches that can be completed in less than a week and release frequently, including the use of MVPs (minimum viable products).”
  • Make Flow of Work Visible: “Whether teams have a good understanding of the flow of work from the business all the way through to customers, and whether they have visibility into this flow, including the status of products and features.”
  • Gather & Implement Customer Feedback: “Whether organizations actively and regularly seek customer feedback and incorporate this feedback into the design of their products.”
  • Team Experimentation: “Whether development teams have the authority to create and change specifications as part of the development process without requiring approval.”
• “One of the points of Agile development is to seek input from customers throughout the development process, including early stages. This allows the development team to gather important information, which then informs the next stages of development. But 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.”
• “Our analysis showed that they ability of teams to try out new ideas and create and update specification during the development process, without requiring the approval of people outside the team, is an important factor in predicting organizational performance as measured in terms of profitability, productivity, and market share.”
• “the more painful code deployments are, the poor the IT performance, organizational performance, and organizational culture.”
• Complex, brittle deployment process typically the result of:
  • “First, software is often not written with deployability in mind. A common symptom here is when complex, orchestrated deployments are required because the software expects its environments does not tolerate any kind of deviation from these expectations, giving little useful information to administrators on what is wrong and why it is failing to operate correctly.”
  • “Second, the probability of a failed deployment raises substantially when manual changes must be made to production environments as part of the deployment process. Manual changes can easily lead too errors caused by typing, k copy/past mistakes, or poor or out-of-date documentation. Furthermore, environments whose configuration is managed manually often deviate substantially from each other (a problem known as ‘configuration drift’), leading to significant amount of work at deploy time as operators debug to understand configuration differences, potentially making further manual changes that add to the problem.”
  • “Finally, complex deployments often require multiple handoffs between teams, particularly in soloed organizations where database administrators, network administrators, system administrators, infused, testing/QA, and developers all work in separate teams.”
• To reduce deployment pain:
  • “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 system 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”
• To avoid burnout:
  • “Fostering a respectful, supportive work environment that emphasizes learning from failures rather than blaming”
  • “Communicating a strong sense of purpose”
  • “Investing in employee development”
  • “Asking employees what is preventing them from achieving their objectives and then fixing those things”
  • “Giving employees time, space, and resources to experiment and learn”
  • “Last but not least, employees must be given the authority to make decisions that affect their work and their jobs, particularly in areas where they are responsible for the outcomes.”
• Factors correlated to burnout:
  • “Organizational culture. Strong feelings of burnout are found in organizations with a pathological, power-oriented culture. Managers are ultimately responsible for fostering a supportive and respectful work environment, and they can do so by creating a blame-free environment, striving to learn from failures, and communicating a shared sense of purpose.”
  • “Deployment pain”
  • “Effectiveness of leaders. Responsibilities of a team leader include limiting work in process and eliminating roadblocks for the team so they can get their work done.”
  • “Organizational investments in DevOps. Organizations that invest in developing the skills and capabilities of their teams get better outcomes.”
  • “Organizational performance. Our data shows that Lean management and continuous delivery practices help improve software delivery performance, which in turn improves organizational performance.”
    • “When organizational values and individual values aren’t aligned, you are more likely to see burnout in employees, particularly in demanding and high-risk work like technology.”
    • “It is important to note that the organizational values we mention here are the real, actual, lived organizational values felt by employees. If the organizational values felt by employees different from the official values of the organization—the mission statements printed on pieces of paper or even on placards—it will be the everyday, lived values that count.”
• Net promoter Score: “NPS is calculated by subtracting the percentage of detractors from the percentage of promoters. For example, if 40% of employees are detractors and only 20% are promoters, the Net Promoter Score is -20%.”
• “when employees sees the connection between the work they do and its positive impact on customers, they identify more strongly with the company’s purpose, which leads to better delivery and organizational performance.”
• The extend an individual identify with the organization they work for:
  • “I am glad I chose to work for this organization rather than another company.”
  • “I talk of this organization to my friends as a great company to work for.”
  • “I am willing to put in a greal deal of effort beyond what is normally expected to help my organization be successful.”
  • “I find that my values and my organization’s values are very similar.”
  • “In general, the people employed by my organization are working toward the same goal.”
  • “I feel that my organization cares about me.”
• “The extendt to which people identified with their organization predicted a generative, performance-oriented culture and also predicted organizational performance, as measured in terms of produtivity, market share, and profitability.”
• “Our analysis is clear: in today’s fast-moving and competitive world, the best thing you can do for your products, your company, and your people is institute a culture of experimentation and learning, and invest in the technical and management capabilities that enable it.”
• Resources for women in tech:
  • anitab.org
  • geekfeminism.wikia.com
  • projectinclude.org
• “Transformational leadership means leaders inspiring and motivating followers to achieve higher performance by appealing to their values and sense of purpsose, facilitating wide-scale organizational change. Such leaders enoucrage their teams to work toward a common goal through their vision, values, communication, example-setting, and their evident caring about their followers’ personal needs.”
• Five dimensions of transformational leadership:
  • “Vision. Has a clear understanding of where the organization is going where it should be in five years.”
  • “Inspirational communication. Communicates in a way that inspires and motivates, even in an uncertain or changing environment.”
  • “Intellectual stimulation. Challenges followers to think about problems in new ways.”
  • “Supportive leadership. Demonstrates care and consideration of followers’ personal needs and feelings.”
  • “Personal recognition. Praises and acknowledges achievement of goals and improvements in work quality; personally compliments others when they do outstanding work.”
• “My leader or manager:
  • (vision)
    • Has a clear understanding of where we are going.
    • Has a clear sense of where he/she wants our team to be in five years.
    • Has a clear idea of where the organization is going.
  • (Inspirational communication)
    • Says things that make employees proud to be part of this organization.
    • Says psoitive things about the work unit.
    • Encourages people to see changing environments as situations full of opportunities.
  • (Intellectual stimulation)
    • Challenges me to think boaut old problems in new ways.
    • Has ideas that have forced me to rethink some things that I have never questioned before.
    • Has challenged me to rethink some of my basic assumptions about my work.
  • (Supportive leadership)
    • Considers my personal feelings before acting.
    • Behaves in a manner which is thoughtful of my personal needs.
    • Sees that the interests of employees are given due consideration.
  • (Personal recogntion)
    • Commends me when I do beter than average job.
    • Acknowledges improvement in my quality of work.
    • Personally compliments me when I do outstanding work.”
• “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.”
• “Said another way, we found evidence that leaders alone cannot achieve high DevOps outcomes. … This makes sense, becuase leaders cannot achieve goals on their own. They need their teams executing the work on a suitable architecture, with good technical practices, use of Lean principles, and all the other factors that we’ve studied over the years.”
• “Create space and opportunity for learning and improving.”
• “Encourage teams to organize internal ‘yak days,’ where teams get together to work on technical debt. These are great events because technical debt is so rarely prioritized.”
• “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.”
• To enable cross-functional collaboration:
  • “Building trust with your counterparts on other teams.”, “Trust is built on kept promises, open communication, and behaving predictably even in stressful situations.”
  • “Encouraging practitioners to move between departments.”
  • “Actively seeking, encouraging, and rewarding work that facilitates collaboration.”
• To crate a climate of learning:
  • “Creating a training budget and advocating for it internally.”
  • “Ensuring that your team has the resources to engage in informal learning and the space to explore ideas.”
  • “Making it safe to fail.”
  • “Creating opportunities and spaces to share information”
  • “Encoruage sharing and innovation by having demo days and forums.”
• “Unless there’s a good reason not to, practitioners should shoose their own tools. If they can build infrastructure and applications the way they want, the’re much more likely to be invested in their work.”
• Questions to ask the team:
  • “Help me better understand the problems you’re encountering,”
  • “Help me see whata you’re learning,”
  • “What can I do to better support you and the team?”
• “‘Before, I never discussed culture, ‘ he said. ‘It was a difficult topic and I did not know hwo to change it in a sustainable way. But I learned that when you change the way you work, you change the routines, you create a different culture.'”
• “To develop this new way of working, first they needed to undersand how they currently spent their time. The skepticism and discomfort were obvious; nevertheless, for several weeks each of them recorded and measured how they spent their itme each day. They shared what they learned with each other, and together developed new ways to work.”
• “a high-performance culture is far more than just the application of tools, the adoption of a set of interrelated practices, copying the behaviors of other successful organizations, or the implementation of a prescribed, expert-designed framework. It is the development, through experimentation and learning guided by evidence, of a new way of working together that is situationally and culturally appropriate to each organization.”
• Capabilities
  • Continuous delivery
    • “Use version control for all production artifacts.”
    • “Automate your deployment process.”
    • “Implement continuous integration”
    • “Use trunk-based development methods.”, “It is characterized by fewer than three active branches ina code repository; branches and forks having very short lifetimes (e.g. less than a day) before being merged into master; and application teams rarely or never having ‘code lock’ period when no one can check in code or do pull requests due to merging conflicts, code freezes, or stabilization phases.”
    • “Implement test auotmation”
    • “Support test data management”
    • “Integrating security into the design and testing phases of the software development process is key to driving IT performance.”
    • “Implement  continuous delivery (CD)”, “CD is a development practice where sofware is in a deployable state througghout its lifecycle, and the team prioritizes keeping the sofware in a deployable state over working on new features.”
  • Architecture
    • “Use a loosely coupled architecture”
    • “Our research shows that teams that can choose which tools to use do better at continuous deliver and, in turn, drive better sofware development and elivery performance.”
  • Product and Process
    • “Gather and implement customer feedback”
    • “Make the flow of work visible through the value stream”
    • “Work in small batches”
    • “Foster and enable team experimentation”, “Team experimenation 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 crate value.”
  • Lean Management and Monitoring
    • “Have a lightweight change approval proceses.”
    • “Monitor across application and infrastructure to inform business decisions.”
    • “Check system health proactively”
    • “Improve process and manage work with work-in-process (WIP) limits”, “When used effectively, this drives process improvement, increases throughput, and makes constraints visible in the system.”
    • “Visualize work to monitor quality and communicate throughout the team.”
  • Cultural
    • “Support a generative culture (as outlined by Westrum).”, “Hallmarks of this measure include good information flow, high cooperation and trust, bridging between teams, and conscious inquiry.”
    • “Encourage and support learning”
    • “Support and facilitate collaboration among teams”
    • “Provide resources and tools that make work meaningful”
    • “Support or embody ransformational leadership.”
• “Unplanned work and rework:
  • High performers reported spending 49% of their time on new work and 21% on unplanned work or rework.
  • Low performers reported spend 38% of theri tie on new work and 27% on unplanned work or rework.”
• “Change advisory boards are negatively correlated with software delivery performance.”
• “Approval only for high-risk chagnes was not corelated with sofware delivery performance.”
• “Teams that reported no approval process or used peer review achieved higher software delivery performance.”
• “Low perfomers were more likely to say that the software they were building–or the set of services they had to interact with–was ‘custom software developed by another company (e.g. an outsorucing partner).”

Advertisement