Brett Cannon

Hello and welcome. My name is Brett Cannon, and I am joined today by John Ediger. We are here to share with you an experience report and our experience around implementing DevOps at Aflac.

A little bit of introduction around us and our roles. Aflac is a Fortune 500 company, and many of you know of Aflac, but we provide financial protection, supplemental insurance for about 50 million people worldwide. When a policyholder gets injured or sick or hurt, Aflac pays cash directly to the policyholder in an effort to help them and give them cash back in their time of need. Aflac operates primarily within the U.S. and Japan. We're actually one of the largest supplemental insurance providers in Japan, which sometimes is not well known about Aflac.

My role: I'm a senior manager within Aflac. I've got about 20-plus years of experience as a leader and executive within IT, and a little over a year and a half ago I joined Aflac as a DevOps strategy leader with the goal of helping to implement DevOps as a part of our digital transformation within Aflac. When I joined Aflac and got my arms around what was going on within Aflac, I realized that we needed some outside experience, some outside help to help us set up an enablement team and do some coaching to get this really going. So I reached out to John with DXC and brought him and his team in to help us in our journey as we started down this path of implementing a true DevOps practice within Aflac.

John, do you want to introduce yourself and your role?

John Ediger

Yeah. Thank you, Brett. John Ediger. I'm with DXC. For those that don't know DXC Technology, it's the world's leading independent end-to-end IT services and solutions company. We provide customers with everything from IT outsourcing, cloud capabilities, application services, analytics capabilities, advisory, so a whole host of things, many more than that.

My role in DXC: I'm a senior leader focused on DevOps and Agile transformation, and I'm also a distinguished technologist. I've got over 25 years industry experience in various leadership roles. Essentially what I do now is I work with various organizations or customers to help them in their DevOps/Agile transformation journeys from the executive level down to the working-team level, focused on business outcomes.

Brett Cannon

A little bit about what we're going to cover today. We'll walk through the challenge that we've gone after and what we're trying to accomplish. We'll talk about the key enablers that we put in place and the framework that we've now set up to really enable DevOps and Agile to help us in this digital transformation. We'll talk about progress and outcomes so far, and then the ongoing continuous challenges that we're trying to meet.

A little bit about the challenge and what we've faced here. When I first came into Aflac, there had been quite a bit of DevOps progress up to that point, and quite a bit that actually had happened, but there were a number of different things that we were facing as we really kicked in hard on this. One, as good a progress as there was, there were inconsistent results across the enterprise. We recognized that the best outcomes were coming from those areas that had strong leadership engagement, but in reality it was fairly inconsistent.

It was difficult for the teams to find time, to make time to continuously improve, and recognize that there was, and still is in many cases, more work than the people available. Our demand was far outpacing our capacity. The teams themselves were struggling with what turned out to be org-wide impediments that the delivery teams in and of themselves couldn't necessarily make progress on. In many cases, the teams themselves didn't quite know how to get started.

Those were the challenges that we faced when we first started down this path. So let's talk about some of the enablers and the path that we've started down. John, do you want to take us to the next?

John Ediger

Absolutely. We know from the DORA organization and the great authors of these books that you're all familiar with, we know that highly evolved, high-performance teams really focus on outcomes, business value, not just DevOps for the sake of DevOps or Agile for the sake of Agile, and that they continuously improve these four metrics here on the right, the throughput metrics and the stability metrics.

We also know that there's a predictive relationship. We know this from the great _Accelerate_ book, that there's a predictive relationship between these four DORA metrics and higher organization performance illustrated by these really outstanding numbers. There's a direct predictive relationship for those that focus on those measures to get results such as these.

There are also enablers for these high-performing organizations. These high-performing organizations continuously increase the autonomy and fast flow of their cross-functional teams, and this is known from years of our experience and experience of the gurus and the authors of the books that I mentioned here and that are shown below.

We have found that this requires four key elements. The first two are very related. This is about the culture and the discipline, both bottom up and top down. Not just using any DevOps/Agile patterns and practices, but those that address the top impediments toward the goals. This culture and discipline of continuous improvement, I like to illustrate this by some of the favorite quotes that we know and love.

You'll probably recognize and remember these from Dr. Steven Spear, who said that improving daily work is more important than daily work. Henrik Kniberg talks about the important thing is not your process; the important thing is your process for improving your process. Then one of my favorites here, Jonathan Smart, who, when we talk about how to get started and how to focus, says, "Impediments are not in the path; impediments are the path." That's one of my favorite quotes about focusing in on those top impediments.

