Nationwide Mutual Insurance Co.'s IT function is in the midst of a major cultural shift. The CIOs at the insurance firm have married Agile and Lean practices and are applying those practices across the entire organization -- from front-line software developers to senior-level executives.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Agile -- working iteratively rather than sequentially -- is often cited as an important characteristic for digital transformation efforts. And Lean practices, which stem from Lean manufacturing methods pioneered by Toyota, have often been applied to IT departments looking to eliminate waste. But the Lean/Agile story at Nationwide isn't just about reforming how work gets done; it's also about how work gets managed.
In this SearchCIO Q&A, Guru Vasudeva, senior vice president and CIO of program and application services at the insurance firm in Columbus, Ohio, describes the rigorous practices of the department's Lean management system and how he's measuring the economic value it brings. Spoiler alert: It's paying off big time.
One thing to note: The IT department at Nationwide is centralized, so IT resources are pooled. Vasudeva said centralization is a helpful -- but not necessary -- organizational structure for a Lean management system to succeed. What's more important is IT alignment so that the same practices are implemented across the board.
This interview has been edited.
What is a Lean management system? And how does it work?
Guru Vasudeva: The Lean management system is a set of practices that managers, directors, executives and CIOs should embrace that helps us manage the production system using Lean techniques. For that we use primarily four practices:
- Leader standard work. If you ask me, 'What does a CIO in application and program management services do?' I have a checklist that says what I'm expected to do every week, every month, every quarter. I do a self-assessment on them and then I publish it to the whole organization. That helps to make it clear to people what a leader is expected to do. I expect the same thing from my direct reports, and they expect the same thing from their direct reports.
- Visual management system. We have about 25 big blue-chip programs going on across the company. Every week, I and my leaders -- the head of project management, the head of software development, the head of requirements and testing -- look at how we're delivering on those projects and what roadblocks we can remove as a leadership team. We have a board in a conference room where the top 25 programs are listed, along with [questions such as]: What is the standard? How is the staffing? How healthy is the leadership? Are there any technical issues? Are there any cross-boundary issues? It's not in a report that comes out every month in a spreadsheet nobody looks at. Instead, there is collaboration.
- Accountability board. All of the big things I ask my direct reports to do -- these are VPs that have large teams and global responsibilities -- are managed using an accountability board. It tracks what they're working on, if they're focused on delivering projects or continuous improvement, if there are deliverables due to the board or to external stakeholders, and if there are any people issues. We spend 20 minutes on that topic every week.
- The gemba walk. In Japanese, gemba means "where the work happens." The idea originated from manufacturing. Before manufacturing departments embraced Lean, managers would sit in their offices, they would have some kind of report and that's how they would manage the production. But they never visited where the work was happening. That's why you hear about the disastrous quality challenges the auto industry had in the '80s and '90s compared to Toyota. The idea of the gemba walk is that you, as a leader, have to routinely visit where the work is happening. Doing so takes the emphasis off of who is the most productive employee and places it on what is the most productive process. All of my directors are expected to visit the software development team every day. All of the executives who manage those directors are expected to visit those same teams at least once a week. And my direct reports, my VPs, are expected to do random checks across their large teams.
In another interview, you listed scaling the program and quantifying the economic value as two challenges, but you didn't elaborate on how you overcame those challenges. Can you explain how you did so here?
Vasudeva: We did small experiments first and we built momentum. It worked in small Agile teams, and we thought if it works in small Agile teams, can similar practices of bringing Agile and Lean together work with project managers? How about how we collect requirements? Does it have to be six months of documentation floating around in emails or can you actually get it done in two weeks by bringing the key stakeholders in a room to work through the key decisions? We started with small experiments, we got buy-in from early adopters and then we kept on building the momentum. And then we challenged ourselves: If it works here, why can't it work everywhere?
How about measuring the economic value?
Vasudeva: It is different in different types of work. You have to know the value stream. So, for example, in the case of software development, we use three different metrics to measure our economic value:
- Productivity, which is the number of lines of code you produce [and] how much effort in labor hours it takes to produce it.
- Quality. How many defects are you introducing? And we compare that to what we used to do before introducing all of Lean and Agile practices.
- The hourly labor rate. My hypothesis when we started this was if we had standardized processes across the software engineering lifecycle, we could leverage entry-level talent to do a lot of the work. That's a great way to infuse new energy into the company.
We have proven that, indeed, it is possible, and, as a result, you can have an hourly labor rate that is balanced. Last year, I tracked around $28 million of annualized savings just from software engineering.
How Lean principles can benefit IT
Palo Alto CIO embraces The Lean Startup
Lean thinking is key to innovation