How to go agile enterprise-wide: An interview
Successfully
scaling agile starts with a strategy that’s consistent from the front lines to
the C-suite.
Adopting agile ways of working is
easier said than done. It requires cultural
change, well-balanced teams, and buy-in across the organization in order to
succeed. Scott Richardson, chief
data officer at Fannie Mae, shares his insights about going agile with
McKinsey’s Khushpreet Kaur.
McKinsey: What are some successful strategies that have
worked to actually scale agile?
Scott Richardson: To start with, I recommend a central Agile CoE
(center of excellence). Everyone brings their own flavor of agile to the table,
and arbitrary differences can slow you down in the early days of a transformation.
The CoE is useful in standardizing vocabulary, best practices, etc., to bring a
useful level of consistency. Central seed funding is also helpful, as it’s
often necessary to bring in expert coaches to jumpstart the process, and most
local groups don’t have the means to fund their own coaches. The CoE can share
the coaches across the organization until such time as the gains from effective
agile practices can self-fund the program on a broader scale.
The CoE also plays an essential role in
establishing training programs and assessing organizational maturity with
agile, and it can provide important guidance on more substantial changes, such
as revising an existing SDLC (systems development life cycle).
I like the approach of starting small—one
to three teams, with the right leaders and people— because this allows you to
focus your energies on getting it right. It’s very important that the early
teams are successful, because they become beacons that attract others and prove
that it can work here. Also, with the early teams you will encounter difficult
organizational issues, and it’s important to overcome many of them early on,
because subsequent teams won’t fare well until you clear the big boulders from
the road.
Another key to scaling is creating two
communities of champions. At the lower to middle level, local champions can
learn from each other’s experiences and build off each other’s energy and best
practices. This is a very productive way to shift the local culture and
encourage self-sufficiency in overcoming hurdles. But you also need champions
at the executive level. You need executives to promote it actively in their
areas. This is what ultimately moves the late adopters.
One simple technique for creating
executive champions is for the CIO or other top executive to track one simple
metric: the number of agile teams per division or business unit. You’ll find
that if a C-level executive reports on this in the monthly business review, it
won’t be long before the divisional or business unit leaders naturally compete
to have the most agile teams. That kind of productive peer pressure creates a
real incentive to drive change.
McKinsey: Who needs to drive an agile transformation?
Scott Richardson: There is debate in the industry about whether
you’re better off driving an agile transformation from the bottom-up (activity
on the front lines) or from the top-down (upper management steers the
process).
Bottom up requires local leadership on the
ground and teams that are forward-leaning and energetic. But that will only get
you so far, because ultimately they will run into the broader constraints that
exist within the rest of the organization, which are beyond their ability to
change. And people won’t overtly oppose an agile program, but you’ll frequently
encounter passive opposition, especially in the middle ranks.
To work through this, you absolutely need
top-down support at the highest levels to achieve broad and lasting change.
This often doesn’t require much more than a public endorsement at first. Then
as you begin to scale, the continued clear, public, top-level support creates
an environment where agile is allowed, encouraged, and inescapable.
McKinsey: How did you select your early agile teams?
Scott Richardson: Creating a new team is probably the most important
thing managers can do, so make sure you get it right. When we created our
initial agile teams, I was personally involved with structuring them and
selecting team members. It might sound crazy to get so involved in this level
of detail, but it is critical that the early teams become true beacons for
success.
I led the management team through a series
of discussions about the team’s business objectives, scope of work, and what
cross-functional skills were needed. We chose people with the right mix of
skills, seniority, attitude, etc. We created teams that were set up for
success. By the fourth or fifth team, my direct reports knew what questions to
ask and how to structure a proper team, and they could scale up on their own
from that point forward.
I’ve seen environments where teams were
formed based on whoever was available or was on the last waterfall project, and
most often it didn’t lead to success. The teams had to be reshaped within a
couple of months.
As a leader, it’s important to model the
right behaviors early on as well, such as paying attention to what’s important,
ceding authority and responsibility to those doing the work, teaching people to
be self-sufficient, and stepping out and letting go from there. But being
active in the early days is very important.
McKinsey: How do you drive cultural change in an
organization?
Scott Richardson: Culture isn’t something you can change
directly—you can only impact it indirectly; it’s the result of process and
behavior change. For example, as you scale your use of agile, you’ll hit crisis
points, and your response in these moments can have a great impact on the
culture.
It’s human nature in these crisis moments
for people to do what they’ve done before, which often isn’t the agile way. And
it’s in those moments of crisis that a leader can step in and help them find
the right way through the problem. When the next crisis arrives, they will have
new methods and behaviors that reinforce the target culture rather than
undermine it.
I remember a moment in the early days of
our transformation when, during cross-team planning, several teams realized
they were not able to deliver some really important capabilities within the
desired timeline. This was a huge, highly visible timeline, so people were
panicking. Some of my very best new agile team leaders offered to throw more
people at the problem “just this once,” to crash the schedule like they did in
the old days. They sensed this wasn’t the right answer and invited me to step
in and give the blessing to their proposal or suggest something else.
It’s in those moments that you need to
model confidence in the agile method, to be the calm in the eye of the storm,
and say, “No, what you need is to go back to your product owners, who are
managing the priorities and sequence of work, and say, ‘This isn’t working, so
what are you going to do about it? This isn’t a technology problem, this is a
prioritization problem. What is the MVP (minimum viable product)?’” And sure
enough, after some initial wringing of hands, when the product owners saw that
what they wanted wasn’t going to happen, they quickly identified a revised MVP
that was achievable by taking a hard look at what was really needed, cutting
out extraneous requirements and features, but that still delivered the core
customer value. Within a couple of hours everything was back on track with
planning, and ultimately all the teams delivered, and the external customer
delivery was on time.
That story has become a part of our
organization’s lore now: “Remember that crisis and we ended up doing the right
thing, the agile thing?” Now they carry this story with them, and they are
empowered to solve problems and make decisions in truly productive ways. It’s
part of the culture.
McKinsey: How do you manage the various maturity levels of
agile teams?
Scott Richardson: In any company I’ve ever worked for, we’ve always
looked at external examples but then defined internally our own agile maturity
matrix. Here at Fannie Mae, we have a four-stage maturity progression. We use quarterly
or semi-annual independent assessments to determine how many teams are at level
one, how many at level two and so on—this is another useful function of the
Agile CoE. Understanding the maturity level of each team helps us make sure we
are making the right decisions enterprise-wide and determine what further
support is needed—for example, more training, more coaching, different
managers, etc.—for each of the teams.
I find it useful to use a tool that
provides very detailed and insightful team-maturity metrics. Although aggregate
results are shared outside the team, the specifics are for the team only and
provide really rich feedback across some 16 different dimensions. Having this
level of assessment is important so teams can see where they should move
forward, why it’s good to move forward, and what benefits we get from moving
forward. This all encourages team members to own their own growth; it’s part of
the culture we encourage.
McKinsey: What did you do to encourage your agile teams to
focus on customers?
Scott Richardson: My current role here at Fannie Mae is a data role,
which by definition is not a customer-facing function. But from my previous
role at another firm, customer-centricity was central to the agile
transformation. It’s a huge shift. At that previous company we thought in terms
of accounts, not people. And so the big transformation was to recognize that we
are in a people business, that our customers are humans with their own personal
journeys, and that we’d do well to obsess over how we could help them have a
better human experience—which by the way wasn’t always directly related to the
business we thought we were in. But these adjacencies that created a better
human experience for our customers became competitive differentiators for us.
To achieve all this we needed to change
the structure, goals, and compensation and rewards for our front-line staff,
and we infused the entire company with an obsession for the customer by
explicitly changing the language we used for internal company dialog.
Although agile is a fabulous improvement
over what we had, its various modes of implementation (e.g., Scrum) are not
perfect. For example, product owners do not always have all the answers.
Frequently they do not have better [customer] insights nor better ability to
prioritize than any other team member. Where possible, a better approach is to
have the teams interact directly with customers, for example to codesign
products and services with them using design thinking. It’s truly amazing the
insights you can get, and the superior products you can build, when you use
human-centered design like this. The insights from direct customer observation
or cocreation are far superior to relying on customer-survey results or the
opinions of our
August 2017 http://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/how-to-go-agile-enterprise-wide-an-interview-with-scott-richardson?cid=other-eml-alt-mip-mck-oth-1708&hlkid=cbf784a13c9548169759d63f26653758&hctky=1627601&hdpid=f4047397-c6c0-4bd8-8055-dc397a353008
No comments:
Post a Comment