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
Do'stlaringiz bilan baham: 
