|
1.
Find Innovators and Early Adopters: In the beginning, we focus
our efforts on teams who actually want to help—these are our
kindred spirits and fellow travelers who are the first to volunteer
to start the DevOps journey. In the ideal, these are also people
who are respected and have a high degree of influence over the
rest of the organization, giving our initiative more credibility.
2.
Build Critical Mass and Silent Majority: In the next phase, we
seek to expand DevOps practices to more teams and value streams
with the goal of creating a stable base of support. By working
with teams who are receptive to our ideas, even if they are not
the most visible or influential groups, we expand our coalition
who are generating more successes, creating a “bandwagon effect”
that further increases our influence. We specifically bypass dan-
gerous political battles that could jeopardize our initiative.
3.
Identify the Holdouts: The “holdouts” are the high profile,
influential detractors who are most likely to resist (and maybe
even sabotage) our efforts. In general, we tackle this group only
after we have achieved a silent majority, when we have established
enough successes to successfully protect our initiative.
Expanding DevOps across an organization is no small task. It can create risk
to individuals, departments, and the organization as a whole. But as Ron van
Kemenade, CIO of ING, who helped transform the organization into one of
the most admired technology organizations, said, “Leading change requires
courage, especially in corporate environments where people are scared and
fight you. But if you start small, you really have nothing to fear. Any leader
needs to be brave enough to allocate teams to do some calculated
risk-taking.”
Promo
- Not
for
distribution
or
sale
60 • Part II
CONCLUSION
Peter Drucker, a leader in the development of management education, observed
that “little fish learn to be big fish in little ponds.”
By choosing carefully where
and how to start, we are able to experiment and learn in areas of our organi-
zation that create value without jeopardizing the rest of the organization. By
doing this, we build our base of support, earn the right to expand the use of
DevOps in our organization, and gain the recognition and gratitude of an
ever-larger constituency.
Promo
- Not
for
distribution
or
sale
Understanding the Work in
Our Value Stream, Making it
Visible, and Expanding it
Across the Organization
Once we have identified a value stream to which we want to apply DevOps
principles and patterns, our next step is to gain a sufficient understanding of
how value is delivered to the customer: what work is performed and by whom,
and what steps can we take to improve flow.
In the previous chapter, we learned about the DevOps transformation led by
Courtney Kissler and the team at Nordstrom. Over the years, they have learned
that one of the most efficient ways to start improving any value stream is to
conduct a workshop with all the major stakeholders and perform a value
stream mapping exercise—a process (described later in this chapter) designed
to help capture all the steps required to create value.
Kissler’s favorite example of the valuable and unexpected insights that can
come from value stream mapping is when they tried to improve the long lead
times associated with requests going through the Cosmetics Business Office
application, a COBOL mainframe application that supported all the floor and
department managers of their in-store beauty and cosmetic departments.
This application allowed department managers to register new salespeople
for various product lines carried in their stores, so that they could track sales
commissions, enable vendor rebates, and so forth.
Kissler explained:
I knew this particular mainframe application well—earlier in my
career, I supported this technology team, so I know firsthand that for
nearly a decade, during each annual planning cycle, we would debate
about how we needed to get this application off the mainframe. Of
Promo
- Not
for
distribution
or
sale
62 • Part II
course, like in most organizations, even when there was full manage-
ment support, we never seemed to get around to migrating it.
My team wanted to conduct a value stream mapping exercise to de-
termine whether the COBOL application really was the problem, or
maybe there was a larger problem that we needed to address. They
conducted a workshop that assembled everyone with any account-
ability for delivering value to our internal customers, including our
business partners, the mainframe team, the shared service teams,
and so forth.
What they discovered was that when department managers were
submitting the ‘product line assignment’ request form, we were asking
them for an employee number, which they didn’t have—so they would
either leave it blank or put in something like ‘I don’t know.’ Worse,
in order to fill out the form, department managers would have to
inconveniently leave the store floor in order to use a PC in the back
office. The end result was all this wasted time, with work bouncing
back and forth in the process.
During the workshop, the participants conducted several experiments, in-
cluding deleting the employee number field in the form and letting another
department get that information in a downstream step. These experiments,
conducted with the help of department managers, showed a four-day reduction
in processing time. The team later replaced the PC application with an iPad
application, which allowed managers to submit the necessary information
without leaving the store floor, and the processing time was further reduced
to seconds.
She said proudly, “With those amazing improvements, all the demands to get
this application off the mainframe disappeared. Furthermore, other business
leaders took notice and started coming to us with a whole list of further ex-
periments they wanted to conduct with us in their own organizations. Everyone
in the business and technology teams were excited by the outcome because
they solved a real business problem, and, most importantly, they learned
something in the process.”
In the remainder of this chapter, we will go through the following steps:
identifying all the teams required to create customer value, creating a value
stream map to make visible all the required work, and using it to guide the
teams in how to better and more quickly create value. By doing this, we can
replicate the amazing outcomes described in this Nordstrom example.
Promo
- Not
for
distribution
or
sale
Chapter 6 • 63
IDENTIFYING THE TEAMS SUPPORTING OUR
VALUE STREAM
As this Nordstrom example demonstrates, in value streams of any complexity,
no one person knows all the work that must be performed in order to create
value for the customer—especially since the required work must be performed
by many different teams, often far removed from each other on the organization
charts, geographically, or by incentives.
As a result, after we select a candidate application or service for our DevOps
initiative, we must identify all the members of the value stream who are re-
sponsible for working together to create value for the customers being served.
In general, this includes:
Do'stlaringiz bilan baham: |
