Phillip Gadzinski

Welcome to our talk today, which is titled "No Flow, No DevOps." We really appreciate you taking the time to dial in and see us talk about this important topic.

My name is Phil Gadzinski. I'm the Group Global Enablement Lead for Bupa. It is a bit of a mouthful of a title, but what it actually means is that I support capability uplift and modernization of all of our technology teams across essentially 16 countries. We have 4,000 people in technology and nearly 85,000 people serving our customers across the group, and I help them navigate a VUCA world using agile and flow techniques.

With me today, my co-presenter is Adarsh Mehrotra from Infosys. Hello, Adarsh.

Adarsh Mehrotra

Thanks for that, Phil. Hello, all. I'm Adarsh, Industry Principal Consultant with Infosys, and I work with Bupa on flow and DevSecOps adoption across multiple market units, cross-promulgating ideas and implementation to add to Bupa's DevOps intellectual capital. Short and sweet about me.

Phillip Gadzinski

Definitely. Thanks very much, Adarsh.

What we're going to start with today is a little bit around the context of why we adopt flow in Bupa, what the purpose is, but also how it aligns to strategy.

I'm firstly going to start with a story, and it's not my story. I think the first time I heard this was by Steve Denning, who published in HBR about 10 or 12 years ago, and it's the story of Copernicus. It's a great example and a great analogy for this audience, obviously, being in Europe.

Copernicus was a Polish mathematician, essentially, and what he did was rethink how we thought about astronomy. Up until his point in time, we had a geocentric view. We thought the Earth was the center of the universe and all the celestial objects revolved around the Earth. Copernicus turned that around and put the Sun at the center. At that time, we thought the Sun was the center of the universe, and he put forward the proposal that all the celestial objects revolved around the Sun.

The reason I like to use this story is because that small change led to a monumental impact. He published this story a few years before his death, but it really started to gain traction well after. About 70 years after that, it had such an impact in the world that the Catholic Church ended up banning his book for a couple of centuries.

The reason we like to use that as a really strong metaphor for what we're doing in Bupa and in the world today is that in that old world, the organization was the Sun, and we used to think that the customer revolved around us. But what has changed in the digital world, in the explosion of complexity and globalization and interconnectedness and the ability to compete with any part of the world from wherever you are, is that the customer is now the center of the universe, and organizations revolve around the customer. We're trying to get their attention to come and see our products and services.

The reason this is really important is that the world today is VUCA. VUCA is a term that's just starting to get a lot of attention and traction in a lot of our organizations. It was first espoused probably in the early 1980s by the U.S. Military College as a way of describing the complexity evolving during the collapse of the Soviet Union. Interesting, very relevant today considering what's happening in Ukraine.

VUCA breaks into four key topic areas: volatility, uncertainty, complexity, and ambiguity. It tells us that what's happening in the world today is constantly changing and moving, and the way we used to work, understand things, and respond to change is very different. We can't rely on it because the past is no longer useful to predict the future in many circumstances.

VUCA also extends as a mechanism when we start to think about organizational transformation. Organizations are moving very quickly. We need to respond faster, we need more weak signals out, and we need really good feedback loops. It is used as a mechanism when we think about how we might set up to change the organization.

There are a couple of quotes that I still like to use today from Edwards Deming, who many of you may know was one of the founders of the Toyota Production System in Japan and essentially led to the Lean movement. He created 14 principles of total quality management, and the three I still use on a day-to-day basis when I think about VUCA and flow and organizational change are: create constancy of purpose to forever improve products and services; improve constantly and forever every process for planning, delivery, and production; and put everybody to work on the transformation. Those quotes still mean a lot to us today, and we use them on a day-to-day basis.

Why does VUCA matter to Bupa, particularly when we think about strategy? In 2019, we created one of the first global technology strategies in the organization. It was posited on three pillars: make Bupa safer, allow us to change faster, and have technology at the heart.

In 2021, we had a new CEO start, Iñaki Ereño. He came over from Europe and Latin America, so he was not new to Bupa but was new to running the group. He refreshed our global business strategy. It's focused on the elephant 3 by 6. I won't cover the elephant story today, but it's an interesting one. He simplified our business strategy, focused on six specific pillars, four strategic and two enabling, hence the six, and three specific outcomes, the goals we want to achieve as an organization.

On the back of that, we spent time refreshing the technology strategy so that we could still respond to the VUCA world but deliver to the new organizational strategy. We changed a few things and started to focus on empowering our Bupa people, building engagement, delighting our customers, which is critical to our global strategy, and continuing to build out our digital core, which is one of the key things we do, particularly in the centers of enablement.

