Value Delivered - Navigating Change: The WPS shift to Product Mindset and Team Empowerment

In this episode of the Scrum.org Community Podcast, as a part of our Value Delivered series highlighting Scrum case studies, host Dave West, sits down with Professional Scrum Trainer Mary Iqbal, founder of Rebel Scrum and organizer of Scrum Day Madison. They discuss the agile transformation journey of WPS, a leading health insurance provider. Mary shares insights into WPS's shift from a waterfall model to a product-based Agile approach using Scrum, the challenges faced during this transition, and the strategies employed to streamline product ownership and improve delivery processes. Tune in to learn about the importance of defining clear products, empowering teams and fostering a product mindset in large-scale agile implementations.

Transcript

Lindsay Velecina  0:03  
Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.

Dave West  0:19  
Hello, and welcome to the scrum.org community podcast. I'm your host, Dave ware, CEO here@scrum.org. Today's podcast is going to be focused on sharing some experiences, the experiences of an organization or health insurance provider called WPS and their journey to agility into the product mindset and to the product operating model. It's it's an interesting journey and I'm very fortunate lucky, I feel blessed to have Mary Marriott BA, PST founder rebel Scrum, and organizer of annual scrum event in Madison, Wisconsin. I was fortunate enough to go to Madison, Wisconsin last year to sample this experience. It was incredible. And I've only got positive things to say about both the place and and the event. But this is when Mary and I started talking a little bit about some of her experiences with this with WPS. And I thought everybody would like to hear this. So welcome to the podcast. Mary.

Mary Iqbal  1:24  
Thank you so much. I'm thrilled to be here. And yeah, it was great seeing you in Madison. That was that was a lot of fun. And I think people don't realize what a beautiful place Madison really is. And we've got cheese, you know, what's better than been by trees and cheese,

Dave West  1:39  
cheese and trees. And obviously, the old fashions brandy old fashions, which has become a staple of my my drinking list now. Yeah, so it is an amazing place. And what really shocked me Marissa and we'll, we'll lean into the story about AWS in a second, but was just the sheer energy and passion that the audience and the community the Agile community has. And you know, it's my first time to Madison. And that really blew me away. It was it was a fantastic introduction to Madison and to that community.

Mary Iqbal  2:16  
I'm so glad to hear it, it was a lot of fun for me. And people gave such positive feedback about about the event. And I think people really enjoyed it. So it was was fun experience for me just all the way around. And

Dave West  2:28  
of course, it's going to happen again this year. So if you're in the area, or even if you're not in the area, and you fancy a trip to sample some cheese, and some trees, and in Madison, Wisconsin, go check it out. It's on our website, and you can find it. But anyway, that's not what we're here for, though, it's always good to plug a fabulous event. Let's first start a bit about you. Tell me about you and your journey to helping WPS.

Mary Iqbal  2:53  
So, you know, I was at WPS for eight years. And it's a really it's a great company. It's the largest health benefits provider in the state of Wisconsin. And they provide health benefits to veterans, active duty personnel, but also they provide health health insurance as well to the public. So it's a fantastic company, I was there for eight years actually started off in project management. And so I moved on up to program management and finally was their Agile transformation manager. Most recently, their WPS. But the story I want to talk about today is really for one of their government contracts. So WPS actually has a lot of government contracts. That's what they do. So when I say they process health claims for the military, I mean, they have a contract to process health claims for the military. And so this particular contract was launched with waterfall. Initially, it was the last contract they ever did with waterfall. But as soon as they went live, they went agile with it with the with the maintenance and delivery. So that's the story I'm gonna want to talk a little bit about today.

Dave West  3:58  
I'm really interested in that. And yes, I mean, WPS was founded after the Second World War, when so many people returned home to throughout America were particularly in Wisconsin and in the Midwest. And needed, you know, this, this level of help and, and support. So it's, it's, it's, it seems like a fantastic organization. So all right. So we've got this existing system. You've got this contract with, dare I say, the government, which is, I mean, I love America, you know, I chose to be here. But working with the government is always interesting and challenging. We know that. So tell me a little bit about how you introduce agility and the journey. Of course,

