00:00:13

Hi everybody. I'm Jim Collins, and I'd like to welcome you to our presentation overcoming and understanding how we bridge the it business gap and learn to trust each other. I'm coming to you live from the virtual grand Tetons

00:00:28

And I'm Amanda Plasik. And I'm joining you live from my living room because I have not been on a camping vacation in the last six months.

00:00:39

A little bit about ourselves before it gets started. Again, my name is Jim Collins. I am a senior manager in the it lending area at CUNA mutual group. I've been a CUNA for about seven years, but I've been in it since Ronald Reagan was president. I started out in it and the Navy I served on submarines for a little while. And then after my time in the Navy, I spent time at a couple of financial industries before I came to CUNA mutual group. And I should point out that I have a really sweet bourbon collection, which has helping me get through this COVID year.

00:01:13

And like I said, my name's Amanda, and I'm a senior it manager in our lending it departments, department, excuse me. And I'm focused on agile delivery. I consider myself myself less of an it person despite having been working with it for the better part of about 16 years in a variety of different industries, but that doesn't stop me from jumping into most conversations, um, on a variety of topics. So even though I've never been a developer, it doesn't stop me from trying to talk the language. Um, I'm definitely a Disney nut going down there about two to three times a year and also definitely a big fan of wine, um, and enjoy usually having that at the end of every evening. So Jim and I have known each other for the better part of seven years, having met at CUNA mutual group, we started working together on some of the first agile projects that we did at the company. And through that time, we found a lot of common ground over agile topics and our love of happy hours. So COVID may have slowed us down a little bit, but it hasn't stopped us. And despite a bitter Packers bears rivalry, we maintain our friendship through football season, mostly because Jim is pretty good natured about all the joking I do about the bears.

00:02:27

Yep. Go bears. All right. So, uh, this presentation is about building an it business partnership and really one of the key takeaways from this it's going to be that you can't do it alone. A good partner is really a necessity. So we have a couple quotes here about the importance of partnership. Uh, anyone can be a good partner. It's not like you need to find the right person, but you do need to make sure to you treat each other well respectfully listen to each other's opinions and just give each other common respect. Uh, as long as you have a team, first attitude and you trust each other, anyone can be a good partner for you.

00:03:10

So a little bit of background about CUNA mutual group is it was founded more than 80 years ago by credit union leaders. So Kuna helps credit unions, businesses, and individuals build financial security, um, through a variety of commercial and consumer insurance and protection products. So this year has been no exception to the challenges and opportunities for us to serve our customer base and provide more support to them than we ever have before. So we have just under 4,000 employees located throughout the United States and the Caribbean and our headquarters are here in Madison, Wisconsin. CUNA mutual has implemented a variety of project management approaches and our agile journey started about six years ago. We have many departments and have worked with a mix of agile approaches, including safe, less scrum, Kanban, extreme programming, and lean six Sigma like many organizations. Our agile journey started in it and has moved into partnership with our business teams and the project management office. We have scrum masters technology analysts, business analysts, product owners, developers, tech leads, and transformation leads helping with this journey in different projects and teams throughout the company. So it's quite a mix and we're constantly learning and adapting to what works, what doesn't, and recognizing the differences between our teams that makes each of them a unique opportunity to find the right fit of agile. We also have a large community of practice for each of these roles, um, which helps them learn from each other and expanding their agile footprint within the company.

00:04:51

Uh, a few years ago, at least in terms of our, the example we're going to talk about today, we realized that our business needed to change. We had done a lot of market analysis and in the past CUNA mutual had developed standalone solutions, uh, where people would come to our applications and use our systems to sell our insurance products. Uh, while that model had been very successful, what we were finding these days is that people want it to be able to sell our insurance products from their channel. So instead of them coming to us, we needed to come to them. We wanted to provide a way for our customers and their customers to actually interact with our products, uh, without needing to leave the existing platforms that they were using. And as to fulfill that, we decided to focus on an API based solution. Now this meant a lot of changes for the way we do business.

00:05:47

Uh, instead of delivering insurance products and tools to administer them, we're now a technology enabler for our customers. And because of that, it really blurred the line between business and it, whereas in the past, you know, business could come up with something and go sell it. Now what they were selling was a technology solution. And so, uh, we needed to be a lot more closely aligned than we had been in the past. We also had identified that our old way of becoming or doing business was too slow and too costly. Uh, our new concern was how do we fit into our customer's development cycles if they're going to spend time and money building our products into their application so that they can sell them, we need to be able to be responsive to their needs, uh, almost immediately.

