Julia Davis is a former CIO at Aflac, Inc. She is currently an Apptio CIO Advisory Board member working to assist Apptio by evangelizing the value of technology business management to other CIOs.
Before joining Aflac in 2013, she was a CIO for a small specialty property and casualty insurance carrier, in Atlanta. She joined Aflac in time to drive the insurance company’s journey into Agile.
Thanks for your time today, Julia. Please tell me more about Aflac's Agile adoption story. Where were they when you walked into the process?
Aflac had been a classic waterfall, mainframe shop for decades. Our core policy admin system was called Life 70 because it was developed in the 1970s. So, traditionally, projects took a very long time to do, and they weren't major projects but were more minor changes to the existing system.
Too often companies will go out and build a quick-and-dirty application and then try and hook it into the legacy platform, not realizing that they add all these bolt-ons every time they have to change. Now, instead of having one system change, you have 70 systems to change. The timeframe to do new projects was quite lengthy.
Because of all these different touchpoints, it was complex. It was expensive in terms of change, expensive in terms of resources to test, especially with all the integrations.
Aflac didn't have much experience with Agile. It was a very traditional waterfall shop with projects averaging between 18 months and two years. Those timeframes didn’t address the speed of the market we were facing.
That drove the need for us to start to think about what we needed to do from an Agile perspective. Like a lot of organizations, Aflac had 21 number one priorities, and it was very difficult to focus on any one thing when you have 20 things going on simultaneously, that require your attention.
Our first effort at an Agile project was our “One Day Pay” initiative as a result of our CEO saying, "We've been processing claims in four days. What can we do to use technology to drive that down to one day?" Manually, we were getting it done within four days, how could we take that to one day without adding headcount?
When he originally asked me, I said, "Okay, it's going to take 18 months.” He was not too happy with that answer. He said, "Nope, that's not going to cut it. What's it going to take to get it done in a shorter time frame?" And I said, "We need to make this the number one priority. The other 21 number one priorities have to go to the bottom of the list. This is number one. We're going to do it differently and get it out like an Agile project. We’re going to run it so that we have business people dedicated to this project, IT people dedicated to this project, and it is not a part-time job. It's a full-time job. We are going to put them in a room together, so they are working the problem together, not throw it over the wall, wait six months, see what happens, throw it back, and see it looks nothing like how it was originally envisioned by the business stakeholders."
We were able to do that, get that group working together, and they were able to deliver the project in under six months.
It changed the whole perspective of the company to realize that Agile works. You do things to get that bang for the buck, focus on what you need to get out first, second, and third, make this your priority, and do it as a joint initiative between IT and the business.
Did you encounter any resistance from other business areas, departments, or groups?
Yes, initially, I think people were very focused on what their needs were, within their division. They didn't necessarily think about what the corporate need was. But when you have the backing of the CEO, it's very hard to turn down what he wants to do as the number one priority. That made it a lot easier to get them on board, to have that direct leadership driving this Agile change. That opened it up to folks saying, "Okay, this is our number one vision; we need to work on this together."
Some of our biggest detractors got on board, and it showed up in improved customer satisfaction scores. They could now see what the challenges were within IT. It wasn’t about the people. It was about money and priorities.
It opened their eyes to what was going on with IT and gave them more understanding of the outcome.
What challenges did you have moving away from waterfall?
The biggest challenge was starting to realize we were not going to try and bite off everything, make this big bang, like spending six to nine months getting all of the requirements. Instead, we now were trying to focus on what's going to give us the quick hits, the biggest returns upfront, and spreading it out.
It is about how can we get the quickest return, then move onto the next area where we would get the next return.
What benefits did Aflac gain from the move?
We saw a huge increase in our overall productivity. One of the metrics we look at in the insurance industry is the number of things you can accomplish from the IT department, divided by the total number of headcount.
It can be anything from a simple project to a quick fix, to a large project. It is generally a directional indicator.
When we first started that process, we were probably at half of what our peer group was doing. Maybe it would take us considerably longer to get things done, we had things in the queue that would take forever, and our developers couldn't get as much accomplished because of the complexity of some of the things they were doing.
As we moved more toward Agile, we saw the per head metric increase twelvefold. We were able to get a lot more accomplished, per headcount than previously.
How did that affect the enthusiasm with the IT department?
From an employee satisfaction and customer satisfaction perspective, we saw a huge uptick, almost double what it had been. The employees were feeling like they were accomplishing more, and certainly, the customers felt like we were accomplishing more in the timeframe. It was a huge win.
Once the internal customer started to appreciate what the employees were doing in IT, the IT employees felt like they were able to accomplish a lot more with their customers. So, it drove up satisfaction in both areas.
And your CEO was probably happy too?
Thrilled. We made it in time for the Grammy's, and they were able to produce the first commercial advertising with the Aflac duck advertising that we can settle claims in one day.
What advice would you give others in your situation?
I think they have to recognize that this is not a flip of the switch, where you go immediately from waterfall to Agile. It is a journey. Also, they're going to have to take several steps along the way. It’s best to take a sort of modified Agile approach in many cases when you're dealing with the transition from waterfall.
Start the process of learning the techniques, building the process, building the program, transitioning people out of roles of project managers to scrum masters, or product owners.
You're not going to be able to turn things on a dime. Make sure you plan for that transition because it isn't going to happen overnight.
Can you describe the differences between what a project manager role might be versus a scrum master?
Yes. It was interesting for us because it’s not always a one-for-one correlation. One of the things we discovered is that project managers gravitate well towards program owners or product owners. You need someone comfortable saying no to the customer, in a way that isn't going to seem standoffish but is realistic. Someone with the personality type where they know the good and the bad, and they know what can be done. They need to be good at helping to level-set expectations.
Project managers, when they come out of a very hierarchical structure of project team leader, often have a bumpy transition where they're coordinating these activities instead.
People who are good at being project managers may not necessarily be good at being a scrum master. They can be good as product owners because they're good at setting expectations for the customer and the business. They can say. "okay, this is what we can do, and this is what we can't do." It’s important to find the people that fit those roles.
One of the efforts we had to go through was doing personality profiles and assessments, understanding where is the best fit, and the right person for the right role.
Too often, mistakes happen where you put someone, that you think is customer-focused, in that product or role. And they’re yes men. They don't want to disappoint and say this isn't going to work. They don't necessarily work out, because you need more of a realist in there, helping set expectations around limited resources.
How does Apptio fit into the equation?
Apptio gave us visibility into many of our key reporting metrics. One of the metrics that we talked about was the productivity metric. We could dive into the requests per headcount based on the system and the resources assigned to work on those systems to establish baselines by technology stack. The data clearly showed that the more complex systems took longer throughout the development life cycle.
Rather than having an army of people developing the reports, you could use the tools to drive down the productivity metric and do team assessments based on improvement in performance over time. The reports gave us data-driven productivity metrics.
The coolest thing that happened among the teams when we moved to Agile is that if they felt like they had a partner that wasn't working too well or someone on the team who wasn't working too well, they pretty much helped that person move along. They didn't want to be held accountable to the weak link, and they usually were more effective in identifying the issues before the reports did.
Teams were much more effective in dealing with issues than perhaps the old waterfall method, where it may take months before you can get the poor performer out of the environment.
What haven't I asked about that you feel needs to be included?
Making sure as you're going through the transition to Agile that you do need to do those assessments and put the right people in the right roles. Too often in IT, particularly in the waterfall approach, we're very quick to promote, based on longevity and seniority. This happens because, to get the higher pay, you're going to want to put people into leadership roles.
You have to think about what the right personality is for that role and assess your organization to make sure you're putting the right people in the right positions.
Importantly, the whole comp structure has to be aligned with that. This is a process that you have to work intensely not just within IT but also with your HR organization and business leadership, so they understand you're going through that transition
Mainframe shops don’t automatically have to be waterfall. Ironically our mainframe guys adapted to Agile a lot faster than some of our other folks, because they found that there were benefits in the business understanding the complexity of what they were dealing with and that they couldn't handle doing everything at once. It turned out to be a win/win for everyone.