Mary Iqbal  4:42  
of course. So so this contract went live in 2018. And when they first went live, it was was the largest contract that VPS had ever had, actually, and so there was some uncertainty on how we were going to support the contract initially, following go live. So I spoke with some senior management and some senior leaders and we decided to try agile, and the customer was on board. The leadership was on board the team was certain on board. So we initially tried agile. And it was the it was not the first time WPS had used agile, in fact, it was it was then used agile in small pockets before, but it was the first time they use it in such a large scale. So initially, management had a lot of guardrails. So when they first went agile with this, with this contract support, they actually had five different products, I'm gonna call it they had to find the products very narrowly they had siloed their teams quite narrowly. So they had one team that was focusing on loading up authorizations, right, another team that was focused on payments to auth matching, and or I should say, claims processing, another team that was focused on invoicing. So they had five different teams actually siloed in this way, which was an improvement actually, on what they had before, which was previously they really well, this was a new contract section, it didn't have anything, but they would have, they wouldn't have done it this way. So when they first went to agile, it was, it was good, right? They did get some benefits from agility, they got a lot more transparency they had ever had on previous contracts, they certainly had a lot more ownership than they had ever had supporting a previous contract. And they had a lot more engagement from the team. They had first launched a contract with waterfall, so it was buggy. Right, they already were a little bit behind because the project had been launched using waterfall, there was a lot of bugs. And it took them a long time to really get the system up to the quality level that they wanted. But but they got there with Agile. And so that took about a year. Right. And they were they were going Agile, but still it wasn't as powerful of an experience as they had hoped. Yes, they had more transparency. Yes, they had more engagement, yes, the customer was more engaged. But it felt like they could be doing more. So this is the point where where I kind of reengaged with them. And I talked to senior leaders, and we said, did a little bit of analysis. And it turns out that 30% or more of their work on any individual scrum team had dependencies on another scrum team. Right. So you can imagine this, right, the claims processing team has a priority that they're working on. But they need work from the authorizations team and invoicing team needs work from the Ostium. And they will have different priorities, different competing priorities. But, but that wasn't even the worst of it. Actually, the worst of it, I knew it. The worst of it was the customer's experience, right? An internal stakeholder, if an internal stakeholder wanted to have work done, they couldn't just go and request work, they had to go to five different people to request work. Right. And that put a lot of burden on our internal stakeholders, not only did they have to request work from five different people, they also had to harass those five different people to make sure that they were working together to get that work done. And if it wasn't on somebody's radar, it was Disrupt. Right. It was just that. So that was really the worst of it. And that was what, what led them to say we can't continue this. So they brought me back in and to do it a little bit of analysis on on what we could do to make this happen and make this better. So I met with senior leaders, and we talked about well, what are your products, actually? Right. Your product is not authorizations, your product is not just invoicing, right, or claims to off match. What are your products? And so the executive team took a step back, and the managers and their leaders and they had a conversation Well, who is our customer? Right? And what are our products and they came back and they said we actually have two products. And those two products are essentially customer service, right? And claims processing, those are our two products. So they took a step back, and they identified that and then they put in place one product owner for claims processing, and one product owner for customer service. And this is a huge change. So we went actually from a total of six product owners if I'm not mistaken, right down to eventually down to two, two product owners, one for this system and one for that system. So it's a huge change. And if we follow the story just with claims processing, so we defined our product, we said there's one product, and all of these teams are going to come together to support that one product, which is fantastic. And then from there, right. I'm going to pause and say question, what are your thoughts so far? Do you have any questions or comments on that?

Dave West  9:53  
I mean, so So let me just just bring our listeners along for a second. So let me see if I can get this right. So basically Got this insurance system, medical insurance system, obviously, the components of an insurance system, were then elite were created in sort of like these product teams, five of them, six of them, they're all working together, when that created a significant amount of dependencies between them. So if you made a change in one area had to change often in others, and etc, etc, which slows down, you know, dependencies, slow things down, there's no ifs or buts about that really knows that. But then, but also, the implication was when the business came along and said, Hey, we want this, they themselves had to then negotiate with each of the product owners for these different groups, to actually ensure that this imperative went across the appropriate places, which again, made it incredibly complicated and incredibly challenging to implement the experience. So ultimately, you went and did a bit of analysis and realize that actually, the customer, you know, the, the out the ultimate customer, and the value that you're delivering can be grouped into two areas, which we are calling products, obviously, one is really about that whole customer experience, the person that's taken the insurance or is benefiting from the insurance, you know, he's going to the doctors is getting their, their aspirin or whatever, or and then it's the actual people that provide the the the the medical organizations claiming for that. And so that's the two products that you provide that provide and then that then you change the number of product owners, number of backlogs and all of that infrastructure that supported them with that, is that a fair summary? It

Mary Iqbal  11:41  
absolutely is a fair summary. And this was a huge change for us, right? We had gone from waterfall to Agile with siloed teams, and then we're taking a step back. And we're saying that these don't, these siloed teams are not working for us, it doesn't really make sense. If you think about it, right? When we used to if you want to make the analogy, and I don't know if you want to make this analogy, but I'm gonna make it when we used to run work with projects, we would bring together cross functional teams. So when we went agile, they went to silos, and it just did not work.

