Allen Bernard - October 22, 2018

Lean, Agile, and DevOps: the trifecta for powering innovation

Stephen Farley

Allen Bernard recently caught up with Steve Farley, Nationwide's vice president of software development, to talk about how he and his teams are using Agile, DevOps, lean manufacturing techniques, and even CMMI certification to keep the company competitive in the fast-shifting digital marketplace for insurance.

Steve, even though Agile has been around for the better part of two decades, it still seems like companies are only now adopting it en-masse. Why Agile and why now?

Well, the "why now" is interesting. We've been on our Agile journey for much of that 17 years. It started around 2006 as we were coming out of the RUP [Rational Unified Process] era. And, if people know the emergence of Agile, a lot of that early iterative development came from what we know as RUP. In about 2008 we said, "There's an opportunity here," and we harnessed the energy of those [first] 10 teams and brought them together in our first Nationwide Application Development Center.

So Agile's been coming at us fast for many years and we’ve had great teams that were early adopters. We actually have maturity models. We were one of the first, and maybe only, financial services organizations that married up lean [manufacturing] and agile principles, and we actually went out and got ourselves CMMI level three certified back in 2012 and 2015. Those certifications are based on agile team principles.


How do CMMI, which I have not heard anyone talk about in years, and lean combine with Agile?

We talk a lot about lean principles plus agile principles and now we talk about the third leg, which is the leg we're on—lean plus agile plus DevOps.

DevOps is now the guiding principle of a lot of organizations. That’s because DevOps started with that Agile mindset and that Agile manifesto and then started to extend the boundaries of traditional Agile teams and move more into true business agility. We adopt a lot of the lean principles outside of our Agile software teams to determine how we want to guide the organization. That goes all the way through the C-suite—How do we use lean management systems? How do we use lean problem-solving principles? How do we do the basic cadence of a lean organization? So it's more about applying the lean management system while the Agile teams are using Agile for our software development.


Can you do DevOps effectively if you're not doing Agile?

Absolutely not. DevOps spawned from Agile. It was actually coined by a Belgian who happened to be at an Agile conference. I think the year was like 2012. He said, "Listen, we need to extend the boundaries because we may be doing Agile software development, but we're not bringing in some of the concepts of the operational components." Meaning, how do we continuously deploy?

If we get into a continuous execution model … how do we get our business partners to flow work in an Agile manner? And then, on the back end, how do we continue to deploy with high-frequency releases and automation in our deployment?

A lot of companies adopted Agile at the heart of software development, but they may not have fixed the front end or the back end, which is where a lot of people land, which is what we call a "water-Scrumfall” mindset.


So, DevOps is the "book-end" for Agile?

Yes, it really is. I have two books on my desk called "The Phoenix Project" and "The DevOps Handbook." They are all about how to create world-class agility, reliability, and security in the organization. And at the heart of it, you have to get to Agile, continuous delivery, and three ways of doing work, which are based on the principles of flow, feedback, and continual learning. And then those are basically how people define DevOps.


What are the advantages of Agile? I'm assuming the other alternative is waterfall? It's either Agile or waterfall, right?

There are variations in between, like the one that I coined “water-Scrumfall” or “water-Agilefall.” A lot of teams are doing Agile in the middle of their development, but they're kind of "waterfalling" into the requirements. And then they're having big, monolithic releases once a year on the back end.


Okay. So, you can't do DevOps very well without Agile, but you can do Agile by itself. Out of everything that Agile has to offer, what are the main advantages?

If you truly look at what we're trying to achieve with both Agile and DevOps, it's speed, quality, reliability, and customer satisfaction. If you look through those lenses, both the Agile and DevOps principles are intended to, first and foremost, give us speed.

Quality, which is a key DevOps principle, is about automating at the point of every single build and every single iteration and testing automatically through those automation frameworks at those moments.

Customer satisfaction comes through the Agile concepts of full transparency, show-and-tell concepts, and customer collaboration where the customers are playing product owners. They're engaging in the software build as we actually build the solution, versus waiting to see the grand reveal at the end, which is the old waterfall mindset.


Do you have an issue with maintaining quality? I know that's a challenge.

We do quality well, but it costs us a lot. We are on a mission right now with a lot of our DevOps principles and the infusion of new tools and concepts to automate everything we do.

This includes test-driven development practices. It includes DevSecOps, which utilizes security-testing principles built into the development processes versus on the back end. So we're working on infusing all of that into our organization so that we can actually back off some of the high-priced manual testing.

And it also includes security testing. The whole DevSecOps, it's about shifting that into the build practices, into the Agile team, having those security scans run against the code at every build point and every iteration point.


