How Johnson & Johnson embraced agile to drive digital transformation

Stuart McGuigan is no stranger to transformations. The longtime IT leader and 2018 inductee to the CIO Hall of Fame has blazed a trail of change in his leadership roles at Liberty Mutual, CVS and Johnson & Johnson.

Since joining the health-care giant in 2012, McGuigan has transformed J&J’s IT using agile development processes. He’s also reduced IT cost and complexity by migrating many of the company’s legacy on-premises systems to a hybrid cloud.

CIO.com recently spoke with McGuigan about that journey — including the importance of design thinking and data science, and why change management programs for agile are a clear sign of poor strategy, planning and communication. This is an edited version of that discussion.

You talked about your agile transformation in the context of “putting a rocket on the back of a go-kart.” Why did you need a rocket-powered go-kart?  

There’s no such thing as technology strategy — there are only business strategies with a technology component. Agile needs to be in the context of a business strategy, and a business purpose.

The most important thing is knowing why you’re doing something. For us, that’s serving customers, serving patients, serving the needs of the health-care community. As long as that is the steering mechanism, then agile will power speed to value. If you think of agile as a technology strategy, then you’re putting in a mechanism to deliver capability very fast, but you don’t have the mechanism to make sure you’re aimed at the right problem. That was the idea of attaching a rocket to a go-kart: You have to go fast, but in the right direction.

We didn’t have any rocket-powered go-karts here. We have a very federated model — we are highly and deeply embedded in our businesses. We look for leverage where leverage makes sense. So, we think globally and act globally. Everyone says that, but we’re actually organized around doing that. And as a by-product of that, we are purpose-built for agile.

In agile, you have deep business engagement in the technology development process itself. You have business product owners who are part of the self-directed teams. Then everything you do is constantly validated against business value. If you’re down to two-week sprints, the worst case is you take two weeks, and you find out it didn’t accomplish its purpose. Oh well, you lost two weeks. You’re not going to lose a two-year project you spent a year planning. It deals with the dilemma of sunk cost in a way other methodologies don’t.

Johnson & Johnson

Because we are federated and embedded in our businesses, we automatically have the steering mechanism, but now we have a better engine behind it to deliver value faster. As that emerged, we saw — without really changing our software development lifecycle, existing staff and business partners — that we were able to deliver quite the value in half the time. 

You also talked about the “virtuous cycle of innovation.” What does that mean to you, and how does it relate to the agile transformation?

J&J appointed a chief design officer five years ago. It was a recognition that we needed to better understand the journey — our customers’ journey, our own employees’ journey—and that we needed to provide more than point solutions. We needed to understand the context.

The virtuous cycle is understanding your customer — and in many cases, that involves bringing in design thinking. If you’re treating a diabetic, it’s not just about the diabetes, but the entire journey.

You combine that with data science so that you have a much better understanding of your customer, and a much better understanding of what’s happening in the health-care system that you’re supporting. And then you use agile to do short sprints to essentially deploy and test new ideas. You know the business value you’re trying to create, because you have your business strategy and design thinking. You know the measure of success, because you have data science, and now, increasingly sophisticated modeling. And you have the ability to perform and try different approaches to engaging customers. Now, the distance and time between an insight and having something in front of consumers or patients to see how much you’re helping them happens in weeks.

The difference between change and “difficult change”

Some leaders run change management programs as part of agile transformations. You don’t believe in that. Why not?

If we’re deploying technology, and we think we need a lot of change management and influencing, we might not be developing the technology people want to use. That’s where the design thinking comes in. If it takes you more than a few seconds to figure out how to use a new app on your phone, what do you do? You get rid of it — you don’t sign up for a whole bunch of change management.

There’s the old belief that people don’t like change. That’s too simplistic. People don’t like difficult change. They don’t like uncertainty. But everyone likes change that makes it easier to be successful, that makes their jobs easier, that creates a compelling experience.