00:06:36

So we've identified what we'd like to implement in that digital lending space, but as you're likely aware by attending this session, we had some challenges to overcome. And my guess is these are similar to what you've experienced or probably are still facing. Um, first making changes was not easy because projects run long sometimes over budget, um, and may no longer be exactly what was needed at the start both business. And it recognized that simple changes cost a lot for those in it. We know what seems simple, maybe a challenge to code and for our business partners, the why can't we make that button green instead of blue, it seemed simple, but due to the cost time and resources put into work, often those changes came with a high price tag and let's face it by the time something was released, we were off and onto the next project, which is a good segue to the next point. Business wanted to get everything done at once. So how many folks here have run into a project being so large, it was going to be years to get something of value out the door.

00:07:49

So our business recognized that if it didn't get done in the first place, it wouldn't get done at all. Cost was too high and projects were so large that small changes wouldn't happen. So it was a large amount of requirements from the start that the projects became lengthy and costly to add to it. We had a real opportunity to build trust back business didn't necessarily trust that it would get everything they wanted done as they wanted it. And it didn't trust that the business was only asking for truly what was needed. So when things went long and budgets ran over the fingers would point as to why things were failing. And it just wasn't healthy for the projects. As with many waterfall projects, we collected requirements upfront. And once we locked those in and started the development, there was little to no opportunity to change them.

00:08:41

So we'd continue through a project. Knowing requirements probably needed to change, but without an ability to do so without severely impacting an already lengthy timeline and budget, which we didn't want to go over on. And finally our business and it goals were not always aligned. So our business partners wanted the latest and greatest our it team just wanted to get off a system that was no longer being supported. So while it was always striving for delivering what the business wanted, it was a challenge with increasing technical debt, but we knew we needed to make a change to make it a more positive experience for everyone.

00:09:20

And as we start to talk about the changes that we needed to make, uh, this is a great quote, that kinda sets the tone for what we're going to talk about. Nothing you're going to hear today is, are shattering. A lot of these principles are things you would already apply in your own personal relationships. And we just decided to apply them to the workplace. Uh, so we really needed to change. We knew that we couldn't do this using our own methods. Uh, in the end, one of our driving principles was that really all that mattered was business success. Uh, because if the business doesn't succeed, it doesn't succeed. Then it doesn't matter what cool new technology solutions you delivered. If they're not making money for the business, then it's not good business. And really things broke down into two categories. The first one is being the concept of one team prior to making our change.

00:10:16

Uh, it was in one building and the business was in another building and we get together and POC and big conference rooms. We'd have these huge meetings with lots of people in attendance, and you try and sit down and figure things out in an hour. And then everyone would go back to their desks. And that just wasn't working. You know, a lot of these things that we need to do require back and forth conversations, give and take. And by spending a lot of time together by having everyone in a project room, uh, we thought that was really important or really paid dividends. And then the next one is that the business as its partner, not their customer in the past, the business would say, here's what I want. Now go build it. Or it would say, well, you just tell me the requirements and I'll go figure it out.

00:10:58

And that doesn't really work. There are so many times where a, a little bit simpler solution may end up being a lot less money and a lot better for what the business is looking for in the long run. But if one of you is a customer and one of you is the partner. You don't have those conversations. Someone, you become an order taker. And really what we want is to have conversations about what's best for the business overall, not just this business unit or this it unit, but what's best for the company. Uh, in order to do that, we have, we let business weigh in on it decisions. And of course it will weigh on, on business decisions. Uh, this one, we had to have it go first. We had to demonstrate that we were going to let the business weigh in on some IP related decisions as a show of good faith, uh, whence once they, they saw that, that they could have input and they were listened to, uh, then they were very quick to invite it into their decision-making process as well.

00:11:58

And that's critical without that. None of this would really be possible. We need to have a good enough collaborative relationship where we can both tell each other, this is what makes the most sense, so we can develop the best solutions. The next one is that all work is aligned to business goals. And here we call those OKR. So objectives and key results. Uh, everything needs to be business focused because again, as I mentioned earlier, if the business can't sell what we deliver, it doesn't matter how cool it is. It's got to meet a need of the business. And so really even it goals need to fit into business goals. And if you do this right, well, you don't have to worry about the it goals, not getting priority because they're the same goals that the business has because the business needs good technical systems and solutions in order to sell their products.