The centers of enablement that we created as the mechanism to deliver to that are really the vehicles. We run four specific centers of enablement to build out that capability. We have a data and analytics CoE. We have a digital CoE, which focuses on transformation and agility. We have a cloud and technology modernization CoE, which is where a lot of our DevOps teams sit. We also have just started an AI and machine learning CoE to improve our capability in that space.

Alongside that, we run numerous communities of practice. We have an agile community of practice, design community of practice, innovation, data science, and even a global agile coaching group. The purpose of these things is to build up our capability so we're better at delivering to VUCA. When we think about VUCA, it means complexity, and if you want to understand complexity and succeed and thrive in complexity, you've got to be doing multiple, numerous things: bringing feedback loops and getting more information back to the group to figure out where we need to focus more.

Now that we've talked about our strategy and VUCA and why we're doing these things, let's talk about flow. One of the reasons that we look at flow as the principles of working across all of our technology teams and even outside of technology is about the speed of information flow.

I learned a long time ago when I spent time with Alistair Cockburn, one of the founding authors of the Agile Manifesto, that the limiting factor in a lot of work, whether it be project or product teams or even BAU and operational teams, is the speed of information flow from the person that holds the information to the person that needs to act and execute on it. The faster that information can flow through a system, the more likely you're going to deliver better and faster and more quickly, and the more likely you're going to have better decisions. Speed of information flow leads to speed of decision-making, which leads to speed of information and the speed of outcome.

What does it mean for us in Bupa? It means that we prioritize adopting flow as one of the key strategic pillars in the way that we work and operate.

Let's talk about flow. What is flow? Flow is a collective social motion where essentially all the participants in a value stream of work get together and define what that process needs to be, from customer demand, the source of the ask, through to delivery back into the customer's hands. That's the definition that we're using in Bupa.

We've prioritized it as our main enabling mechanism because we want to allow teams to get closer to customer demand, remove the things in the process that slow down information flow, and accelerate decision-making so we can get a better customer outcome.

We don't just do it at the team level. We actually do it at an organizational level, because if we ask teams to design for flow only at a team level, they can only do so much. We adopt the flow principles organizationally, right at the upper level, portfolio level, strategic thinking, through the multiple layers of an organization, down to team of teams, and even down to teams. We've developed patterns and guides that enable people to pick up flow when it comes time for them to adopt it. Adarsh will talk about that when we get to the principles of flow and the processes.

Why do we adopt flow? Flow is an enabler. It's not the outcome. There are three specific goals that we think about when we think about adoption of flow.

One is around an operations strategy. Traditionally, in a lot of companies, we treat our people as a resource to be utilized, perhaps up to 100%, sometimes even more than that. When you focus on resource and people utilization, you introduce delays in the system and get reduced flow efficiency. When we talk about using flow as an operations strategy, we're trying to turn the lens away from resource utilization and onto the real input, which is the work and the flow of work through the system. If we do that, we can improve our operational productivity anywhere between 30% to 50%. When you start working with a team, baseline them, and start to progress, within three months they're generally up to 30% better. It makes you more productive.

The second goal is flow as an improvement driver. We're asking teams to look at the way they work and operate today, the policies, practices, and things we want them to do, to understand, collaborate, and work better. When we do that, you get increased team engagement, which again is another focus at Bupa. We want to empower our people and make Bupa a place that people want to come to work.

The third is to use flow to reimagine delivery totally. We're on a bit of a journey with that at the moment. We're thinking about value streams, and how we slice value streams even smaller, right down to a micro-moment level, with a goal of increasing customer satisfaction. By thinking about value streams and using flow as a principle, we can uplift customer satisfaction by anywhere between 10 to 20 points. We use NPS as a scale in Bupa to measure customer satisfaction. When I talked about the 3 by 6 earlier, one of the three is an 80 NPS across the whole group. We're really focused on uplifting that customer experience, and flow is a key mechanism for us to be able to do that.

What's next is how we bring that to life. I want to hand over to Adarsh now to talk about the steps and things we do to make flow work in our teams.

Adarsh Mehrotra

Thanks for that, Phil. We wanted to make our journey measurable, and hence we created a flow transition matrix on a scale of one to five. Level one shows the principles of flow where things are not followed at all, where there are ad hoc processes to track the work item, there is no linkage of customer value to work, and no agile ALM tools to manage and track your work items. All the way to level five, which is the state of bliss, where the organizational flow with the entire business is fit for purpose, where your workflow is mapped to your entire system of work, where all the deployed work items clearly have specific outcomes, and you're managing your entire system of work in your work item management tools.

To summarize it all, there are four key areas that this flow transition matrix gives us. It tells us how flow is being adopted at a team level and whether it is working. Second, it tells us how workflow mapping is done. Third, it tells us whether we are aligning the work to customer value. Finally, it tells us how the work items are tracked and managed.