Dave West  12:08  
Feature teams feature teams, right? That because in some ways they were they were autonomous, they had complete control over their destiny. The problem is their destiny was determined by a set of features and capabilities in the internal system, not the actual value stream that the end customer was receiving this, when you made changes to that experience, it then had an impact across all these different places. So you can see the logic to building feature teams is probably more efficient, you get to group all the skills, you get to focus on the same systems, you get to become really good at delivering to that set of feature areas. However, when when your variability is driven from a customer, an end user, a consumer of the product capabilities, it gets a little bit of a mess, it's a bit of a problem.

Mary Iqbal  13:00  
Right? You're completely right does the exact trade off, we talked about, in fact, right? There is there's some benefits to having these feature teams like exactly as you said that people can specialize in part of the system, you really get to know how does the claim stuff match part of the system really work. And so there's some benefits to that. But on the other hand, when the customer only wants work on invoicing or only work once work on other parts of the system, you lose a lot of flexibility. And instead of worrying about what's the most valuable thing to do next, you're really worrying about how do we keep all these teams busy? When they all they want is invoicing? And that's not the focus that we want it. Yeah.

Dave West  13:36  
Yeah, yeah, that makes total sense. And this, this sort of, like false economy, of specialization of labor, is a specialization of labor works brilliantly, if demand is linear, and if it's not lumpy, and if you can effectively manage demand in that way, like in a production system, etc. The problem is in the situation in your situation, or WPS is situation is that demand isn't it's all over the place in pursuit of things that are important to the ultimate customer of these, of these of these products that you're providing. Okay, so now you've, you've blown up the organization, some product owners have, have changed their authority, hopefully, they're still in the organization doing something else. And you've now got two products. So what happened next?

Mary Iqbal  14:27  
So once we had these two products, we needed to of course, reorganize the team. So the very first thing we had to do was communicate about this change right to the teams so that they knew what was coming. So a lot of communications happened to to explain what was happening, what was going to happen next. And what was going to happen next was we're going to let those to self organize, we're not going to come in there and tell you, you're gonna be on this team and you're gonna be on that team. We're gonna let you self organize. So this was right in the summer of 2018. Huh, so 2019 I think it was, but we decided we're going to self organize. And so it took a lot of communication to get just to get people to prepare for self organization like that. It's scary. It's, it's new, it's different. So we did a lot of communications about it, a lot of training about it in advance. And then we came to the day of self organization. And this was done actually remotely. And it was a four hour meeting. And the way we started the meeting was, we had our product owner, come in and talk about, here's the products that we have, right. And we actually did two separate self organization sessions, there was one self organization for the claims processing, and when self organization for the customer service, but so we did this the self organization session, there was roughly 60 or 70 people that were taking part in this. And we started off with our product owner, who was fantastic, by the way. And she she talks about what is the product? And what are the left or right limits of the product? What's our vision, our future state for this product? And then within that, what's our goal? What are we shooting for, for this product? And then within that, what are the what are my highest priority features? Where are we going with this? What are the upcoming deadlines, a little bit about the customer, she she just really did a nice job of orienting everyone about where are we going? Why are we doing this. And then we had the leadership come in, and do a little speech, kind of a rah, rah, we believe in you. We're gonna let you self organized because we believe in you and your skill skill people and we believe in your ability to do this. And then we had the Scrum Masters come in, and they they presented well, actually so leadership left at this point, right. So leadership left the building, right. And then we're moving off to building the room at least

Dave West  16:50  
playing golf anyway. But that's.

Mary Iqbal  16:54  
So the Scrum Masters came up and they presented what are the guardrails within which you're going to be allowed to sell phones. And so those guardrails were presented to the team and they were, they were pretty lenient guardrails. So they said, We need a mix of different skills and every team, we need to have senior people and people who are newer to the teams working together. And then they did something really interesting. They said, Oh, and by the way, any team has to be able to pull any work, which is completely different. And this was a guardrail that leadership really, really put some thought into. And they said, No, we want ultimate flexibility, right? Flexibility is more important to us than than specialization we want. We want depth on the bench, right? We want people to learn different parts of the system. So this was, this was interesting. And then a few other guardrails to write. And then the teams were asked to go into small groups kind of randomly, and come up with their proposal. How many teams do you want to have, right? And we went through several iterations of that, but teams broke out into different rooms. And then each room room came back a few minutes later with their proposal. And each group kind of got feedback from the others. And they went back again. So we went through several iterations of that, that took a couple hours, actually. And then towards the end of the day, the scrum team said, Well, we're gonna push back on some of those guardrails, we want to have a team that is focusing on change orders, government change orders, and one a team that's focused on production support, and other teams can pull in anywhere. So they said no to one of the guardrails. At the very end of the day, they presented their, their proposed team structure to leadership leadership said, Okay, we find your arguments compelling. And then the teams at the very end of the day, each decided who's going to be on each team. And that took, like two minutes, I was really kind of shocked. That's that part of the day actually went, but the team members just assigned them essentially just put their names on sticky notes on what team they wanted to be on. And that was it. And we closed out the day. The next day, there was team agreement meetings for every team, there was activities around what's our definition of done as a product. And then we started sprinting, right, we just we went we went with it. And that was was such a positive experience, I got to tell it was very, very motivating and energizing to be part of something like that. Yeah,