If we look at the next two of these key requirements or key enablers to increase the fast flow of value, they include really getting the teams to be autonomous, to make changes that have minimal handoffs, approvals, blocking dependencies, and so forth, as well as having the teams be loosely coupled and having the architecture and the services that are developed being independently developed and released.

There are key enablers we are using with many of the customers we work with, including what we're doing here in partnership with Aflac, to help increase the fast flow of value. One of those includes value stream mapping. Many of you are familiar with value stream mapping. Basically, it's a collaboration with a cross-functional team looking at this end-to-end system of work, this end-to-end process. At DXC, we help our customers really nail this down into a five-step process that's identified here.

The second big enabler is the Team Topologies work, the great book on Team Topologies that you're all familiar with as well. There's a very powerful set of patterns and constructs, including the clear delineation of platform and enabling teams that help the stream-aligned or cross-functional delivery teams become more and more autonomous and able to focus on their fast flow of value.

Using these and many more of these enablers, we put together a framework. This framework is for continuous improvement that works in a two-tier model from the leadership level and the team level. We're going to spend a little bit of time walking through what that looks like.

The first key point on this is that we found this journey-of-journeys concept to be key. Rather than a one-size-fits-all, prescriptive, mandated single journey, we enable each team to own and drive results based on their specific goals and impediments. Each journey is not the same. Whether the team is managing a modern cloud-enabled app, a legacy app, an off-the-shelf app, mainframe, mobile, whatever the case may be, this DevOps journey concept applies. It's not a one-size-fits-all approach. It's based on where the team is, where they're starting, what they have, and then focusing on their impediments.

A couple of years ago, I published a paper on top anti-patterns that we see companies fall into when they try to do these large-scale DevOps and Agile transformation work. In addition to the big-bang anti-pattern, and the tools-and-methodologies-only anti-pattern, and modernization for modernization's sake, DevOps-for-DevOps-sake anti-pattern, one of the biggest ones we see is this one-size-fits-all one.

I'm going to walk quickly through this journey, how each team has their own journey, but it's based on the same process. The first is that the delivery teams, these cross-functional teams, allocate time for improvement. Whether that's one sprint per quarter, or whether that's a percentage of time each sprint or each time period, they focus on not just their feature work and their defect work and compliance work, but they build in time to focus on continuous improvement of their value stream.

The second key point here is that the team focuses on a set of outcome goals. This isn't DevOps for DevOps' sake. This is focused on business outcomes and OKRs, and then nailing down their four DORA metrics. What they do is identify what the top impediments are to achieving those metrics and then work down that backlog of countermeasures.

They get help from a DevOps enablement and DevOps platform team. We've got this set up now across Aflac. Basically, a couple of things these teams do, these coaches do, is they help advise value stream mapping. They help coach the teams. They also help run these dojos, and several of you are familiar with the dojo concept. We have our custom version of dojos, which is an immersive, week-long set of coach-led, hands-on-keyboard steps to implement some of the top countermeasures and focus on acceleration. Brett will talk a little bit more about some of the specific dojo results.

In addition to these enablement teams and platform teams helping, the core of this is, as the teams identify their top impediments to fast flow of value, they manage this in a Kanban approach and then run through a four-quadrant Improvement Kata pattern.

Real quickly, what that pattern looks like is they start with their current state, their current problem. They look at what the definition of awesome will be, maybe a year or two out, what the ultimate case would be. Then from that, they back that down to what's the next target condition they want to achieve through a set of hypotheses. Then they incrementally work with experiments and fast feedback to getting to that next target condition.

This is a mindset shift. This is a scientific discipline way of looking at continuous improvement, and that is a core part of this framework, this set of steps that each of these teams is on their own journey, but they follow this disciplined process. Now, Brett, why don't I pass it to you to go over a little bit of some of the results of some of the dojos that we worked with?

Brett Cannon

This is a summary of one of the dojos that we have done, and this is one of many. We've done many dojos now, and the success, the outcomes are very, very similar across the various dojos that we have run. You can see here on the left the epics or the work streams that we focused on in this particular dojo, one of them being around CI/CD pipelines, one of test automation, and then one, the final one, reducing our deployment time down to a zero-downtime environment.

