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.
Stay current on your favorite topics
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). I’ve always found that both are required.
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.
What your business needs to put in place if it wants to be agile, fast, and digital
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 relationship-management staff.
