Aflac DevOps Journey of Journeys (Achieving Enterprise-scal DevOps without the one-size-fits-all mandate antipattern) We know from Nicole Forsgren that “maturity models are for chumps” and that doing a one-size-fits all DevOps transformation is an antipattern. So how does an enterprise balance between the goal of broadly scaling DevOps and achieving rapid results with the reality that each part of the organization needs to customize and own their own approach? From this experience report, you will learn ways to successfully navigate the balance and synergy between rapid scaling of DevOps with team ownership of business outcomes. It is an experience report about our DevOps transformation journey at Aflac. Or should we say our journey of journeys, where we are enabling each group to go on their own custom journey while leveraging a DevOps enablement team, Value Stream Mapping, Dojos, DevOps Kaizen and a set of cultural and technical principals and patterns. We are then mixing this with a set of DevOps journey maps with typical patterns of adoption. It is about travels on a journey more like “Dora the Explorer” than taking the journey as a tourist.
Senior Manager - IT Core, Aflac
DevOps Transformation Principal, DXC Technology
Hello and welcome. My name is Brett cannon and I am joined today by John editor. And we are here to share with you and experience report and our experience around implementing DevOps at Aflac. And so 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. And so when a policy holder gets injured or sick or hurt, Aflac pays cash directly to the policy holder in an effort to help them and give them cash back, um, in their, in their time of need. And Aflac operates primarily within the us and Japan. We're actually one of the largest supplemental insurance providers in Japan, uh, which sometimes is not well-known about Aflac, but my role, uh, I'm a senior manager within Aflac. I get 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 dev ops strategy leader with the, uh, the goal of helping to implement dev ops as a part of our digital transformation within Aflac.
And when I joined in Aflac and kind of got my arms around, what's going on within Aflac, um, 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. And so I reached out to John, uh, with DXE and brought him and his team in to help us in our journey as we started down this path of implementing a true dev ops practice within Aflac. So John, you want to introduce yourself and your role.
Yeah. Thank you, Brett. So, uh, John Edgar, I'm with the ECC and, um, for those that don't know DFC technology, um, it's the world's leading independent and then it services and solutions company. So we provide customers with everything from it, outsourcing cloud capabilities, uh, application services, analytics, capabilities, advisory, so a whole host of things many more than that. Um, my role in DXE I'm, 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, um, in various leadership roles. And essentially what I do now is I work with, um, various, uh, organizations on our customers to help them in their DevOps, agile transformation journeys from the executive level, um, down to the working team level, focused on business outcomes.
So 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 dev ops and agile to help us in this digital transformation talk about progress and outcomes so far, and then the, the ongoing continuous challenges that we're trying to meet. So a little bit about the challenge and what we've faced here. When I first came into Aflac there's, there had been quite a bit of dev ops progress, um, 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, there was as good a progress as there was, there was inconsistent results across the enterprise.
We recognize that the best outcomes were coming from those areas that have 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. 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 could necessarily make progress on. And in many cases, the teams themselves didn't quite know how to get started. So those were the challenges that we faced when we first started down this path. Let's talk about some of the enablers and the path that we started down. So John, you want to take us to the next?
Absolutely. So the, um, we know from the door organization and the great authors of, of these, um, these books that you're all familiar with, um, we know that, um, that, that highly evolve high-performance teams really focused on outcomes, business value, not just dev ops for the sake of dev ops or agile for the sake of agile and that, that they continuously improve these four metrics here on the right, the throughput metrics and the stability metrics. And so we also know that that there's a predictive relationship. We know this from, from the great accelerate book, that there's a predictive relationship between these four-door metrics, um, and higher organization performance. So illustrated by these, these really outstanding numbers. So there's a direct predictive relationship for those that, that focus on those measures get results such as these, um, there are also, uh, enablers for these, these high performing organizations.
So these high-performing organizations, can you continuously increase the eponymous and fast flow of their, um, cross-functional teams. And this is known from years of our experience and experience of the, the grooves and the authors of the books that I mentioned here, and that are shown below. Um, we, we have found that this requires four key elements. Um, the first two are very related. These, these, this is about the culture and the discipline, both, both bottom-up and top-down so not just, um, not just using any dev ops, agile patterns and practices, but those that address the top impediments, uh, toward the goals. And so this culture, um, and discipline of continuous improvement, I like to illustrate this by some of the favorite quotes, um, that, that we know and love. Uh, so you'll probably recognize, and remember these from Dr. Stephen Sears, who said that improving daily work is more important than daily work.
Um, Henrik Nyberg talks about the important thing is not your process. The important thing is your process for improving your process. And then, um, one of my favorites here, Jonathan smart, who, when we talked about how to get started and how to focus, he says, impediments are not in the path. Impediments are the path. That's one of my favorite quotes about focusing in on those, those top impediments. So if we look at the next two, um, of these, uh, uh, key requirements are key enablers to increase the fast flow of value. Uh, they, they include, um, really getting the teams to be autonomous, to make changes that have minimal hand-offs approvals, blocking dependencies, and so forth, as well as having the teams be loosely coupled and having the, the, the architecture and the services that are, that, that are developed being independently developed and released.
Right? And so, um, there, there are key enablers we are using with, with many of the customers that we work with and including what we're doing here in partnership with Aflac to help increase the fast flow of value. Um, and, and one of those includes value stream mapping. Many of you are familiar with vice-chair mapping. Um, basically it's, it's a collaboration with a cross-functional team looking at the, kind of these, these, these, um, end-to-end system of work this end to end process. So at DXC, we help our customers really nail this down into a five step process. Um, that's identified here. The second big enabler is the, the team topologies work, the great book on team typologies that you bet you're all familiar with as well. Um, so this is a very powerful set of patterns and constructs, including the clear delineation of platform and enabling teams that help, um, the streamlined or cross-functional delivery teams become more, more and more autonomous and able to focus on their fast flow of value.
So using these and many more of these, these enablers, we put together, uh, a, a framework and, and this, this framework is for continuous improvement. That kind of works in a two tier model from the, from the leaders, the leadership level, uh, and, and, and the team level. And we're gonna spend a little bit of time on, on walking through what that, what that looks like. And the first key point on this is that, um, we found this journey of journeys concept to be key. So rather than a one size fits all prescriptive, mandated, single journey, um, we enable each team to own and drive results based on their specific goals and impediments. So each journey is not the same. So whether the team is managing a modern cloud enabled app or a legacy app, uh, an off the shelf, uh, mainframe mobile, whatever the case may be, that this dev ops journey concept applies that it's not a one size fits all approach.
It's based on where, where the team is, where they're starting, what they have, and then getting focusing on their impediments. So, a couple of years ago, I published a paper on top anti-patterns that we see companies fall into, um, when they, when they try to do these large scale dev ops and agile transformation work. Um, so in addition to the big bang anti-pattern, um, and the tools and methodologies only anti-pattern, and the kind of modernization for modernization sake, dev ops for dev ops, like anti-pattern one of the biggest ones we see is this one size fits all one. So I'm going to walk quickly through this, this journey, how each, each team has their own, their own journey, but it's based on the same process. The first is that the delivery teams, these cross-functional teams, um, they, they allocate time for improvement. So, um, whether that's, you know, one sprint per quarter, or whether that's a percentage of time each, 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.
Uh, the second key point here is that the, the team focuses on a set of outcome goals. So this isn't DevOps for dev ops sake. This is focused on business outcomes in OKR, and then nailing down there for Dora metrics. And what they do is they identify what the top impediments are to achieving those metrics, and then work down that backlog of countermeasures, they get help from an enablement and a platform dev ops enablement and dev ops platform team. So we've got this set up now across cross Aflac, and basically what a couple of things these teams do. These, these coaches do is they help advice your mapping. They help coach the teams. They also help run these dojo's in some, several of you are familiar with the dojo concept. We have kind of our custom version of dojo, which is a immersive week long set of set of coach led hands-on keyboards steps to implement some of the top countermeasures and focus on acceleration.
So, um, Brett will talk a little bit more about the, some of the specific dojo results. Um, but in addition to these teams, helping these enablement teams and puff working and helping the core of this is as the teams identify their top impediments to pass flow value, uh, they manage the sun in a Kanban approach and then run through a four-quadrant improvement, caught up powder and real quickly what that pattern looks like is they start with their current state, their current problem. They look what the definition of awesome will be, um, maybe a year or two out what the ultimate case would be. And then from that, they backed that down to what's the next target condition they want to achieve through a set of hypotheses, and then incrementally work with experiments and, and, and fast on feedbacks to getting to that next target condition. So this is a, this is a mindset shift. This is a scientific discipline way of looking at continuous improvement. And that is a core part of, of this framework. Um, this set of steps that each of these teams is on their own journey, but they follow this discipline process. So Brett, why don't I pass it to you to go over a little bit of some of the results of some of the dojo's that we we've worked with?
So this is a, uh, a summary of one of the dojo's that we have done, and, and this is one of many, we've done many dojo's now, and the success, the outcomes are very, very similar across the various dojo's that we have run, but 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 a of test automation, and then one, uh, the final one, reducing our deployment time down to a zero downtime environment. And you can see where we were moving from in each one of those areas and where we intended to go. And it's important to recognize that the kata process that John just reviewed was the going in kind of prep material for these dojo's 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. And then we did identify the steps that we would do in the dojo to realize the outcomes that we were going after. And 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. So when we come out, we've got things that are near ready, if not into production for that value stream. And we've made progress along the way to help them move faster, higher quality, less risk, et cetera. So in the three value streams in CICB pipeline, we were able to go from a long time manual process to being able to elevate to the next environment within minutes, we're 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 phase, 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 of some of the automation approaches that we applied and in our, our deployment methods, um, we were going, ER, went from what was taking upwards of 40 hours over long weekends. Uh, 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're able to get our deployment time down. And so in this one, particular no dojo. Uh, we achieved that within a week's amount of time with very focused hands-on keyboard, um, coaching led, uh, teams that that really were able to accomplish get very immersive and, and the success was absolutely amazing leaders and, and the business themselves recognize the outcome. And, 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 too? Um, one of the, the business leaders saying, can we do dojo's 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 now asking for us to do more and more. No dojo's.
So as we started this whole effort and really, um, started with what we call lighthouse value streams, there were a couple of things that we learned as we hypothesized and then went and verified our hypothesis that lead us into kind of the next level of where we're trying to go. So in the beginning, we felt like, and hypothesize that we could through value stream mapping, um, pinpoint the biggest impediments, those value streams, and then using the process that John talked about before and the outcomes of the dojo's or whatnot, we felt we could make incredible progress against our cycle time and our quality. And we verified that indeed, that was the case. And you can see some of the outcomes, the metrics that we improved of cycle time being reduced by 50% and MTTR by 60% of one of our claims systems or reduce that deployment time for an agent system by 75%, we were able to, um, reduce our manual tasks and, and the way in which we deployed, um, roughly about 55% for one of our, 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, um, 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, um, common practices, but unique in terms of the category of the journey that they were on. We, 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. And perhaps one of the biggest things that we recognized and put, have been putting a lot of effort into, and that is the idea that efforts in this, if we're really going to make this part of our DNA and a true culture change, it has 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.
And so we've set up this pattern and now John's going to lead us through, we've walked through what the delivery teams are doing, and that's working very, very well. Now let's walk through what we were doing at the leadership level.
Yeah. And, and, and as Brett was saying, that, that turns out to be really key to these transformations is having the top leadership, um, be not only supporting this effort, but actively engaged in doing it themselves. And let's explain what that looks like. So, um, both bottom-up and top-down are key the bottom half of the slide, and I'll, I'll fill out the top part momentarily. The bottom half is what I walked through, this, this, uh, journey of journeys, this set of steps that the individual teams go through. And when they across their top impediments, remember impediments are the path. As John smart says that 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, that they're looking at, um, to, to PR that prevents them from getting really fast, uh, flow of value that gets kicked up to this enablement council, this, this leadership team of senior leaders.
And, and, um, a key part of the framework is that these leaders get training and that they understand a new way to, to, to think, and to lead and to shift their mindset along the lines of, you know, um, servant leadership that they'll help remove impediments for the team, protect time from these teams, for these teams to, to do their continuous improvement. Um, and so they can focus on this continuous improvement in the, in the, you know, scientific hypothesis based manner, as well as, you know, transformational leader. So, so, so these guys become the role models. They coach teams on the process and, and, you know, set the vision. So, so when these org-wide impediments come up, this leadership team has council prioritizes. Those, it looks at what the top impediments they're gonna work on. And then they go through a similar process. Um, these are some general examples of what, or what 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, uh, caught up process that we described that these, that all the teams are using. So they're, they're walking the walk, they're living this, they're modeling it, but they're really addressing the top impediments across the org. So 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, this kind of two tier framework of the journey of journeys.
Yeah. So 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 that leaders need to be trained in this new way of thinking this new way of operating. And so you can see here, some of the topics that we've been working through the leadership or with the leadership team, helping them understand what is continuous improvement and what's their role, um, versus what, where it has been before. What's the improvement kata. Um, how do we go down the platform and team topologies path, uh, 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, um, this level of topics. And 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, um, you know, breakouts and all that kind of, of, uh, work on way of training and making great progress in getting our leaders to kind of think in a different way.
So a little bit about our progress so far and, and the outcomes that we've had. So we now have our leaders very engaged and they're, they're driving, they're still learning, but they are engaged and, and actively driving. Um, the, the workshop needs and the priorities around our value stream mapping and the dojo's 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 dojo's 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 in the input embedded as part of our culture. And it, 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 cottage. And so they're updating and moving on and saying, okay, what's next? We've made progress. Let's go after the next target condition. So those are being realized and active progress is being made through those katas and the top or impediments are being addressed. Now I'm kind of working through those just like John said, and that leader on portion of the framework, just like the way the, the delivery teams are working the top or, or white impediments are being addressed. That being said, there still is a lot of work to be done. And, and we hope we, we embrace the idea that we're never done.
So we will continue to address the top four wide impediments and have the leaders support through doing what's going on at their delivery team level. So that's a continuous, um, effort that we're, we're going under right now. We're formally at counting for the continuous improvement process in our planning. So as we plan, um, 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 and we're solidifying and using that training and whatnot to, um, put together and solidify the plan to scale dev ops 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. And we'll continue to build out our platform and our enablement team while we have a lot of that in place that the work continues. So we will continue to, to work on that, um, as we move forward. So 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 with food 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. So with that said, John, do you have anything else you'd like to say to close this out?
Just that, uh, this partnership between DXC and Aflac has been been fabulous and the business results that we're seeing, the culture change, the focus on top down and bottom up, um, driving this, this changes has been, has been amazing, and it will continue to, to, um, to move forward. Um, I would just also say for those, all those listening, if you have any feedback, comments, anything that you're working on in your organizations that, that, that relate that you can add to this, 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 love to hear from, from any on all of you. So thank you very much. Um, appreciate the, uh, the opportunity to talk about this, this great journey of journeys that, that Aflac,
Thank you very much.
Unlimited users from organization
Gene Kim's How Organizations Started Playlist
Patterns for Enterprise Success: The DevOps Journey at Nationwide
Carmen DeArdo, Nationwide Insurance; Hayden Lindsey, IBM
How DevOps Can Fix Federal Government IT
Mark Schwartz, US Citizenship and Immigration Services (USCIS)
Breaking Traditional IT Paradigms to...
Ralph Loura, HP Enterprise Group; Olivier Jacques, HP Enterprise Group; Rafael Garcia, HP Enterprise Group