You can see where we were moving from in each one of those areas and where we intended to go. It's important to recognize that the Kata process that John just reviewed was the going-in prep material for these dojos, where we really focused on what problem are we trying to focus on, what does awesome look like, the next target condition, which was the outcome of the dojo itself that we're trying to focus on. Then we did identify the steps that we would do in the dojo to realize the outcomes that we were going after.

It's also important to note, too, that in the dojo, it is hands-on keyboard delivering real value in the value stream for which the participants are focused on. When we come out, we've got things that are near ready, if not into production, for that value stream. We've made progress along the way to help them move faster, higher quality, less risk, et cetera.

In the three value streams in CI/CD pipeline, we were able to go from a long-time manual process to being able to elevate to the next environment within minutes. We were actually able to accomplish that in the dojo itself.

In terms of our test automation, again, lots of manual testing. Testing was being done as a separate phase itself, large lengthy feedback loops, and we cut that testing phase from two weeks, in many cases, to a few hours using continuous testing and some of the automation approaches that we applied.

In our deployment methods, we went from what was taking upwards of 40 hours over long weekends. We all know how much we love weekend deployments and whatnot, but we went from 40 hours of deployment down to a few seconds, less than a minute. We were able to get our deployment time down. In this one particular dojo, we achieved that within a week's amount of time with very focused, hands-on-keyboard, coaching-led teams that really were able to accomplish, get very immersive, and the success was absolutely amazing.

Leaders and the business themselves recognized the outcome, and we went from an environment where the business was saying, "I'm not sure that we need this. We know what we need to do. Let's just go focus on it. Why take the time to do it?" to one of the business leaders saying, "Can we do dojos every week?" The outcome was that spectacular and that amazing in terms of what they recognized, and now they, as business and our internal IT leaders, are asking for us to do more and more dojos.

As we started this whole effort and really started with what we call lighthouse value streams, there were a couple of things that we learned as we hypothesized and then verified our hypothesis that lead us into the next level of where we're trying to go.

In the beginning, we felt like and hypothesized that we could, through value stream mapping, pinpoint the biggest impediments within those value streams. Then using the process that John talked about before and the outcomes of the dojos and whatnot, we felt we could make incredible progress against our cycle time and our quality. We verified that indeed that was the case, and you can see some of the outcomes, the metrics that we improved: cycle time being reduced by 50% and MTTR by 60% on one of our claim systems. We reduced that deployment time for an agent system by 75%. We were able to reduce our manual tasks and the way in which we deployed roughly about 55% for one of our group management systems.

We significantly increased our quality throughput through automated testing and pipelines in all of our value streams, and we implemented across the lighthouse value streams a lightweight change management system that helps them to move through change management faster and even in a tighter way, but also showed the way for others.

But in doing that, we learned a few things. One, we all know that there are often, and we validated that there are, many journeys and journey categories that we started to go down. Each of them had common and yet very unique patterns when we talk about distributed and cloud, mainframe, off the shelf, et cetera. Common practices, but unique in terms of the category of the journey that they were on.

We recognized the need for platforms for the application teams to consume very quickly and easily what the platforms were providing, and that we needed to treat those as products. So we are on the journey now building more and more platforms that our application teams can consume and use.

Perhaps one of the biggest things that we recognized and have been putting a lot of effort into is the idea that efforts in this, if we're really going to make this part of our DNA and a true culture change, have to be sustained and led from the top. So we've been doing a lot of teaching and training our leaders and then getting stronger business engagement at the same time.

We've set up this pattern, and now John's going to lead us through. We walked through what the delivery teams are doing, and that's working very well. Now let's walk through what we're doing at the leadership level.

John Ediger

Yeah. As Brett was saying, that turns out to be really key to these transformations: having the top leadership be not only supporting this effort, but actively engaged and doing it themselves. Let's explain what that looks like. Both bottom-up and top-down are key. The bottom half of this slide, and I'll fill out the top part momentarily, the bottom half is what I walked through, this journey of journeys, this set of steps that the individual teams go through.

When they come across their top impediments, remember, impediments are the path, as Jon Smart says. Some of these impediments might be org-wide impediments, things that the individual teams, cross-functional teams, can't necessarily control or that's not in their purview. So one of the steps here is that if it is an org-wide impediment that they're looking at that prevents them from getting really fast flow of value, that gets kicked up to this enablement council, this leadership team of senior leaders.

A key part of the framework is that these leaders get training and that they understand a new way to think and to lead and to shift their mindset along the lines of servant leadership, that they'll help remove impediments for the team, protect time for these teams to do their continuous improvement. They can focus on this continuous improvement in the scientific, hypothesis-based manner, as well as transformational leadership. These guys become the role models. They coach teams on the process and set the vision.

