INTERVIEW – At the recent Lean Transformation Summit in Las Vegas, our editor sat down with Nationwide to hear more about the mutual company’s application of lean thinking to IT and how they are working towards getting 9,000 people onboard.

Interview with: Guru Vasudeva, SVP and CIO of Application and Data Services

Roberto Priolo: When did the lean journey of the IT department at Nationwide start, and how?

Guru Vasudeva: It started seven years ago, when I was CIO of one of the business units in the department. My predecessor was trying to create a standardized software development system that all of our business units could use, but that wasn’t our only challenge.

Several departments were starting to take on agile, but they were all doing it differently. It’s great to have diversity and creativity in our approach to development, but ten different ways to deal with projects were starting to create problems. Moreover, it seemed really wasteful.

We came up with the idea of bringing lean thinking and agile together – which meant standardizing agile practices and using lean to scale them. That’s how things began.

RP: What are the main difficulties of getting lean to work in an IT environment?

GV: The application of agile and lean to software engineering is not a new concept, but scaling it to include 25 departments and impact thousands of people is quite the challenge. So, I would say that the first difficulty is certainly scaling. Secondly, how do you quantify the economic value of lean? Without that, it’s hard to prove it is anything more than the initiative of one team. Finally, I believe it is very difficult to understand how to take the methodology and apply it across the board (outside software engineering and into help desk, for example).

RP: You have over 9,000 employees. What’s your approach to people development in such a large organization?

GV: While we mainly focus our efforts on Nationwide’s 5,000 employees, we need to make sure that the 4,000 temporary workers and contractors also receive training (they have to be on board and know the system).

We use a variety of techniques to develop our people. To begin with, we have created working units. The nexus of each unit is the team leader (called a scrum master in software engineering), who is tasked with developing and supporting others in the unit and ensuring standard work is deployed to developers and testers.

More recently, we have also started to pay more attention to our onboarding process, getting management more directly involved in it. Every quarter, my direct reports and I meet every newcomer for a day and help them get on board with the culture and the system. That’s how we reinforce the lean message.

We also have gemba walks, of course. Observing common problems and working with A3s is perhaps the most rewarding of all our people development activities.

In parallel, we spend a lot of time training people in different skills. We believe in the adult learning model: 70% of what we learn comes from on-the-job training, 20% from our peers, and only 10% from what we are taught in a classroom. That 70% that takes place at the front line is truly critical to us, and to facilitate it we have begun to pair people up – we use pair programming all the time, which encourages our people to take responsibility for their own development and to step in when their colleagues are not around. We even pair up managers as part of their own onboarding!

Our way of teaching is very organic. For example, we organize Teaching Thursdays, two hours set aside for teaching once a week (participation is entirely voluntary). Each week, we have between 35 and 50 courses; last year, a total of 10,000 people attended them! Our annual in-house technology conference is also quite successful: it sees hundreds of people come together for a day of learning – interestingly those who seem to get more out of it are the people who volunteer to teach!

RP: What have you been able to achieve so far thanks to lean?  

GV: We have been reducing defects in the software we develop by 50% year on year. We didn’t exactly focus on the goal, however. Instead, we established a new process to avoid mistakes: test-driven development. First, we write the testing scripts, then the requirements, and then we code. The fact that we already know what we are going to test for and that everything is written for that purpose makes all the difference in the world. We have now taken the new system one step further, automating it and scaling it to several teams, and that’s where the reduction in defects came from.

We have had a few surprises in 2013, which in business nobody really likes, especially when it comes to massive projects of strategic importance. So we focused a lot on preventing them from happening. One of the purposes of our newly developed lean management system is indeed to eliminate unexpected outcomes. Our people often told us they didn’t know how to escalate an issue, or that they felt they didn’t have to flag it up at all. We tried to encourage transparency and get the message across that nobody would be penalized for escalating a problem. We also removed roadblocks and taught people to look for patterns – if problem occurs in one place, how can we change the overall process to ensure it doesn’t occur elsewhere? These measures have had a tremendous impact, and we haven’t recorded any surprises since we introduced them.

RP: How does your approach to visual management reflect the lean management system?

GV: The culture we are trying to build is one of transparency, collaboration, and problem solving, rather than hiding issues or trying to look good at all costs. We are not perfect, of course, but we strive to continuously improve our system by reflecting and learning from mistakes. Visual management is critical to getting there, and it is an expression of our new way of thinking.

_{THE INTERVIEWEE}