Book Club: The DevOps Handbook (Chapter 1. Agile, Continuous Delivery, and the Three Ways)

The following is a chapter summary for “The DevOps Handbook” by Gene Kim, Jez Humble, John Willis, and Patrick DeBois for an online book club.

The book club is a weekly lunchtime meeting of technology professionals. As a group, the book club selects, reads, and discuss books related to our profession. Participants are uplifted via group discussion of foundational principles & novel innovations. Attendees do not need to read the book to participate.

Background on The DevOps Handbook

More than ever, the effective management of technology is critical for business competitiveness. For decades, technology leaders have struggled to balance agility, reliability, and security. The consequences of failure have never been greater―whether it’s the healthcare.gov debacle, cardholder data breaches, or missing the boat with Big Data in the cloud.

And yet, high performers using DevOps principles, such as Google, Amazon, Facebook, Etsy, and Netflix, are routinely and reliably deploying code into production hundreds, or even thousands, of times per day.

Following in the footsteps of The Phoenix Project, The DevOps Handbook shows leaders how to replicate these incredible outcomes, by showing how to integrate Product Management, Development, QA, IT Operations, and Information Security to elevate your company and win in the marketplace.

The DevOps Handbook

Chapter 1

The Manufacturing Value Stream

In manufacturing operations, the value stream is often easy to see and observe: it starts when a customer order is received and the raw materials are released onto the plant floor.

Value Stream: “the sequence of activities an organization undertakes to deliver upon a customer request” or “the sequence of activities required to design, produce, and deliver a good or service to a customer, including the dual flows of information and material.” – Value Stream Mapping by Karen Martin & Mike Osterling

To enable fast and predictable lead times in any value stream:

• Create a smooth and even flow of work
• Using techniques such as small batch sizes
• Reducing work in process (WIP)
• Preventing rework to ensure defects are not passed to downstream work centers
• Constantly optimizing the system toward global goals

The Technology Value Stream

The same principles and patterns that enable the fast flow of work in physical processes are equally applicable to technology work.

In DevOps, the technology value stream as the process required to convert a business hypothesis into a technology-enabled service that delivers value to the customer. Value is created only when services run in production.

Focus on Deployment Lead Time

Deployment Lead Time begins when a developer checks a change into version control. Deployment Lead Time ends when that change is successfully running in production, providing value to the customer and generating useful feedback and telemetry.

Instead of work going sequentially through the design/development value stream and then through the test/operations value stream, testing and operation happens simultaneously with design/development.

Defining Lead Time vs. Processing Time:

• The lead time clock starts when the request is made and ends when it is fulfilled.
• The process time clock starts only when work begins on the customer request—specifically, it omits the time that the work is in queue, waiting to be processed.

The Common Scenario: Deployment Lead Times Requiring Months

When we have long deployment lead times, heroics are required at almost every stage of the value stream. We may discover that nothing works at the end of the project when we merge all the development team’s changes together.

Our DevOps Ideal: Deployment Lead Times of Minutes

Developers receive fast, constant feedback on their work, which enables them to quickly and independently implement, integrate, and validate their code, and have the code deployed into the production environment.

Achieved by checking in small code changes to version control repository, performing automated and exploratory testing against it, and deploying it into production. Achieved when we have architecture that is modular, well encapsulated, and loosely-coupled.

Teams capable of working with high degrees of autonomy, with failures being small and contained, and without causing global disruptions. Deployment lead time is measured in minutes or, in the worst case, hours.

The below is the Value Stream Map:

Observing “%C/A” As A Measure of Rework

The third key metric in the technology value stream is percent complete and accurate (%C/A). This metric reflects the quality of the output of each step in our value stream.

“The %C/A can be obtained by asking downstream customers what percentage of the time they receive work that is ‘usable as is,’ meaning that they can do their work without having to correct the information that was provided, add missing information that should have been supplied, or clarify information that should have and could have been clearer.”

Value Stream Mapping

The Three Ways: The Principles Underpinning DevOps

The First Way enables fast left-to-right flow of work from Development to Operations to the customer. In order to maximize flow, we need to make work visible, reduce our batch sizes and intervals of work, build in quality by preventing defects from being passed to downstream work centers, and constantly optimize for the global goals.

The First Way

Goal: Speed up flow through technology value stream, reduce lead time to fulfill requests, increase throughput.

Practices:

• Continuous build, integration, test, and deployment processes
• Creating environments on demand
• Limiting work in process (WIP)
• Building systems and organizations that are safe to change

The Second Way

Goal: Creation of a generative, high-trust culture that supports a dynamic, disciplined, and scientific approach to experimentation and risk-taking, facilitating the creation of organizational learning, both from our successes and failures.

Practices:

• System design to multiple effects of new knowledge (local discoveries into global improvements)

The Third Way

Goal: fast and constant flow of feedback from right to left at all stages of our value stream.

Practices:

• Amplify feedback to prevent problems
• Enable faster detection and recovery

Conclusion

Chapter One covered the concepts of value streams, lead time as one of the key measures of the effectiveness for technology, and the high-level concepts behind each of the Three Ways. The following chapter summaries will cover each of the Three Ways in greater detail.

Series Navigation

<< Book Club: The DevOps Handbook (Introduction)Book Club: The DevOps Handbook (Chapter 2. The First Way: The Principles of Flow) >>