Accelerate

(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).

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.

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.

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 Perform deployments during normal business hours with negligible downtime

Our research lends support to what is sometimes called the “inverse Conway Maneuver,”2 which states that organizations should evolve their team and organizational structure to achieve the desired architecture.

When teams can decide which tools they use, it contributes to software delivery performance and, in turn, to organizational performance.

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.

Net Promoter Score is calculated based on a single question: How likely is it that you would recommend our company/product/service to a friend or colleague? Net Promoter Score is scored on a 0-10 scale, and is categorized as follows: Customers who give a score of 9 or 10 are considered promoters. Promoters create greater value for the company because they tend to buy more, cost less to acquire and retain, stay longer, and generate positive word of mouth. Those giving a score of 7 or 8 are passives. Passives are satisfied, but much less enthusiastic customers. They are less likely to provide referrals and more likely to defect if something better comes along. Those giving a score from 0 to 6 are detractors. Detractors are more expensive to acquire and retain, they defect faster, and can hurt the business through negative word of mouth. In

The five characteristics of a transformational leader are: Vision. Has a clear understanding of where the organization is going and 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.

And you should give power to those who have the knowledge. You may be asking yourself: What could investment in DevOps initiatives and my teams look like? There are a number of ways technology leaders can invest in their teams:

Help create a climate of learning by:

Leading questions. Survey questions should let the respondent answer without biasing them in a direction. For example, “How would you describe Napoleon’s height?” is better than “Was Napoleon short?” Loaded questions. Questions should not force respondents into an answer that isn’t true for them. For example, “Where did you take your certification exam?” doesn’t allow for the possibility that they didn’t take a certification exam. Multiple questions in one. Questions should only ask one thing. For example, “Are you notified of failures by your customers and the NOC?” doesn’t tell you which part of the question your respondent was answering for. Customers? the NOC? Both? Or if no, neither? Unclear language. Survey questions should use language that your respondents are familiar with, and should clarify and provide examples when necessary.

A latent construct is a way of measuring something that can’t be measured directly. We can ask for the temperature of a room or the response time of a website—these things we can measure directly.

Once we collect the data, we can run several statistical tests to make sure that those items do, in fact, all measure the same underlying concept—the latent construct. These tests check for: Discriminant validity: tests to make sure that items that are not supposed to be related are actually unrelated (e.g., make sure that items that we believe are not capturing organizational culture are not, in fact, related to organizational culture). Convergent validity: tests to make sure that items that are supposed to be related are actually related (e.g., if items are supposed to measure organizational culture, then they do measure organizational culture).

In the case of Westrum organizational culture, we have seven items that capture a team’s organizational culture: On my team … Information is actively sought. Messengers are not punished when they deliver news of failures or other bad news. Responsibilities are shared. Cross-functional collaboration is encouraged and rewarded. Failure causes inquiry. New ideas are welcomed. Failures are treated primarily as opportunities to improve the system. Using a scale from “1 = Strongly disagree” to “7 = Strongly agree,” teams can quickly and easily measure their organizational culture.

There are several reasons to use survey data. We’ll briefly present some of these in this chapter. Surveys allow you to collect and analyze data quickly. Measuring the full stack with system data is difficult. Measuring completely with system data is difficult. You can trust survey data. Some things can only be measured through surveys.