I read 『LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する』 (‘Accelerate: The Science of Lean Software and DevOps - Building and Scaling High Performing Technology Organizations’), so I’ll share the insights I gained from this book.

Background

After reading 『チームトポロジ』を読んで, I felt that ‘The Science of Lean and DevOps’ was also essential reading, so I picked up this book.

→ LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する - インプレスブックス

Below are quotes and notes from parts that left an impression on me.

■Part 1: What the Research Shows

Chapter 1: Accelerating

1.1 Focus on Capabilities, not Maturity

Technology managers must deliver software quickly and reliably to gain a competitive advantage in the market. However, for many organizations, this means making significant changes to how they deliver software. The key to success in this case is to focus not on the organization's "maturity" but on capabilities - proper understanding of the situation and measurement of indicators that enable it.

→ I want to focus on Capability.

The second reason why a shift to capability models is necessary is that maturity models often advocate achieving predetermined maturity levels step by step, recommending similar technologies, tools, and capabilities to teams and organizations at the same level. Teams or organizations certified at a specific level (for example, "Level 2") are assumed to be in similar situations and states, but this is a well-known fact among those working in technology-related organizations that this does not reflect reality.

→ In the real world, the same/similar situations and states never continue.

Chapter 2: Measuring Performance

2.2 Desired Measures

Software Delivery Performance Metrics: ・Lead time ・Deployment frequency ・Mean time to recovery ・Change failure rate

→ I want to refer to these metrics.

Chapter 3: Measuring and Changing Culture

3.1 Modeling and Measuring Organizational Culture

Table 3.1 Three Types of Organizational Culture and Their Characteristics Proposed by Westrum

→ I want to refer to this.

Chapter 4: Technical Practices

4.4 Continuous Delivery Practices—Which Are Most Effective

4.4.4 Trunk-Based Development

This research also found that "teams doing trunk-based development have higher delivery performance than teams working off long-lived feature branches."

→ I have no practical experience with trunk-based development, so I’d like to try it somewhere.

Even with this evidence that trunk-based development practices can improve software delivery performance, some developers accustomed to working with "GitHub Flow" remain skeptical. "GitHub Flow" relies heavily on branch-based development and only periodically merges to the trunk. However, from what we've heard, branch strategies can be effective if development teams don't maintain branches for too long, and if short-lived branches are merged to the trunk at least once a day, this doesn't contradict the generally accepted continuous integration practices, which we agree with.

→ Adding the constraint of shortening branch lifespan to the familiar GitHub Flow seems to bring it closer to trunk-based development.

Chapter 5: Architecture

5.4 Teams Can Choose Their Own Tools

Many organizations only allow engineers to choose tools and frameworks from pre-approved options. The purposes of this approach include:

・Reducing the complexity of the working environment ・Ensuring the skills needed to manage the technologies used throughout their lifecycle ・Strengthening purchasing power from vendors ・Properly managing licenses for all software used

However, this inflexible approach prevents teams from choosing the tools that best meet their needs and from trying new approaches and paradigms to solve problems.

→ There’s a risk that the organization won’t be able to develop technology selection skills and will gradually lose competitiveness.

Our analysis proves that "tool selection is also an important element of technical work." When teams can choose the tools they need, software delivery performance improves, which also positively affects overall organizational performance. This is not a surprising result. Technical professionals responsible for software development and delivery and complex infrastructure operations choose tools that best serve to complete work and support users.

→ “When teams can choose the tools they need, software delivery performance improves, which also positively affects overall organizational performance.”

However, standardization isn't bad either, especially when it comes to infrastructure architecture and configuration.

→ When work cannot be completed within the team, for example when SRE team support is needed, using standardized tools is also an option.

Another finding from this research is that "teams that incorporate information security concepts into their delivery processes also have high continuous delivery performance." The key element here is "having information security teams arrange for developers and IT operations staff to use pre-approved, user-friendly libraries, packages, toolchains, and processes in their work."

→ For security as well, when security engineer support is needed, using standardized tools is an option.

5.5 What Architecture Designers Should Focus On: Engineers and Outcomes

It's inappropriate to force users to use tools or technologies that they have no desire to use, or that cannot achieve the outcomes and behaviors that users value. What's important is that teams can make changes to products and services without depending on other teams or systems.

→ I want to prioritize providing value to products and services.

Chapter 11: Transformational Leadership and the Role of Management

11.1 Transformational Leadership

The role of leadership in technology transformation has often been overlooked in discussions about DevOps, despite being essential in the following ways:

・Establishing and supporting cultural norms to achieve high reliability and productivity ・Creating technology that enhances developer productivity, reduces lead time to deployment, and supports more reliable infrastructure ・Supporting team experimentation and innovation to quickly create and implement quality products ・Building strategic partnerships through cross-organizational initiatives

That’s all from the Gemba.