The underpinning principles that have worked for us come straight out of what Gene has given us in The Phoenix Project. Number one, visualizing the whole work from business through to development to operations, and ultimately to customer, where the value is created. We cover all four pillars of people, process, technology, and culture. Point number two is increasing the feedback loops: stop the flow as soon as you find an error and put the feedback as soon as possible to the source to fix it. Point number three is the culture of constant experimentation and learning. We were a highly risk-averse organization, but now we move towards PDCA, plan, do, check, act, and that has started to take root within the organization.

It is said that the stronger the why, the easier the how becomes. Let us talk about DevOps and the flow solution elements, which have also been our golden template.

Number one is the value stream-based construct. The teams are organized on their core business and have full-stack capabilities, which means that they are able to pull from the backlog and deploy all by themselves.

Number two has been the KPI-driven maturity model. We needed a reference point and hence created a maturity model. We've included KPIs that are fundamental to DevOps: metrics across speed, like lead time, deployment cadence and success, and stability-based metrics like mean time to repair and availability of systems.

Number three is infrastructure as code with self-service CI/CD pipelines. While we made this journey measurable, we started setting the DevOps infrastructure in parallel with three striking elements. One, you get end-to-end traceability, right from user stories to code, defects, test cases, and all the way to deployment artifacts. Point number two is reusable pipelines, which means that as a feature team, I do a right click and say clone, and with changing a few parameters I am good to go all the way to production. Finally, quality and security are completely baked in the pipeline.

How did we scale out? You have a robust infrastructure in place and a strong CI/CD platform. Then we have waves of applications hopping onto the platform in a factory-like approach.

The next element is training and enablement. Now that your teams have hopped onto the platform, how about the enablement of these teams? One of our biggest learnings has been that while we have the best-of-breed tools and automation in place, we also have to make sure that the people are the most important part and factor of our journey. Hence training and enablement has been key for us.

Let's talk about the metrics and KPI-based improvements. Now we are in value stream construct mode. We are doing on-demand deployment. We have multiple products that can go together as part of a release. Am I talking about science fiction? Is it happening in real life, and how do you measure that? In God we all trust, but for everything else, we need data. Hence, we have been a metrics-led culture story.

In order to sustain the momentum, we have used a lot of game mechanics. It is said that gamification is 75% psychology, 25% technology, and that helped us in sustaining the momentum across the organization. Crystallizing our story so far, we started with ANZ first, and now we have successfully replicated our golden template across multiple market units in the last two years. This strong foundation has not only created value, but tangible outcomes in terms of faster time to market and, at the same time, resilient production.

As you would observe, with our complexity and diverse geographies, how do we drive a lot of this change centrally and at the same time bring visibility to all? We have utilized a framework to tackle this, and I will hand it back to Phil to take us through it.

Phillip Gadzinski

Thanks so much, Adarsh. We're really making some great strides in starting to adopt flow from an enablement perspective across 16 countries, with still a long way to go.

Let's talk about how we bring it to life. In Bupa, we've adopted the Remote Agility Framework, which is reasonably new. I've been familiar with it over the last two or three years. We've been using it in the CoEs, but now we're starting to federate it out to other parts of the business.

Why we like using this when we want to talk about designing for flow is that it allows us to cover off all the things that are important when you want to start a new team, launch one, or come back and revisit that team's way of working. The RAF templates cover a multitude of things, but we'll talk about one today, which is the team launch canvas.

The idea is that you get the team together and they collaboratively co-design how they want to operate. From a center of enablement perspective, we provide the tooling, guidance, patterns, and techniques, but the teams need to work and design the how: how they work collectively and what they do.

The RAF templates are good for that because they bring everybody together and allow you to elevate the questions that sometimes don't get asked and just evolve over time. These are things around aligning on purpose: what are we here to do? What are our social contracts? What are our norms? What are the team alliances? Making sure that the sources of demand are clear is super important when you want to talk about flow and designing value streams. You need clarity around where the work is coming from and how you're executing it collectively. What are the shared roles and responsibilities in the team, so when work comes through, you know who's going to be doing what, so you can get it out to your customer? It also breaks into things like not just your scope, so how you operate here, but what processes are upstream from you and what processes are downstream from you. We've started to deploy that a lot more across the organization, and we hope to see an uplift in our ways of working and collaborations as we grow it out more.

The next thing that is really important when you're talking about flow and DevOps is metrics. When we first started our global technology strategy, we had a lot of metrics. I think at last count there were about 40, and that's probably a little too much when we want to think about organizational transformation and change.

