Chapter 7 • 81
Amazon or Netflix, each service team is simultaneously respon-
sible for feature delivery and service support.
‡
With these three categories of organizations in mind, let’s explore further
how an overly functional orientation, especially in Operations, can cause
undesired outcomes in the technology value stream, as Conway’s Law
would predict.
PROBLEMS OFTEN CAUSED BY OVERLY FUNCTIONAL
ORIENTATION (“OPTIMIZING FOR COST”)
In traditional IT Operations organizations, we often use functional orientation
to organize our teams by their specialties. We put the database administrators in
one group, the network administrators in another, the server administrators
in a third, and so forth. One of the most visible consequences of this is long
lead times, especially for complex activities like large deployments where we
must open up tickets with multiple groups and coordinate work handoffs,
resulting in our work waiting in long queues at every step.
Compounding the issue, the person performing the work often has little
visibility or understanding of how their work relates
to any value stream goals
(e.g., “I’m just configuring servers because someone told me to.”). This places
workers in a creativity and motivation vacuum.
The problem is exacerbated when each Operations functional area has to serve
multiple value streams (i.e., multiple Development teams) who all compete
for their scarce cycles. In order for Development teams to get their work done
in a timely manner, we often have to escalate issues to a manager or director,
and eventually to someone (usually an executive) who can finally prioritize
the work against the global organizational goals instead of the functional silo
goals. This decision must then get cascaded down into each of the functional
areas to change the local priorities, and this, in turn, slows down other teams.
When every
team expedites their work, the net result is that every project
ends up moving at the same slow crawl.
In addition to long queues and long lead times, this situation results in poor
handoffs, large amounts of re-work, quality issues, bottlenecks, and delays.
‡
However, as will be explained later, equally prominent organizations such as Etsy and GitHub
have functional orientation.
Promo
- Not
for
distribution
or
sale
82 • Part II
This gridlock impedes the achievement of important organizational goals,
which often far outweigh the desire to reduce costs.
†
Similarly, functional orientation can also be found with centralized QA and
Infosec
functions, which may have worked fine (or at least, well enough) when
performing less frequent software releases. However, as we increase the
number of Development teams and their deployment and release frequencies,
most functionally-oriented organizations will have difficulty keeping up and
delivering satisfactory outcomes, especially when their work is being performed
manually. Now we’ll study how market oriented organizations work.
ENABLE MARKET-ORIENTED TEAMS (“OPTIMIZING
FOR SPEED”)
Broadly speaking, to achieve DevOps outcomes, we need to reduce the effects
of functional orientation (“optimizing for cost”) and enable market orientation
(“optimizing for speed”) so we can have many small teams working safely and
independently, quickly delivering value to the customer.
Taken to the extreme, market-oriented teams are responsible not only for
feature development,
but also for testing, securing, deploying, and supporting
their service in production, from idea conception to retirement. These teams
are designed to be cross-functional and independent—able to design and run
user experiments, build and deliver new features, deploy and run their service
in production, and fix any defects without manual dependencies on other
teams, thus enabling them to move faster. This model has been adopted by
Amazon and Netflix and is touted by Amazon as one of the primary reasons
behind their ability to move fast even as they grow.
To
achieve market orientation, we won’t do a large, top-down reorganization,
which often creates large amounts of disruption, fear, and paralysis. Instead,
we will embed the functional engineers and skills (e.g., Ops, QA, Infosec) into
each service team, or provide their capabilities to teams through automated
†
Adrian Cockcroft remarked, “For companies who are now coming off of five-year IT outsourcing
contracts, it’s like they’ve been frozen in time, during one of the most disruptive times in
technology.” In other words, IT outsourcing is a tactic used to control costs through contrac-
tually-enforced stasis, with firm fixed prices that schedule annual cost reductions. However,
it often results in organizations being unable to respond to changing business and
technology needs.
Promo
- Not
for
distribution
or
sale
Chapter 7 • 83
self-service platforms that provide production-like environments,
initiate
automated tests, or perform deployments.
This enables each service team to independently deliver value to the customer
without having to open tickets with other groups, such as IT Operations, QA,
or Infosec.
‡
MAKING FUNCTIONAL ORIENTATION WORK
Having just recommended market-orientated teams, it is worth pointing
out that it is possible to create effective, high-velocity organizations with
functional orientation. Cross-functional and market-oriented teams are one
way to achieve fast flow and reliability, but they are not the only path. We
can also achieve our desired DevOps outcomes through functional orienta-
tion, as long as everyone in the value stream views customer and organiza-
tional
outcomes as a shared goal, regardless of where they reside in
the organization.
Business
Units
Feature
Teams
Centralized
Operations
Users
Product Teams
Operations
Users
Platform as
Service
(optimized for speed)
(optimized for cost)
Each team opens ticket
to have code deployed
Server
team
Network
team
Database
team
VM
team
(optimized for speed)
(optimized for speed
and expertise)
Each team can
independently develop, test
and code into production
Ops management
Service desk
Platform team
?
Do'stlaringiz bilan baham: 