00:12:48

And we all have to be on the same page about it. Uh, one of the other ones that may not be quite so obvious as some of those ones above is that we built trust by supporting other people's causes, not just their personal or work causes, but also their personal causes. Uh, one of the things that CUNA mutual does a great job at is philanthropy. We do a lot of volunteer work and, uh, we, we support a lot of the, the needs of our community as best we can. And we found that by having the team skip together and do philanthropy work together, whether it's raising money to donate for, you know, what the food bank or whatever the cause happened to be, we did those things together as a team. And we found out what people's causes were. And, uh, you know, it's a great way to build a comradery on the team.

00:13:39

It was also the work causes. If something was really important to somebody at work, well, you would want to support them in that too. And by doing that, and by seeing the team supporting each other and what their real concerns were, uh, it built a great relationship. And then the last one of the one team concept is eliminating blame. And believe it or not, this was much easier to do than expected, but did require frequent reinforcement at first less overtime. You know, when you're working in a waterfall environment, which we were before we started this, you would come up with requirements and then everyone to sit in a room, the business would come up with what they could and our business people are brilliant, but they don't know every one of their use cases. So they would come up with the requirements, the best they could, and then we'd lock them down.

00:14:28

We get them signed and that's what we were building, whether that's what we needed or not. Uh, and so a lot of times you would hear that an issue was identified. They say, oh, well, that's not what was in the requirements. And we no longer do that. Instead, when an issue is identified, we don't talk about whose fault it was. We talk about how we're going to fix it. And so by eliminating the step of saying, all right, well, what's the root cause of this. You can just get the, how do we make it better? And everyone's really smart. Everyone's working hard, everyone's doing the best they can, uh, by focusing on how do we make it better rather than who actually got us into this situation. Uh, we've been able to really have a very high degree of morale and cooperation on the team because people will do their best.

00:15:13

And they know that that's appreciated, not have to hear about how they did stuff wrong. Uh, the second part of what we changed was requirement's manage management. As I mentioned, we were very, very waterfall where, you know, we'd sit in that room and we get sign off and you get a stamp. And every change on it had to be a change request. And they had to go through a process. We had to get more money. Uh, we don't really do that anymore. And a big way we get around that is that the product owner doesn't really define the work. The product owner is the one who probably has the most significant input into what we work on, but the team defines the work. Everybody has input. A lot of times the product owner will ask for a solution that, uh, if they dropped one requirement from it, we could have done in two weeks.

00:15:59

But because of that one requirement, now it's going to take nine months and we need to have people be able to say that and say, well, geez, you know, I know you want this, but it'd be really a lot simpler if we went this way. And a lot of times the business is like, yes, let's do that. And so by having a team decide what we're doing instead of a person, it really made things a lot easier to manage. We had a few rules that enabled that to happen. The first one was being, don't ask the business questions. They can't answer prior to our change. We would go to the business and say, so how fast does this API need to respond is a second fast enough. And sometimes they'd say, oh, sure, a second, we'll be fine. And we might respond and say, oh, well, that's not possible.

00:16:44

It's going to take five. And so that really leads into the next few points is don't ask the business questions. They can't answer the answer to how fast does this screen need to respond to a business person is as fast as it can, right? Don't build, listen to what is possible. But if you just ask them, they're going to say, I want it this fast. So we also don't want to ask the business about options that aren't available. So if you can't make that API respond in one second, don't make that offer. Uh, and that leads into the next one, which is share the impact of a decision when asking for one not after. So if your API needs five seconds to do its work, because it's very complex. Well, tell them that upfront, say, this is what we need to do. Or when a business person says, you know, what we really need is this one extra feature.

00:17:31

And you say, if we did this one feature, uh, it's going to add four months to the estimate. But if we do this other thing, it gets you really close to what you want to do. Um, nine times out of 10, in fact, only one time that I can remember the business said, no, that's a really important requirement. You're just going to have to build it most of the time. They're like, no, that's good enough. That'll get us what we need. And it'll get us into market faster, quicker, easier. And, um, by being collaborative, all these things were possible. Again, taking the requirements, going back, coming back with an estimate and then saying, oh, this is, this is nine months. The business wouldn't understand, but it's all these just little decisions along the way that added to that. And may think things take so long.

00:18:20

