Accelerate: Building and Scaling High Performing Technology Organizations

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.

High performers understand that they don’t have to trade speed for stability or vice versa, because by building quality in they get both.

ARCHITECTS SHOULD FOCUS ON ENGINEERS AND OUTCOMES, NOT TOOLS OR TECHNOLOGIES

Adrian Cockcroft, Netflix’s seminal cloud architect, was once asked by a senior leader in a Fortune 500 company where he got his amazing people from. Cockcroft replied, “I hired them from you!

The most important characteristic of high-performing teams is that they are never satisfied: they always strive to get better. High performers make improvement part of everybody’s daily work.

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.

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. All of these have a measurable impact on an organization’s profitability, productivity, and market share.

Knowledge is power, and you should give power to those who have the knowledge.

As Deming said, ’whenever there is fear, you get the wrong numbers

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

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.

Westrum’s description of a rule-oriented culture is perhaps best thought of as one where following the rules is considered more important than achieving the mission—and we have worked with teams in the US Federal Government we would have no issue describing as generative, as well as startups that are clearly pathological.

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” (Deming 2000).

In addition to regular stand-ups with squads, product owners, IT-area leads, and chapter leads, the tribe lead also regularly visits the squads to ask questions—not the traditional questions like “Why isn’t this getting done?” but, rather, “Help me better understand the problems you’re encountering,” “Help me see what you’re learning,” and “What can I do to better support you and the team?” This kind of coaching behavior does not come easily to some leaders and managers. It takes real effort,

In our search for 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.

Using velocity as a productivity metric has several flaws. First, velocity is a relative and team-dependent measure, not an absolute one. Teams usually have significantly different contexts which 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). Not only does this destroy the utility of velocity for its intended purpose, it also inhibits collaboration between teams.

Another Forrester report states that DevOps is accelerating technology, but that organizations often overestimate their progress (Klavens et al. 2017). Furthermore, the report points out that executives are especially prone to overestimating their progress when compared to those who are actually doing the work.

software delivery is an exercise in continuous improvement, and our research shows that year over year the best keep getting better, and those who fail to improve fall further and further behind.

Technology managers, like so many other well-meaning managers, often try to fix the person while ignoring the work environment, even though changing the environment is far more vital for long-term success. Managers who want to avert employee burnout should concentrate their attention and efforts on: 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.

We found that where code deployments are most painful, you’ll find the poorest software delivery performance, organizational performance, and culture.

much of what has been implemented is faux Agile—people following some of the common practices while failing to address wider organizational culture and processes.

we hypothesized that implementing CD would influence organizational culture. Our analysis shows that this is indeed the case. If you want to improve your culture, implementing CD practices will help.

Westrum’s theory posits that organizations with better information flow function more effectively.

We measured product delivery lead time as the time it takes to go from code committed to code successfully running in production

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.

delivery lead time, deployment frequency, time to restore service, and change fail rate.

I made a lot of mistakes along the way and wish I had access to the information in this book back then. 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).

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.

Computers perform repetitive tasks; people solve problems. One important strategy to reduce the cost of pushing out changes is to take repetitive work that takes a long time, such as regression testing and software deployments, and invest in simplifying and automating this work.

We measured transformational leadership using survey questions adapted from Rafferty and Griffin (2004):1 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 a part of this organization. ​–​Says positive things about the work unit. ​–​Encourages people to see changing environments as situations full of opportunities. (Intellectual stimulation) ​–​Challenges me to think about 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 recognition) ​–​Commends me when I do a better than average job. ​–​Acknowledges improvement in my quality of work. ​–​Personally compliments me when I do outstanding work.