What we did do was develop robust systems and reporting using Power BI connected to Azure DevOps, and even built some of our own portals and templates. We get strong information so teams especially can understand where they are from a metrics and performance perspective. When the new strategy launched, we rethought our metrics. I'm really pleased to say we've adopted DORA. The DORA metrics and the four key ones are the ones we're focusing on organizationally and have just started to use this year. We haven't thrown away the other things, but these are the ones we really want to focus on because we think they're going to give us the most value. As your last book, Gene, really posited, the DORA metrics are the keys to organizational performance. We're focusing on those with a few extra ones that matter to Bupa.

What have we achieved now that we're starting to implement flow and DevOps? In terms of reporting, we're using some great dashboards and starting to see real improvements across things like quality. As we start to release more frequently, our quality is increasing. We're lowering work-in-process limits, so teams are better able to focus on the important things in their backlog. We're shortening cycle times, improving lead time, the really critical things when you think about flow and flow metrics.

The one we're focusing on now is flow efficiency, which is a super hard metric to get right because you've got to have your processes in place, a certain level of maturity in the team, and the tooling right. Not only are you measuring as work progresses through your system, you're measuring wait times, because without wait times, you can't get flow efficiency. It's not something we start with, but as teams mature, it's definitely something that we use.

In terms of achievements, we're starting to see some real progress. Flow-based adoption is growing across the group. We're starting to see reuse, and end-to-end automation is improving. In some of the pipelines of the teams we work with closely, we even got security tooling in, which is new for us. We'll be able to think about that DevSecOps shift left, which is something we've been building for and are now starting to operate in practice. We're seeing it on the ground.

Cloud and data adoption is something else. We've got a real focus on cloud migration now. We've been doing it in bits and pieces, but it's now a strategic goal. What's interesting as well is that cloud adoption has been a technology goal for a couple of years. It's now an organizational goal, sitting on the scorecards of our executives, which I think is a monumental change and something that will give us great impetus in viewing technology as an enabler into the future and not just a cost center. Automation of metrics is something we're really focusing on.

I've got a quote here as well. We work very closely with some of our delivery teams. Ajmal Takali is one of our business leads on our digital connected health platform. We've been working with his team for about a year or a year and a half on the adoption of flow principles and now the adoption of flow metrics and flow efficiency. His view is that we're getting so much better in our delivery and processes, and it's also improving the employee experience. We've got a really engaged, happy team that is starting to be really productive. That piece of work we're on is setting the digital future for Bupa.

There are challenges, though, and there will always be challenges. Some of the ones we've talked about a little bit in the talk so far: Bupa is a really federated organization. We talked about those 16 countries. They're all independent. We're only now starting to build collaboration using the CoEs as communities, but it does make it difficult. The CoEs themselves are the vehicles to build cross-border collaboration.

The link between technology and business is still emerging in the company. Some parts of our business, particularly in Poland, shout-out to anyone from Poland listening in to this European summit, are probably one of the best examples we've got. In some other areas, we're starting to build that cross-business and technology value stream thinking. We're really working on that, and it's a focus for us.

Project mindset: we still have a bit of a project mindset in parts of the business. But we are moving more to domains, to value streams, and to more persistent teams. We've got mission teams up and running. The interesting thing is that because we are a federated company, we might be doing things 16 different ways. When you take off the wrapper, underneath it, it's all the same: how do we bring people and business and people and technology closer together? You think about the principles of the Agile Manifesto: bring people from business and developers closer together so we can deliver better outcomes.

We still have a bit of a risk-averse mindset, but we're starting to break through that. We're breaking through and being able to deliver value quickly and faster because that ultimately reduces risk. One of the things people forget when they're thinking about Agile is that Agile is actually about risk reduction. It makes you less risky because you're doing things sooner.

Adarsh, how is our partnership going over the last couple of years around this?

Adarsh Mehrotra

Thanks for that, Phil. Infosys has worked very closely with Bupa to roll out the flow maturity assessment training program, nailing down on the global KPIs, their reporting, dashboarding, and working across different market units as one seamless team. The journey hasn't been one straight line. It has been a series of advances and retreats, but we've worked on each other's strengths and capabilities to produce the outcomes to help meet Bupa's goals. Back to you, Phil.

Phillip Gadzinski

That wraps up our talk today around flow and why it really matters to a DevOps team, a little bit about why it matters to us at Bupa, and a bit about how we're bringing it to life and some of the successes we're having. We're still very early on the journey. We're only a year or two in, and we've got a long way to go. We take this continuous improvement mindset to the things we do, so the journey is never going to end.

Thanks again for dialing in. We're now opening up for any questions or queries you might have. Everybody, the floor is yours, and we're here to answer them. Thank you.