Dave West  19:21  
I think there's a couple of things that are really interesting about them. So lots of things, but the things that really stand out is the clarity of product, the definition of it, what it is the product owner that came in and and really set those this is where the journey were on the leadership providing that safety that hey, your career is not going to be destroyed by this everybody you've got a job and, you know, this is the way you're gonna we're actually going to succeed as an organization and make more money and be more successful and, and therefore, you know, promote people and the light creating that environment and the guardrails obviously super important. It otherwise you can't self organize. If you haven't got those guardrails, you're just running around like crazy, you know, like a bunch of kittens or whatever, or, in my case, small children, you know, my house. But so we've got those guardrails, and then everything that really highlights, which sort of like an underlying sort of theme is, people can be pretty amazing. If you just just allow them. I mean, most organizations, when they do an organizational change, at this level, Mary, they would tell people, what teams they're in, tell them how they're going to be organized. And then the change management processes the persuasion model, as it were, whereas what you did, which is, isn't often actually I've seen it happen a few times, is you're allowed the teams to form, you allowed the teams to sell for literally self organized, you know, as an, you know, not quite as extreme is an open space, but a model similar to that. And, and I think that's really, you know, people are incredibly able, if you just give him the environment for success, which you which you really did. So how did it go? I'm just now curious, you've got these teams, they've got a shared definition of done, they've got some team working agreements, that and that they're doing it, how did it how did it go?

Mary Iqbal  21:17  
Well, first off, the morale improved drastically, immediately, right, just immediately, I was surprised that they used a measuring system. In the end, I don't fully understand the math behind this, but the HR team assures me that it was significantly seven points or something it was, it was very significant. Six months later, in fact, but you could tell the difference right away, morale went went significantly higher. And then we also had several measures of of, you know, agility that we're tracking. So the first measure is throughput, right, which is not a great measure of success, I'm gonna grant you that. But it was still an impressive change, they improved throughput by 300%, within three months, so a huge significant change in throughput. But more important than that lead time dropped, as well, by 20%, which was also quite astonishing. And then more important than that customer satisfaction went up drastically, because not only were they getting more done, which, okay, but also they were working on what mattered to the customer. And that's what really mattered, our NPS net promoter score went went up, customer satisfaction just generally went up. And stakeholders also were a lot happier, because they're not having to go to five different people than one product owner, they could go to, to request request request work from there, a lot of the I'm gonna call it, you know, the administrative burden was taken off of our internal stakeholders. So all around, it was a it was definitely a success. And then other metrics that that around current claims quality were significantly higher metrics around, you know, technical debt, technical debt was it was significant was impacted, as well. So it was was a really positive experience.

Dave West  23:03  
Well, yeah, I mean, ownership. It's funny technical debt, one of the biggest challenges with technical debt is encouraging people to mitigate it, right? A bit like that, in general. But the benefit of, of having a clear ownership is if the same teams saying, if you're, actually if you're just working on something, actually, your propensity to fix technical debt is actually lower than if you know, the people that are going to be working on the thing that you're not fixing. So you end up with this sort of culture, particularly if you have that maneuverability of people, that other people will be working on other people's things, you feel a responsibility to leave your room cleaner than you found it when you went in, you know, it's a bit like, when it was recently in Japan, and I was a large organization, I was gonna say their name, but I probably better not. And their CTO was in the room. And this is the guy he's got, like, 100,000 people in the organization. I mean, it's a big company, and this is a CTO. And when we finished the meeting, he said, he just started cleaning up. I was like, What the heck. So I started helping, so I didn't want to like a, you know, an idiot. So me and him are like picking up the plates. We had a little lunch and tidying it up and putting it on the tray. And that's the culture in Japan. And everybody does that, you know, school children clean their own classrooms. You know, it's just that's the culture. And I think that technical debt is a great example of where this product model and there's cohesive teams that are the you know, the most enjoyable as it were that move around, depending on the work and everybody does everything, you end up with that sort of, let's clean up the room when we leave mentality, which is just fantastic.