So, we’ve brought design thinking to developing our internal services and internal applications. It’s not just user-interface design expertise, but the real understanding of what people are trying to do, and how it fits into their daily lives. If you do that right, when you launch a new capability, there’s a pull — there’s no need to push. We just need to be able to explain what it is, give people access to it, and they’ll go tell each other about it. When you create experiences that delight the user, that is your change-management mechanism.

You also had to push back on the desire for standardization. How did you handle that, and how do you continue to do that?

What can happen anywhere — particularly at a big company — is we start to think of the means as the end. The goal is one change management process. So we inflict one process on everybody, whether it makes sense or not. And we forget the reason why we’re doing it. We need to always bear in mind what is the value of what we’re creating.

We could roll out a standard manufacturing execution system. We standardize because we think it’s a faster, better, lower-cost way to do it. But it has to be faster, better, lower cost for the business, for the manufacturing plant. And we have to measure the results not in terms of percent standardized, but in, did we produce higher-quality products faster, with better economics? We might have done that in part because of standardization, but standardization is not the goal—standardization is the means to achieve a goal.

If you keep the metrics in mind, then you won’t have senseless standardization. You’ll have it where you need it, but where it makes sense to not be standard because it creates better business value, you should be completely open to that. 

Big wins include hybrid cloud, analytics 

What have been some of the big wins?

We’ve had a number of them. One of the early ones was funding our transformation of legacy infrastructure to hybrid cloud. This was the only project, in my experience, where we put together the business case and got support such that it was funded over and above the IT budget. Usually most things in IT are self-funded. The company invested in this journey and stuck with it. So, over a four-year period, we were able to move from almost no cloud footprint to more than 80 percent of our workloads running in hybrid cloud.

There’s an example of faster, better, lower cost. But also more and better compliance, because we automated provisioning. We have 100 percent compliance on new systems validation. We scan our environment every 15 minutes, so we have a better security posture. We’re better able to align to business growth or changes in demand because of cloud pricing. It sounds like a very technical project, and it is, but it required business engagement end-to-end to support it and invest in it, and the ROI has been tremendous — it exceeded the original proposal. That’s given us a foundation for having the flexibility to be able to grow from a compute and infrastructure capacity perspective.

The next thing was agile—the ability to really align to the way our businesses think and operate: Smaller squads, tight alignment, sitting with business partners wherever possible. One of my favorite things to hear when I visit a team is when you can’t tell who’s from infrastructure, who’s from development, who’s from business, because they’re all so unified in their purpose.

The third thing that has been tremendous has been fostering a data science capability throughout the enterprise. I’ve had the privilege of helping to shepherd that, with support from our executive committee. We’ve established world-class data science groups [across Johnson & Johnson]. Those are now fairly mature organizations that are helping transform the way we look at what we do using natural language processing, machine learning, and other advanced analytics. Those are enabled by a good technology strategy, but they are really part of our model of keeping the technical people who create value as close to the business — and therefore as close to the customer — as possible.

What advice can you offer for other CIOs on leading through the agile journey?

Start with a community of the willing and interested. Agile itself is about small, independent teams. So, deploy agile using agile. Don’t use a waterfall, change-management approach to implement agile. If you try to do everything simultaneously, you’ll only go as fast as the slowest adopter.

The wonderful thing about being part of a company like Johnson & Johnson is that we have so many businesses in so many regions, so it’s not hard to find a partner who is at a point in their journey when they want to try to do something new — whether it’s agile or data science. We partner with them, making sure we really understand the “why,” and then over-manage the success. Take that team, and then do two more, and four more, and eight more — agile grows best organically and by a pull strategy, not a push strategy. So far, that’s been very successful.

One of the reasons it’s been so well received is that we haven’t had to a do “change management” project for agile. With the right groups at the right time, they’re ready for it, and a little bit of agile goes a long way in accelerating time to value.