The devops handbook how to Create World-Class Agility, Reliability, & Security in Technology Organizations By Gene Kim, Jez Humble, Patrick Debois, and John Willis

• 
Product owner: the internal voice of the business that defines 
the next set of functionality in the service
• 
Development: the team responsible for developing application 
functionality in the service
• 
QA: the team responsible for ensuring that feedback loops exist 
to ensure the service functions as desired
• 
Operations: the team often responsible for maintaining the 
production environment and helping ensure that required service 
levels are met
• 
Infosec: the team responsible for securing systems and data
• 
Release managers: the people responsible for managing and 
coordinating the production deployment and release processes
• 
Technology executives or value stream manager: in Lean 
literature, someone who is responsible for “ensuring that the 
value stream meets or exceeds the customer [and organizational] 
requirements for the overall value stream, from start to finish”
CREATE A VALUE STREAM MAP TO SEE THE WORK
After we identify our value stream members, our next step is to gain a 
concrete understanding of how work is performed, documented in the form 
Promo 
- Not 
for 
distribution 
or 
sale

---

64 • Part II
of a value stream map. In our value stream, work likely begins with the 
product owner, in the form of a customer request or the formulation of a 
business hypothesis. Some time later, this work is accepted by Development, 
where features are implemented in code and checked in to our version 
control repository. Builds are then integrated, tested in a production-like 
environment, and finally deployed into production, where they (ideally) 
create value for our customer.
In many traditional organizations, this value stream will consist of hundreds, 
if not thousands, of steps, requiring work from hundreds of people. Because 
documenting any value stream map this complex likely requires multiple 
days, we may conduct a multi-day workshop, where we assemble all the key 
constituents and remove them from the distractions of their daily work. 
Our goal is not to document every step and associated minutiae, but to suffi-
ciently understand the areas in our value stream that are jeopardizing our 
goals of fast flow, short lead times, and reliable customer outcomes. Ideally, 
we have assembled those people with the authority to change their portion 
of the value stream.
†
Damon Edwards, co-host of 
DevOps Caf
é podcast, observed, “In my experience, 
these types of value stream mapping exercises are always an eye-opener. 
Often, it is the first time when people see how much work and heroics are 
required to deliver value to the customer. For Operations, it may be the first 
time that they see the consequences that result when developers don’t have 
access to correctly configured environments, which contributes to even more 
crazy work during code deployments. For Development, it may be the first 
time they see all the heroics that are required by Test and Operations in order to 
deploy their code into production, long after they flag a feature as ‘completed.’”
Using the full breadth of knowledge brought by the teams engaged in the 
value stream, we should focus our investigation and scrutiny on the 
following areas:
• 
Places where work must wait weeks or even months, such as 
getting production-like environments, change approval processes, 
or security review processes