Mary Iqbal  24:45  
Awesome. Yeah, I definitely hear what you're saying. And I know that production support, you know, had not gotten that kind of attention before. And so not only was there there, what you're talking about which which is You know, let's not make a mess, right. But there was also that that focus on it. And I would say the other thing that was was interesting, that happened, you know, few months later, I'm not sure how they're still using that product model today, right? It's 2018. It's, you know, when they went to the 19, when they first did that 2024. So five years later, we're still doing the product model, but they have reorganized themselves several times. And those other reorganizations did not really have management input. So I found out about them, like later, after, they'd already been sprinting in the new model, like, a couple of weeks later, they just mentioned oh, by the way, just so you know, we reorganized. Great, and they, you know, they felt empowered to do that. And so when the computer when the team was faced with different types of work, so if they had a new government change order that came down, they reorganize themselves to deal with that, where they might move people around here or there and not do a big reorganization, but they just shifted themselves when they needed to do so. And that, I think, was just, I love that, I think that's fantastic. Yeah,

Dave West  26:02  
and it sort of, it sort of goes against the model of the industrial paradigm, that because ultimately, the idea is everybody's a resource, you got to optimize, specialize, etc, etc. And instead, focuses on delivering value as a team to the to the end customer, which is such a compelling story about this product mindset and, and, and the operating model that support it. So the last thing and I know, we have to keep these short, because we could talk for hours about this, Mary. But let's keep we're gonna keep it short, because we try to support the the idea that this is like, when you're doing ironing three shirts, or one trip to the grocery, you know, you know, that sort of lamp for our for our podcast. So. So what's next? Where are they now? What's what's on the horizon for WPS? Do you know I mean, obviously, you're not quite as involved as you once were.

Mary Iqbal  26:57  
Well, so I'll start with, you know, that was a very successful experience for them. That was actually the second time they had allowed a team to self organize, but it was the first round they really defined products. And so because that was so successful, WPS did adopt the product model in general. So they went division by division and defined a product. So for example, for for their HR division, they actually had a two day meeting with their executives, their leaders, their directors, and they asked the question, well, who are our customers? And from that, what are the services? What are the what are the pains and gains of the customers? And then what are what are the services that we provide? What are our pain relievers, and gain enhancers, and then they sort of grouped the here's our services, and they group the services as a formed products that way. So they did it for ATI. And they did it for gha. They went around the division and did this because it was so successful, and it really made sense. Now one thing I would say, though, is they, they, they adopted products where it made sense, but how big you draw that product box, right depends on the product. So depends on dependencies. So not everyone is in a product field, we still have or they still have teams that are service teams, they call them service teams, teams, like, you know, the server team, right. They're not part of a claims processing product, right, their service team, infrastructure teams remain. I'm going to call it single technology focus. It's not a single technology, but but they're I'm gonna call them kind of service teams. But it's overall has been very successful for them to really start thinking about, let's organize around the customer and what the customer's needs are. And from there, they focus on building that product owner accountability. And that's where they're at today. Building that product owner accountability, and moving from Agile transformation, at this point and into agile delivery is really where they're at today. That

Dave West  28:53  
sounds so compelling and it's great to hear that they've been successful in this the power of products and how that how that works. Thank you for taking the time. I really appreciate it Mary and I think our listeners will as well it's you were very honest and open which is always good and this journey has obviously been incredibly positive experience for everybody involved. So thank you for sharing.

Mary Iqbal  29:19  
Thank you so much for inviting me is this was fun. Great.

Dave West  29:24  
Okay, everybody well that we were lucky enough fortunate blessed to have Marik bow from PST founder of rebel Scrum and organizer of our annual scrum event in Madison, Wisconsin. Join us talk about her experience of change at WPS the insurance the health care insurance organization based in Madison in the Midwest and and their journey from from a waterfall model to an agile Adoption Model using product as that mechanism that glue to bring every Ready to gather and the success that they had. I certainly was inspired by that journey. So, thanks for listening today. Thank you for listening to the scrum.org community podcast. If you like what you heard, please subscribe, share with friends and of course come back listen to to an other podcast I'm very lucky fortunate to to have the opportunity to talk to a variety of guests. Obviously today we heard from Mary and the journey of WPS, but there's also you know, other stories that you might like to hear maybe you want to hear about Gillette and what they're up to, with agility or maybe some of our PST is talking about some very detailed scrum skills or facilitation techniques. It's all here at the scrum.org community podcast and thank you for listening. Scrum on