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

• 
What the new product functionality is and why we’re building it
• 
How it works as it pertains to operability, scalability, and observ-
ability (diagramming is strongly encouraged)
• 
How to monitor and collect metrics to ensure the progress, success, 
or failure of the functionality
Promo 
- Not 
for 
distribution 
or 
sale

---

Chapter 8 • 101
• 
Any departures from previous architectures and patterns, and 
the justifications for them
• 
Any extra needs for infrastructure and how usage will affect in-
frastructure capacity
• 
Feature launch plans
Furthermore, just like in the embedded Ops model, this liaison attends the 
team standups, integrating their needs into the Operations road map and 
performing any needed tasks. We rely on these liaisons to escalate any resource 
contention or prioritization issue. By doing this, we identify any resource or 
time conflicts that should be evaluated and prioritized in the context of wider 
organizational goals.
Assigning Ops liaisons allows us to support more product teams than
the embedded Ops model. Our goal is to ensure that Ops is not a constraint 
for the product teams. If we find that Ops liaisons are stretched too thin, 
preventing the product teams from achieving their goals, then we will likely 
need to either reduce the number of teams each liaison supports or tempo-
rarily embed an Ops engineer into specific teams. 
INTEGRATE OPS INTO DEV RITUALS 
When Ops engineers are embedded or assigned as liaisons into our product 
teams, we can integrate them into our Dev team rituals. In this section, our 
goal is to help Ops engineers and other non-developers better understand the 
existing Development culture and proactively integrate them into all aspects 
of planning and daily work. As a result, Operations is better able to plan and 
radiate any needed knowledge into the product teams, influencing work long 
before it gets into production. The following sections describe some of the 
standard rituals used by Development teams using agile methods and how 
we would integrate Ops engineers into them. By no means are agile practices 
a prerequisite for this step—as Ops engineers, our goal is to discover what 
rituals the product teams follow, integrate into them, and add value to them.
†
† 
However, if we discover that the entire Development organization merely sits at their desks 
all day without ever talking to each other, we may have to find a different way to engage them, 
such as buying them lunch, starting a book club, taking turns doing “lunch and learn” presen-
tations, or having conversations to discover what everyone’s biggest problems are, so that we 
can figure out how we can make their lives better.
Promo 
- Not 
for 
distribution 
or 
sale

---

102 • Part II
As Ernest Mueller observed, “I believe DevOps works a lot better if Operations 
teams adopt the same agile rituals that Dev teams have used—we’ve had 
fantastic successes solving many problems associated with Ops pain points, 
as well as integrating better with Dev teams.”
INVITE OPS TO OUR DEV STANDUPS
One of the Dev rituals popularized by Scrum is the daily standup, a quick 
meeting where everyone on the team gets together and presents to each other 
three things: what was done yesterday, what is going to be done today, and 
what is preventing you from getting your work done.
†
The purpose of this ceremony is to radiate information throughout the team 
and to understand the work that is being done and is going to be done. By 
having team members present this information to each other, we learn about 
any tasks that are experiencing roadblocks and discover ways to help each 
other move our work toward completion. Furthermore, by having managers 
present, we can quickly resolve prioritization and resource conflicts. 
A common problem is that this information is compartmentalized within the 
Development team. By having Ops engineers attend, Operations can gain an 
awareness of the Development team’s activities, enabling better planning and 
preparation—for instance, if we discover that the product team is planning 
a big feature rollout in two weeks, we can ensure that the right people and 
resources are available to support the rollout. Alternatively, we may highlight 
areas where closer interaction or more preparation is needed (e.g., creating 
more monitoring checks or automation scripts). By doing this, we create the 
conditions where Operations can help solve our current team problems (e.g., 
improving performance by tuning the database, instead of optimizing code) 
or future problems before they turn into a crisis (e.g., creating more integration 
test environments to enable performance testing).
INVITE OPS TO OUR DEV RETROSPECTIVES
Another widespread agile ritual is the retrospective. At the end of each de-
velopment interval, the team discusses what was successful, what could be 
improved, and how to incorporate the successes and improvements in future 
iterations or projects. The team comes up with ideas to make things better 
† 
Scrum is an agile development methodology, described as “a flexible, holistic product devel-
opment strategy where a development team works as a unit to reach a common goal.” It was 
first fully described by Ken Schwaber and Mike Beedle in the book