So our business and it team agreed together that these were good changes, agreed. We wanted to compromise to support each other. And it was no longer about business getting what they wanted or it getting what they wanted, but truly understanding and supporting what was best for the company. So sometimes this was an it upgrade and sometimes it was new business functionality that compromise is possible because of open communication and understanding. And because both areas felt that security, they became champions of each other's priorities. So one exciting outcome and benefit to everyone involved is that a result of the open communication and transparency, the it tech lead and the business owner could ask the other to step in for them in any conversation. So technical and business knowledge was openly shared and supported. Um, and really just endorsed by each other five years ago, we never would have thought that the tech lead would step into a business conversation and drive their priority. But now it happens,

00:19:28

You know, the understanding and help driving other business priorities is really key. There's, there's nothing that an it person wants less than to build something that either doesn't get used or makes their customer unhappy by having this collaborative environment where we can talk through things and really work through what we needed to build, what the right solutions were. Everybody was happier. It also saved a lot of time because we weren't building things that weren't needed. We were only building the things that really added value, and we were building them in a way that allowed us to get them into market with the minimal functionality that was needed without adding things that really weren't going to bring business value. Uh, the last bullet on here is probably one of the most critical things. We could not have done this. If we would have continued to use waterfall, a waterfall created and reinforced these divisions, things like, uh, gates between different phases and sign-offs and requirement, approvals, and change management processes, all made these things take longer, made them more complicated and really made everybody unhappy the business wasn't getting, they were what they wanted. Uh, it felt squeezed to meet budgets and timelines, and instead spent time building things that weren't really going to be used instead of working on things that were, and now we use those times to, to handle things like tech debt that's building up. So instead of spending our time on things that don't add value, we can get back to adding things that add value, even if it's it value because in the end, all that it value is business value.

00:21:05

So like we mentioned before this collaborative, this collaboration trust and partnership had far reaching effects for our organization. So first and foremost, it created a stronger relationship between business and it, there was no longer that tug of war between priorities, a concern that work wouldn't get done, or a concern of disappointing a customer with unmet expectations, the open communication, the no blaming and the clear expectation setting are not really crazy new topics, but they're hard to stick to when there are different expectations from the different areas. When you're holding firm to these, it just helps that helps pave the way for a team for ongoing trust and collaboration with our business partners.

00:21:51

You know, when a lot of times you'll hear people talk about empowering teams and what that really means, and it's been fantastic to see what a real empowered team looks like. Uh, everyone's contributing they're, they're moving fast. People are really happy where we're doing work. That adds value to our customers, to our business, to our entire organization. And everybody's on board. And it's really, it's, it's great to see. I thought I had seen him power teams in the past, but until, until everyone, if this is one of those things where if you give up a little, you get a lot in return by the business and it giving up a little bit to each other. In the end, we have obtained, uh, much more than we ever could if we would have stayed separate and really the quicker results part of this is when you're building solutions or when you're not building solutions that aren't going to be used. You can get to the stuff that you really need to build, and you'll get there a lot faster. It's not that the work gets done any quicker. It's that you're eliminating things that you really don't need. The team can focus on really what's important, and we can make the best use of funds and the best use of the team's time.

00:23:04

So we'd like to thank you for, I just screwed that up.

00:23:10

You

00:23:11

Are going to start.

00:23:12

Thank you. We would like to thank you for attending today. That's a great way to end a nice long recorded session. Um, you know, like any good relationship, it takes time, it takes work. You know, there's, uh, this, this quotes about marriage and it's not really a marriage, but some of the principles, you know, would apply when you're married. You don't, if you have your first fight, you don't stop talking, you work through it. And so you're going to have good days. You're going to have bad days. You're going to have things you need to work through. There's going to be give and take and just stick with it in the end. It's worth it, but it does some effort. And now let's kick it over to Amanda.

00:23:48

It's going to say we, we'd still like to say thank you for attending our session. Um, hopefully you did get a couple pieces of good information that you're able to take back and help implement with your teams. Um, you know, definitely a lot of steps in there. It wasn't an overnight change that was made. Um, but a lot of good pieces that I think we wouldn't change at all at this point, because it really has helped foster a wonderful collaborative team. Um, and hopefully that's something that we could help you do as well, and that you can take away from today. So thank you for joining us.

00:24:21

Yup. And we'll be available for questions for a little while. And if, uh, if you would like to reach out to us afterwards, feel free to reach out. Uh, our contact information is available on the website. Yep.

00:24:32

Bye.

00:24:32

Bye.