When these org-wide impediments come up, this leadership team, this council, prioritizes those, looks at what the top impediments they're going to work are, and then they go through a similar process. These are some general examples of what org-wide impediments of companies might be. But they go through the same process of having a Kanban here at the org-wide level, and they use the same four-quadrant Kata process that we described that all the teams are using.

They're walking the walk, they're living this, they're modeling it, but they're really addressing the top impediments across the org. Let me pass it to Brett. You can talk a little bit about what some of this leadership training involves, which is a key part of this two-tier framework of the journey of journeys.

Brett Cannon

Yeah. We recognized that if the leaders are going to go from wherever they were to where they need to go and where we all want to go, and make this part of the DNA and the culture, the leaders need to be trained in this new way of thinking, this new way of operating. You can see here some of the topics that we've been working through with the leadership team, helping them understand what continuous improvement is and what's their role versus where it has been before. What's the Improvement Kata? How do we go down the platform and Team Topologies path? Psychological safety, et cetera.

You can see the things that we're working through, and we're not done in any way, but we have made great headway into this level of topics. We're running leadership training sessions now at least once a month, where we have the entire leadership organization together, and we're walking them through and training them with interactive breakouts and all that kind of work and way of training, and making great progress in getting our leaders to think in a different way.

A little bit about our progress so far and the outcomes that we've had. We now have our leaders very engaged, and they're driving. They're still learning, but they are engaged and actively driving. The workshop needs and the priorities around our value stream mapping and the dojos are now becoming leader-directed. When we first started, it was, "All right, here's our lighthouses." We go off and we execute. We did value stream mapping workshops, we did dojos, and we went back to leaders and said, "Okay, what's next?" Now it's turned the corner and they're coming to us and saying, "Okay, I think we need one here, and let's go there," and it's becoming more leader-directed.

The Improvement Kata is being embraced throughout the organization, and it is starting to become embedded in our culture, both at the leader level and at the delivery-team level. Lots of pushback, as one would expect in the beginning: "Why are we doing this? Not sure that I get it." Now it's becoming embraced and embedded in part of our culture.

In that very point, many of our delivery teams are now able to hit, and they're hitting our next target condition as a part of the Katas. They're updating and moving on and saying, "Okay, what's next? We've made progress. Let's go after the next target condition." Those are being realized and active progress is being made through those Katas.

The top org-wide impediments are being addressed now, working through those, just like John said, in that leader portion of the framework. Just like the way the delivery teams are working, the top org-wide impediments are being addressed.

That being said, there still is a lot of work to be done, and we hope we embrace the idea that we're never done. We will continue to address the top org-wide impediments and have the leaders' support through doing what's going on at their delivery-team level. That's a continuous effort that we're going under right now.

We're formally accounting for the continuous improvement process in our planning. As we plan year to year, and hopefully get shorter and shorter as we go, we're carving off time for each one of the teams to build in continuous improvement into their regular work.

We are working to train the rest of the leadership. We started with the executives, and we're working our way down through the rest of the people leadership. We're solidifying and using that training to put together and solidify the plan to scale DevOps practices and principles across our organization. It's not embedded in every team. It's on its way, and we're working to scale that across all of digital services, our IT organization for Aflac.

We'll continue then to build out our platform and our enablement team. While we have a lot of that in place, the work continues, so we will continue to work on that as we move forward.

Let me just close by saying this: I have and feel great excitement for how this is being embraced across the organization. Coming from the outside and having done this outside of Aflac and now watching the culture change that is happening within Aflac, not only am I excited, but I feel that excitement being infused throughout the organization, and people are seeing it. They're recognizing the capabilities and what this brings to the organization, and more importantly, how we can get better and better at delivering business value to our customers.

With that said, John, do you have anything else you'd like to say to close this out?

John Ediger

Just that this partnership between DXC and Aflac has been fabulous, and the business results that we're seeing, the culture change, the focus on top-down and bottom-up driving this change has been amazing, and it will continue to move forward.

I would just also say for all those listening, if you have any feedback, comments, anything that you're working on in your organizations that relate, that you can add to this continuous improvement of how we improve and how we do top-down and bottom-up combined journey of journeys rather than the one-size-fits-all, we'd love to hear from any and all of you. Thank you very much. Appreciate the opportunity to talk about this great journey of journeys at Aflac.

Thank you very much.