Chapter 8 • 103
and reviews experiments from the previous iteration. This is one of the primary
mechanisms where organizational learning and the development of counter-
measures occurs, with resulting work implemented immediately or added to
the team’s backlog.
Having Ops engineers attend our project team retrospectives means they can
also benefit from any new learnings. Furthermore, when there is a deployment
or release in that interval, Operations should present the outcomes and any
resulting learnings, creating feedback into the product team. By doing this,
we can improve how future
work is planned and performed, improving our
outcomes. Examples of feedback that Operations can bring to a retrospective
include:
•
“Two weeks ago, we found a monitoring blind-spot and agreed
on how to fix it. It worked. We had an incident last Tuesday, and
we were able to quickly detect and correct it before any customers
were impacted.”
•
“Last week’s deployment was one of the most difficult and lengthy
we’ve had in over a year. Here are some ideas on how it can be
improved.”
•
“The promotion campaign we did last week was far more difficult
than
we thought it would be, and we should probably not make
an offer like that again. Here are some ideas on other offers we
can make to achieve our goals.”
•
“During the last deployment, the biggest problem we had was
our firewall rules are now thousands of lines long, making it
extremely difficult and risky to change. We need to re-architect
how we prevent unauthorized network traffic.”
Feedback from Operations helps our product teams better see and understand
the downstream impact of decisions they make. When there are negative
outcomes, we can make the changes necessary to prevent them in the future.
Operations feedback will also likely identify more
problems and defects that
should be fixed—it may even uncover larger architectural issues that need to
be addressed.
The additional work identified during project team retrospectives falls into
the broad category of improvement work, such as fixing defects, refactoring,
and automating manual work. Product managers and project managers may
Promo
- Not
for
distribution
or
sale
104 • Part II
want to defer or deprioritize improvement work in favor of customer
features.
However, we must remind everyone that improvement of daily work is more
important than daily work itself, and that all teams
must have dedicated ca-
pacity for this (e.g., reserving 20% of all cycles for improvement work, sched-
uling one day per week or one week per month, etc.). Without doing this, the
productivity of the team will almost certainly grind to a halt under the weight
of its own technical and process debt.
MAKE RELEVANT OPS WORK VISIBLE ON SHARED KANBAN BOARDS
Often, Development teams will make their work visible on a project board or
kanban board. It’s far less common, however, for work boards to show the
relevant Operations work that must be performed in order for the application
to
run successfully in production, where customer value is actually created.
As a result, we are not aware of necessary Operations work until it becomes
an urgent crisis, jeopardizing deadlines or creating a production outage.
Because Operations is part of the product value stream, we should put the
Operations work that is relevant to product delivery on the shared kanban
board. This enables us to more clearly see all the work required to move our
code into production, as well as keep track of all Operations work required to
support the product. Furthermore, it enables
us to see where Ops work is
blocked and where work needs escalation, highlighting areas where we may
need improvement.
Kanban boards are an ideal tool to create visibility, and visibility is a key
component in properly recognizing and integrating Ops work into all the
relevant value streams. When we do this well, we achieve market-oriented
outcomes, regardless of how we’ve drawn our organization charts.
CONCLUSION
Throughout this chapter, we explored ways to integrate Operations into the
daily
work of Development, and looked at how to make our work more visible
to Operations. To accomplish this, we explored three broad strategies, including
creating self-service capabilities to enable developers in service teams to be
productive, embedding Ops engineers into the service teams, and assigning
Ops liaisons to the service teams when embedding
Ops engineers was not
possible. Lastly, we described how Ops engineers can integrate with the Dev
Promo
- Not
for
distribution
or
sale
Chapter 8 • 105
team through inclusion in their daily work, including daily standups, planning,
and retrospectives.
Do'stlaringiz bilan baham: 