What are the challenges you are facing with Agile?

Our biggest challenge is the front end, which is getting our funding stacked up, getting decision velocity and requirements laid out in a continuous flow from our business partners. If you look at that as the lead time for requirements, right now it is in excess of 200 days. While at the same time, by the time that card gets on the board, we can actually build the code in 22 days.


Okay. So if you have a project in motion, do these lead time for requirements play into that as well—if you have major changes, for example?

Absolutely. One of the things we should probably talk about is the definition of projects. The biggest challenge with corporate America moving to an Agile DevOps environment is, honestly, moving away from a project-centric culture.


The biggest challenge with corporate America moving to an Agile DevOps environment is moving away from a project-centric culture.

Stephen Farley VP,


If you're an Agile team building software and you're a large organization, you can end up running multiple projects that hit that same piece of software. So your Agile concepts can be eroded because you're running independent project silos or threads. One of the major DevOps principles is shifting away from a project-centric mindset to a product mindset, which says what matters most is the frequency at which we deliver this software product that adds value to our customers.

So instead of running 10 independent projects, how do we actually map the flow of work into that one single software product and release it on a very high-frequency cadence? The Googles and Amazons of the world are releasing hundreds of times, even thousands of times a day as they make adjustments and changes.


Can you give us an example of that?

Yeah. So at one point, I was the vice president of one of our business unit's IT organizations, and I owned a piece of software, let's say it was a record-keeping system. And it did all the policy administration for the retirement plans across the country. We had 10 different entities, businesses, and customers of ours that wanted changes to their retirement plans. The old way of thinking was to stand up 10 different projects, 10 different project managers, and 10 different architects and tech leads to solve that problem, when in fact they were needing work done by one single Agile team.

You can imagine the collisions that were created when you had 10 project managers who all felt like they owned the implementation date and were really dealing with one software team.

We had to change the mindset to say, "The Agile software team will take your input and they'll define your release cadence for when these enhancements make it to the street, because they know best how the software needs to be crafted and released to meet the needs of the customer." And that was a hard shift.


How are you capitalizing labor in Agile? I guess this is a bit of a challenge for people.

I don't think it's a challenge. I mean, we still use a capitalization model for all of our build funding, but what we had to do was shift the way our Agile teams actually post to those funding models. So, we have what we call a standing team concept that allows us to track the investment in our standing teams and then trace that back to our funding models so that we can then capitalize those. And that's where the project's interest comes in. We still fund the macro-project level and then we capitalize those projects.


But in Agile, you don't track hours, is that right?

We do, but here's what we do differently. We don't track hours by project for a standing team. We do standing team hours that then get allocated back to projects. And then those projects get capitalized.


Why do people struggle with this?

I think it’s a learning curve. That was a painful ride for us because we woke up exactly with what you're describing, which is like, "Wait a second. We don't want a bunch of people reporting hours to all these different projects when they're really working as a standing Agile team." And we had to fix our model and we had to come up with this way to track investment time when we're living in a standing Agile team model. So, we had to learn the hard way.


How do you know if you're getting business value from Agile?

There's always customer sentiment and feedback, but the question's a tough one because it's one of the hardest things to measure. You know, it's the old earned-value conversation, "How do I measure the benefits realization?"

Everything we build has to have an outcome for the business, which means it's either gonna drive revenue, increase policy sales, or those kinds of things. So all of our Agile team support those outcomes.

We do a pretty structured project model around benefits realization that says, "If we invest a million dollars, this is what we think we're gonna get out of it." But is that really telling us that we're getting the true value out of the implementation?


Right. But is Agile, as an approach, concerned with that? I don't think so.

Not so much. What I think Agile cares most about is customer sentiment and making sure the customer collaboration is occurring along the way. And if it's occurring properly through transparency, regular show-and-tells, and agreement on what the software should look like, then value should come from that. By default, you would assume you're achieving that value because you have integrated customer collaboration inside the Agile team via the product owner.


Last question: What’s next for you with Agile?

Right now, we're bound by an annual budget cycle. We would like to create a more fluid budget cycle based on how work is actually flowing to the teams.

In our classic corporate model, once a year we do annual budgeting, we stack up our most important investments/project, we fund them, and then we take off and run. And then at the end of the year, we either spent all the money or we didn't, based on how we were coming through the work. Then we'd start the cycle all over again.

We're looking to figure out how to create more fluidity in the funding cycle and in the consumption of that funding.

»Read next on Emerge:

Our site uses cookies. By continuing to use our site, you are agreeing to our cookie policy.

Accept & Close