Value Delivered: How Scrum Transformed a Multi-Million Dollar Project

 

In this "Value Delivered" episode of the Scrum.org Community Podcast, host Dave West and PST Jay Rahman, Founder of Fractal Systems discuss how agile principles helped a large investment bank turn a struggling multi-million dollar project into a success. By applying Scrum at multiple levels, the organization improved leadership alignment, enhanced collaboration, and reduced risks tremendously—ultimately accelerating delivery and achieving better outcomes. Listen in to discover how Scrum can create transparency, alignment, and value at scale.

Transcript

Lindsay Velecina  0:00  
Steve, 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 West, CEO here@scrum.org today's podcast is focused on how agile helped ensure that a multi million dollar project was successful, and how you can accelerate value in large programs. That's always a thorny topic, right? Huge programs not necessarily going to be successful, but I'm very lucky today, because I've got a bit of an expert on the on the subject, Jay Raman PST, and CEO of fractal systems, a fractal the company that he leads, have engaged with a lot of companies kind of trying to help them out when they're in a bit of a mess, and we're going to be talking about one of those situations today. Welcome to the podcast. Jay,

Jay Rahman  1:12  
thanks, Dave, great to be here. It's good. Good to have you.

Dave West  1:16  
So we all know that large projects and programs are ultimately going to fail. You were telling me off camera that you were recently reading a study where it was 95.5% of large programs fail and and I think that that is just a really worrying stat, considering large means expensive, so a significant investment by organizations. So Jay, we're going to be talking today about a particular set of a situation, a particular program that you're involved in. So maybe, if we can actually, you could set the scene for our listeners. You know, what were the key challenges the team faced and led them to need a recovery approach?

Jay Rahman  2:06  
Sure? No, absolutely. So a large investment bank with quite a complicated technical estate, multiple moving parts, kind of legacy matrix management approach towards technology, trying to build a product, or a set of, you know, product with a set of capabilities in the back end which were quite involved and require a number of teams to be able to coordinate, well communicate, well collaborate. Well, yeah, yeah. And that basically the idea was, was that they were going to come up with this great idea, a great product. They're going to they're going to work with these eight to 10 teams, and they're just going to deliver it in no time flat. The original timeline was about a year, and just after a year, we got a call from the CTO and said, Hey, listen, things aren't going so well. Would you like to come and have a conversation with us? Yeah,

Dave West  3:03  
and things were and what was going wrong. They weren't delivering frequently. They there was just like amount of churn. Requirements kept changing. They were spending money without actually seeing results. Everybody was unhappy. There was conflict. What What was, what was the situation? Obviously being being appropriate. You know, you don't want to offend anybody, but what really, what was wrong? What was going wrong?

Jay Rahman  3:28  
It sounds like that you were on the program with us. Dave, no, that's exactly right. So look, I think one of the biggest challenges that you begin to see when the cracks begin to show is that although the teams were, they were supposed to be using a flavor of agile, they were supposed to be using Scrum or lean, or something along these lines. There are lots of challenges around the understanding of what the teams were actually doing. So, you know, agility gives you the opportunity to be able to kind of flex the approach based on your context. But it got to the stage where, you know, the teams weren't fully aligned on who was doing what and how they were doing and how they were going to release. Planning was an issue, a major issue. So yes, you know, we want to start quick. We want to be rapid in terms of our delivery. Sometimes, though, when it's quite complicated and complex, lots of moving parts, you do need to do a bit of thinking upfront, just a little bit. We're not talking about months and months, but you do need to do some due diligence to make sure that you're building the right thing in the right way. And you know, when you have the handoffs, the bottlenecks, the resource constraints, the team constraints, the capability constraints, all of that stuff coming in together, what you get is a large soup of challenges, and then suddenly you start to get missed opportunities, missed deadlines, slippage costs. And I think the biggest frustration was, was that when you asked the management teams, the leadership teams, no one was really sure where. The problem lay. So they weren't quite sure. Well, how do we fix this big mess? We're trying to get this done. No one really knows. Where do we even start? So all of the usual things, right? And then ultimately, it's a revenue hit. You know? You think to yourself, Okay, this is going to cost us 15 15 million to deliver 15 million, very quickly becomes 25 million. You start to bring in expensive people to kind of turn things around. That doesn't work. So spiraling costs, spiraling budgets, deadlines spiraling and that leads to frustration. It leads to aggressiveness, it leads to culture degradation, all that kind of stuff. So yeah, it was a bit of a mess,

Dave West  5:40  
yeah, and it's incredibly hard when you've spent a year, you know, if you got, if you got 10 teams for a year, we're talking, you know, three, $4 million at least the minimum. And obviously, if they work in the financial services sector, maybe double that. And the, you know, you've sunk all this money, and it's not getting any better. So it's incredibly hard. I remember that I was talking to Ken scwaber About FBI Sentinel, which is a sort of famous scrum case study. And I was asking him about why they actually went to him and and brought him in. And you know, exactly the same, that that pattern that you described exactly the same. What's interesting, though, he added the bit notes, and yeah, and their stakeholders were armed, so the arguments were a little bit more scary because of that, obviously, because they're FBI, you know, agents, right? And I thought that was a funny addition to that. So, so, okay, so somebody's, you know, listening to this podcast, and they're involved in a very large program, maybe a retechnology, you know, technology driven initiative, or a business driven initiative, or some sort of compliance initiative, or whatever that's, that's, you know, driving, or, you know, new product that they're building that's driving, you know, 10 teams, 15 teams. What? What are the indicators, the early indicators, the signals that this program might be at risk. Do we have to wait for everything to be like, blowing up and they're like, oh my god, it's so bad, we've got to call J or, or, or, or are there some early indicators that maybe they can get ahead of this pain. That's a great question.

Jay Rahman  7:23  
I think a lot of a lot of the times when we, when we come into these sorts of things, the first that's actually one of the first questions we asked, which is, how did you come up with the timelines? How did you come up with the roadmap? What kind of due diligence did you do to make sure that the timelines that you're proposing and the budgets that you're proposing, you know, hold water. A lot of the times it's guesswork, and that's okay. When you're doing something new, which is complex and never done before, then you don't have a lot of data in terms of how, you know, how you as an organization are going to perform. I think some of the other things that we see happening a lot is the number of moving projects happening in, you know, at the same time. So if you have eight, 910, initiatives, all major initiatives, all sort of pulling on the same resources, the same teams, then invariably, you're going to begin to choke some really important programs and projects, and while you give oxygen to another. So sometimes the organizational awareness of what we can actually deliver as a as a firm, is not there. People haven't really thought through you know how doing work in one area of the organization, especially when it requires so many different types of teams and people and resources and drains, is going to affect another part. And then what you tend to happen, what you tend to have happening is because the organization doesn't know how well they're going to perform as you begin to choke one program to feed another, you start to get this infighting, you start to get all these sorts of challenges coming up. So as an awareness of the firm, you know, how good are we at delivering can we do multiple programs at once? Are our teams set up to win? So when you look at the so that's the mission element, in terms of the overall view of program delivery, the management piece is, do our managers understand the risks that are involved in the program? What are the challenges that our teams are going to face? And how do we, you know? How do we kind of resolve them? Do we have the capability to resolve them? Do we know what the right approach is? Then finally, the teams themselves for this, for this particular program work that we're thinking about I remember you we had 10 teams dedicated to the to the work, but they were relying on a particular team which had a very specific skill set, and that team already short staffed, already overloaded, was feeding 10 other critical projects and programs. And so you've got 10 teams relying on. This one bottleneck, and obviously it's going to start to break down, right? It's going to start to stall. And really what tends to happen is that tends to cause problems and stakeholders starting to infight. They've all got challenges. They've all got difficulties. They have to push hard for their program to work. So they're going to do what they can to free up resources, so to speak. And that's you and I know that. You know that's probably not the best way to solve things. By fighting with each other. The setup of the program, the way things are done initially, can give you the clues that you know it's not going to be working well. And then there's a delivery element. If you're missing delivery dates, then something's wrong.

Dave West  10:39  
So so the things that you said, just to sort of summarize whip, you know, work in progress. When there's lots and lots of work and different things that are in progress at any one moment, that's a recipe for disaster. Because as fabulous as human beings are, context switching is is a huge challenge, and particularly if they're not all working together on that context switch, their context switching at different levels, then you get this sort of like almost a prism effect of complexity. So you talked a little bit about looking at the flow that you know, the delivery flow, and actually seeing how easy or how hard it was to deliver something. Because one thing that we have learned on large programs, and this was, this was a great example of what's happened with the manned space flight program in the US between Boeing and SpaceX. Boeing, it's been a complete disaster, as everybody would know, Boeing have managed to strand two astronauts, one astronaut that lives in the town next to my town actually on the space station, because their product doesn't work. And the reason, one of the principal reasons, and there was many, but they're one of the reasons why SpaceX was so successful, was because they had this unmanned space program continually delivering right? And so they learned so much, and they had the ability to test things on a satellite launch, you know, or or on a supply mission to the space station, or on a you know. And they had this, they had this sort of culture of continuous delivery, which then the programs just took advantage of, really, you know, and, and so I think that's a really key point, even though, on a large program, it almost feels impossible. I mean, you could imagine that launching spaceships is probably pretty challenging, but you actually by doing it more frequently, you get good at it, and then that ultimately gives you the muscle to be able to do that. So whip delivery, frequent delivery, at the planning. How did the planning process. So the reality of the planning, how detailed were the plans, and how comprehensive and how were they formed? Maybe they that can be an indicator as well. Interesting. And

Jay Rahman  13:11  
you know, how did you know? How do you manage risk? So a lot of the times in large firms, what tends to happen is, is that you have a risk team. So teams themselves at the management layer, or even at the delivery layer, will begin to raise challenges and issues. And the risk team comes along and picks them up, and they put them in this beautiful ledger somewhere, and that's it. So for this particular program of work, when we one of the first things we go and look at is, hey, can you show us your risk log? And lo and behold, over 700 plus risks, some p1 risks which are sort of sink the ship, type of risks surface in the first three months. And they've been aged. They've been they've been there for like nine, nine plus months. And so you think to yourself, Well, okay, someone has had the foresight to raise this. Someone's done some thinking about it, which is cool, and that's what we want. But what do we do with it? Well, it's in a ledger now, and someone over there who has no contextual awareness, it's not technical, or doesn't understand the business in terms of what we're trying to deliver, is going to manage it somehow. How realistic is that? So I think, I think, you know, I think also the, you know, you mentioned whip, but you know, a lot of the times people tend to think about whip from a team perspective only. So teams themselves should just be thinking about, Oh, how many things should we be doing? We shouldn't be juggling multiple projects or programs. We should be laser focus. But what we find is so when we when we come in, we always kind of think about the mission and from a mission standpoint, leadership teams at the very kind of, you know, who are running, leading the organization, they should be aware of, how many of these big, hairy, audacious goals can we actually deliver in parallel? Yeah, right? And if you answer, because we love starting new things, right? There's a lot of energy that gets released when you start something new. It's fantastic. It's a lot of fun. You know, there's a lot of pump and all this kind of great stuff. And it's, you know, it's really galvanizing. But you know, you're doing that every six months. You know, you're starting three, four new programs every six months, very, very quickly, what tends to happen is the organization grants to a whole so regardless of the, you know, the enthusiasm at leadership level, because you know, the aim is to do good things and to achieve good things for the firm, if you start too many things and don't focus on finishing them, what very quickly happens is, regardless of how scary you are as a leader, and the size of the, you know, of the of the of the big stick you're waving around, it, just the system just comes to a halt. So those things you mentioned, about web, the value stream and all this kind of good stuff has to that awareness has to exist at the Mission level. It's not just about the teams. It's not just about a management level. I think gone are the days when leaders could get away with not knowing anything about how their organization should be delivering. Yeah,

Dave West  16:06  
and it's interesting talk about that whip at the sort of mission or executive level it is really I mean, I run a an organization and, you know, and we do quarterly reviews, and we do it's really hard not to add new stuff every quarter. And you know, and I'm very aware of the capacity of my organization to deliver value and and we do it incrementally, and we make progress. But the amount of times we've done an MVP, we've delivered something with, you know, maybe done the first release of something, got some interesting data, and then we've stopped because, oh, new, bright, shiny thing. And I see myself doing it, and, you know, it's really hard not to. And the best way of not doing that is to make things transparent, which I think brings us to what you did, right? You know, it's it from my understanding of from the when we talked earlier, it's about applying the scrum framework, or sort of blended approach, to actually facilitate the recovery and transparency and all these things become a natural part of the organization which helps them deal with some of these natural characteristics of large programs. So tell us a little bit of how you fixed it.

Jay Rahman  17:36  
I think, you know, I think the thing is, is that what's great about Scrum is that as a framework, and it's a framework, not a full blown methodology, for most people. Most people don't, don't know that, that it's purposefully incomplete, and that that sounds scary, but actually what that means is, is that there's room for other good things to come in. So we when we come in, when we come into firms, and we do have kind of discovery process and learn a bit about how things are working and what's not working. What we tend to find is, is that what scrum gives us is the ability to sort of coordinate and structure our collaboration. So I think probably one of the most powerful elements of Scrum is the retrospective so nine times out of 10. What we tend to do is, when we come in at a firm level, when we're working with the management teams, we're working with the mission level teams, the executive teams, and we're working with the teams themselves. One of the first things we'll do is if we'll deploy a retrospective So, and that's powerful, because what that will do is it's not about coming in and just going, Hey, we're just going to do Scrum, and everything's going to be fantastic. It's coming, and really kind of being a bit of a detective to learn about what are the challenges that people are are facing, and then incrementally and intentionally fixing those challenges. Now, of course, we know that we they should be doing good planning, that the roles need to be there, that we should be collaborating well and often, and that we should be structuring our collaboration. And so most importantly, we should be retrospecting and learning as we go, rather than waiting to the end of a two year SLOG and then going, do you know what? What did we learn? And no one's interested. So a lot of the times we tend to work, we tend to work layer by layer. So again, the mission piece is leadership, teams, executives, with those guys and girls, what we want to do is we want to make sure that they understand their responsibility when leading a large, large program of work, that ultimately you're still accountable, and you are still responsible for how the teams are performing, and if there's a challenge, you should be rolling up your sleeves to support and help them, rather than pressuring them to deliver faster, which tends to be, you know, the standard way of doing stuff, right.

Dave West  19:48  
So let me see if I get this right. So in a little cross eyed during your description, because what you're talking about so Scrum, definitely you can. Everybody knows how to Well, not everybody. Unfortunately. But many people know how to use it at the team level. You know, to deliver stuff. You know, you have a team, you have a backlog, you have a goal, product owner, Scrum Master, developers, working together. You know, Sprint, do stuff like that. But what you're talking about is applying scrum at that executive level, or the mission, as you call it frequently. So you put in place the the the scrum framework. You instantiate it at that level, starting with a retrospective, which is interesting, because you'd have thought you'd start with goal and work your way. So that's kind of cool. And the reason why you do that is because you're like, well, we need to understand what the major challenges are at that level. And then we've blend that in with the mission, the goal, or the goals. And then that then allows us to build this sort of executive cadence, or leadership cadence. And then the actual teams obviously just do Scrum, Scrum. But then that their retrospectives feed into that executive so it's, it's turtles all the way down. Is that right

Jay Rahman  21:04  
up, we're about to do some work with another asset manager, and it's, I'm glad you picked up on the on the fact that we start with the retrospective, yeah. Because what happens is, is that when you have senior everyone at a senior leadership level, at that executive level, knows what they're moving towards, right? But what tends to happen in the retrospective is that what we want to do is we want the system to reveal itself to itself. We want the people there to know, how are we actually working together? And are we working together? Are we actually going for the same mission? Invariably, what happens is, is that one executive will say, Okay, well, the mission is this, this, this, and we're doing this, this and that. And ultimately, because of that reason, you guys, I always find frequently as we're going through the mission for the firm, you know, my people are getting throttled, or, you know, our resources aren't there, or the team that we're looking for isn't, you know, has been pulled off by something which is inconsequential, and then you get someone else going, hold on a minute. Bob, what do you mean that this is the most important thing? Actually? No, I pulled off that team, and the reason we did that was because of this being the most important now, suddenly you start to see, okay, if we're not aligned at the Mission level, if we don't understand the vision that we're going for, if we don't understand the purpose behind the different initiatives and how they dovetail together, if they dovetail together, then suddenly, what we're going to do, if we're confused amongst ourselves, then how, in God's name was our teams? Are our teams, our management teams, going to be aligned towards, you know, a very certain future? So the retrospective actually is a very powerful tool to help leaders think through what are we actually doing? Are we aligned in our goals, all of us at the at the leadership level? And you know, leaders are force multipliers. Right? When they fix a problem for one set of teams, they tend to those ripple effects tend to occur across the organization. Now, if you've got one chap fixing a problem and you've got somebody else undoing it, somewhere else, you're not going towards a certain future. You're going towards a very uncertain, very shaky future. So those are the kind of things that we want to bring out during the retrospective. And that then leads us to an elegant way of asking, Okay, guys, what is the mission? What are we trying to do? What are we not going to do in pursuit of this mission? Are we clear about if we're going to go for this, then we're not going to do that. What does the opportunity cost? And these are hard conversations, and they're hard decisions to make, but that's what leaders should be doing. Okay? So we don't have unlimited resources. We can do anything, but we can't do everything, so we need to pick very carefully what we're going to do and make sure the team at that leadership space, that executive space, is aligned around that, which is why we start with the retrospective and not with hell. Come on, tell us the vision guys, and let's go on with some planning straight into it. Let's figure out what you know, what we've learned, what are the good things that we've done, and what are the good things that we've done?

Dave West  23:59  
I think that that, I think that's really, really interesting. And then that frames the planning, the overall program level planning,

Jay Rahman  24:10  
yeah, yeah, we can get behind it now. We're all aligned around, actually, you know, one, one thing that we did with this particular group was that we said we did a warm up exercise within quotes. And for those of you who are familiar with liberating instructors, you'll know this is Paul Triss. And we said, okay, look, how would we sync the firm guys? And so we spent 15 minutes at leadership exec level figuring out, okay, if we were the competition, how would we think the firm they came with all kinds of ideas, and the main, the main, the most devastating idea that they came up with was no unified sense of purpose, right? It was the biggest thing. If we do that, then we'll fragment the firm. Will fragment the firm will fragment. Our resources will fragment. Our firepower will fragment everything, right? And one hand doesn't know what the other hand is doing. It's probably the most powerful thing we can do to to derail an organization, right? Yeah. And the final question is, okay, guys, so you've seen all this stuff fantastic. You don't vote the most devastating behaviors. And then everyone gets another dot, and they go tell us what we're doing in the organization right now. And at that point, the room went very, very quiet as these chaps start to think things through. And they realized that actually at least 90% of these behaviors that we're seeing are the things that we are actually doing to derail alpha, and the cumulative result of that work is failure, right? And it took the CEO to say, Do you know? What do you know? What guys together we, you know, our intentions are good, but together, what we've actually created is a failing firm, and then that becomes the catalyst to Okay, let's make some difficult decisions. Let's put some stuff into the game. Let's figure this out. Let's talk to each other. Let's collaborate. Because they mentioned collaboration wasn't great. They mentioned communication wasn't great. They mentioned coordination wasn't great. Okay, so now we have space to begin to attack those things and turn them around.

Dave West  26:08  
So you so it got going. Hopefully that bottleneck team was the appropriate either support or prioritization or or magic was sprinkled on that bottleneck team to allow them to not be so much your bottleneck. We started increasing collaboration between the stakeholders aligned to a common goal. People often say, why has scrum only got one product goal? Surely a product's got multiple product goals. And I And of course, a product has multiple product goals. However, at any one moment it doesn't. And, and I think that that you know that consistency, that everybody's going towards one goal, and then that allows you the most powerful word in any organization is no, right or not, not yet. Nobody says no anymore. They just say not now or not. I mean, I'm that's basically, it's how to make a successful marriage. I think is never to say no, just say not now I'm busy. Actually, I don't know if it is a recipe for success or not, but, but the but not now And by you can use the goal to frame those, those disc those discussions, and make those decisions, which then aligns the organization. So, all right, so we started with, we've now got a clear goal. We've sort of, like made those problems very transparent that you know, at that sort of executive scrum level, we're running through the process. How did it, you know, did it carry on in this sort of like regular cadence with reviews and retrospectives at both the team level, yes, I guess it did that, but at the organizational level or the mission level, did you continue that? Yeah,

Jay Rahman  28:01  
what we found was that you have to, you have to adapt the framework at that senior level. So at the executive level, look, they're constrained in time. The these people are very, very time poor, and they are running, you know, a multi million dollar firm. They don't have time to do 15 minute conversations, and it's not really appropriate at that level. So yeah, we kind of, we kind of dropped the the daily down to two to 215 minute conversations as a pulse check throughout the week. But the retrospective, the planning, and all these sorts of things remain to enforce. So we did that. The thing is, what, what a lot of people don't realize is that the fastest way to shift culture is for leadership teams to go first. And when managers look up and they see their leaders thinking about what's not working and how they can support what they can do to eliminate friction, what they can do to eliminate challenges, how to get ahead of the teams and support them. And they're conversing. They're having those tough conversations, they're figuring out, they're changing that effect then ripples down throughout the organization, right? So it's a very powerful cultural shift. Lots of people are talking about, you know, how was a cultural strategy for breakfast, right? But this is how you change culture. You change culture through tangible, visible behavior. So that's why it's so important. Leadership really is the difference. That makes the difference. So it's one of the reasons why we start in that space. When you get down to the management space, what tends to happen is, is that managers also have a very specific focus. They're the they're the folks that connect leadership, vision, strategy, the reasons why the firm lives with the mechanics level, the teams themselves, and the glue that brings the teams and the execution piece together. And so we want managers to be first of all, engaged and thinking about. What it is we're doing and be knowledgeable about it. I think one of the biggest myths in agility is that managers are evil, right? But on the flip side, you always hear that. I mean, when I was young, growing up, the best people were the managers and the leaders that took time to invest in me and to teach me, to mentor me, to coach me, right? Those that's a real strong role for our manager, and that means they need to have knowledge. They need to know about the frameworks. No longer is it okay to just give it to the teams and not know what the right approach is. How are you going to mentor your guys and how are you going to mentor your girls if you don't know what the right things, how are you going to coach them? How are you going to train them if you don't know so the management layer, actually, and one of the things that we do is when we bring people towards this understanding and this realization that actually, you're valid, you're needed, right? You're absolutely needed, what tends to happen is that we avoid this frozen middle, I don't know if you know about too much about this frozen middle, right, where managers tend to scupper the change. We eliminate that change. We eliminate so we eliminate that scuppering effect. We eliminate that frozen effect by bringing people in and helping them feel relevant and needed, because they are right and they need to operate as teams too. So management teams because they're working across the organization. And this particular organization had 50 plus teams, so 50 plus teams with management teams trying to get stuff done, because you can't just down tools. Okay, we're going to slow something else down. That's cool. It's a conscious decision. We're going to speed something else up. That's fine leaders. I mean, those managers have to help figure that out, right? Yeah, we want them to figure out. We want them to learn. We want them to run 15 minute events every morning. We want them to be thinking about what's what's the difference that makes the difference their backlog, by the way, is that an organizational change element. They're thinking more about the organization built in the right way. They're thinking about, what are the key risks that are affecting these multiple programs, and how can we work together to eliminate them? Which are the teams that are struggling, who needs help and who doesn't need help. So coordinating those managers in that way makes a huge, huge difference.

Dave West  32:10  
It I mean, so one of the first things that I did when I started running scrum.org is I brought in this pal, essentials, professional, agile leadership essentials. We couldn't use M because we'd already be using that. So we had to use L for leadership and, and it's very much focused at that frozen middle and, and I personally, when we were beta ring it and testing it and incrementally building it, I worked with a large pharmaceutical company throughout the US and Germany, delivering it because, because these people could be huge enablers for Scrum. And what was interesting, and you probably saw this as well in your situation, was they were, they were so connected to the existing systems and processes that it was very important for them to understand that those needed to change to create the environments for the Scrum teams. Yeah, but nobody had often told them that they could change them and that they were, they were basically they were expecting to do a PR review, or this review or do and they had all this existing, call it waterfall, but traditional sequential project management process that they expected that they had to do, they'd introduced scrum at the team level. The executives had got a really clear idea of mission and vision, and they were getting all digital, and it was all cool, and it was all cloud and all that. And then this middle group were like, oh, they'd attended the meetings on both, but they had no idea what their responsibility was. Yeah. Where's my place? Yeah. Where do I sit? You know, you've got the the Agile consultants telling them that managers don't exist in Scrum. Nice. You got the executives saying, Well, yeah, you make it happen with what, you know, and then there was sort of lawyer. It was, it was, it was really interesting. And, and I'm really grateful for that, you know, nine months year that I spent at this pharma company, running around the world, delivering these, this training classes with different professional scrum trainers, because I learned so much and really built an affinity. And, you know, actually made, they made me, I felt sorry for them as well, actually, to be honest. So it's really, really interesting. So it's interesting you say that. So, okay, so you've, you've got these, you've worked on with the middle management, you've worked on the executives. You've got, you know, the easy bit, which is the bit that actually is people doing the work at the scrum team level. You're driving up and down transparency across the organization, anything else that we haven't spoken about, and. Um, that that that needs to be really important.

Jay Rahman  35:02  
We didn't talk about the teams. So,

Dave West  35:04  
oh yes, I guess we should. We was actually doing the work. Yeah, yeah, yeah.

Jay Rahman  35:09  
So look, we so, like, if we just talk about so the framework is mission management and the mechanics, and so mission is, is that piece that we talked about right at the top of the of the conversation, which is leadership that changes everything. Leaders have to go first, right? Super important. We all know that, but we need to be able to show people what to do. So how exactly do we go first? And we have to be able to answer that how question for managers, we want them to feel relevant and included, so that they're basically, they're, in essence, they're they're crushing barriers and uniting teams. That's, in essence, what they're doing, and they're doing it well. And so you have this cascade effect going all the way down, right? And then finally, you got the mechanics level. You've got the teams themselves that are that are using scrums to kind of Scrum and scrums to coordinate things, right? And that behind that, we're trying to build teams and people that are thriving in that delivery space. And when that happens, when that when you're working on trying to figure out, okay, what can we do to fix the organizational barriers and challenges, what you tend to find is you tend to open up that value acceleration. Now we, we are we a lot of the times when we're going into firms, we talk about how we can get it. We can get a program going 100% faster, but actually, some of our clients go 5x faster or 6x faster. We've had teams that have got a six month backlog and have crushed it in a month. And that sounds incredible, but actually, when teams are focused on eliminating the things that are stopping them by, you know, we talk about, we talked about those bottleneck teams, right? One of the, one of the first questions that we asked was that, well, if you've got a team with a very specific skill set, which is serving 15 teams, what is, what is the, you know, what is effect, yeah, what is the, how

Dave West  36:59  
they prioritizing their work. What happens? Yeah, it's

Jay Rahman  37:03  
obvious, right? Yeah. How are you thinking about what's important? Firstly? Secondly, why are you not if that skill set is in demand, what's stopping us from bringing that skill set into the other teams? Is it time? And if it's time, then how can we, you know? What can we do as leaders, as managers, as teams, to share resources start to go forward that those pie shaped skill sets, multi skill sets. What can we do? I think the other thing is, is that we bring in other approaches. Theory of Constraints is a great, great approach. Value streaming is a great approach, right? What are the constraints that are stopping us from moving forward at a team level, and who do we give them? Can we, as a team, fix those issues? If we can, let's get on it. Let's fix them. And if we can't, then we pass them up to our management team, who are literally running around crushing barriers. That's what they live for, because we've given them purpose now, right? And they know how the organization works. They know how to get around those challenges. We did this with one asset manager, and they went from, you know, we told you about the 700 plus risks, they got them down to about 5050, risks, 60 risks, which, in a large program, you tend to have a flowing number of risks that you have to be you don't go down to zero risk, because that's just doesn't seem realistic. Yeah, it's not realistic. It's not real life. But you go to a scenario where things that are coming up are being passed up the chain of command or down chain of command, depending on how you think about it. And you've got management teams doing that stuff. You've got teams themselves using blended approaches. So Theory of Constraints, we mentioned XP tool sets. We you know, we bring in professional testing. If you're in a software space, how can you test faster? A lot of the times we've seen, certainly in the asset management space, people will come in and they'll just bring in an army of testers, 3040, 50 testers. The worst we've seen is 100 plus testers trying to make it all happen. We come in, we bring in strong delivery processes, strong technical people. You hand that off to say, for example, automation, and suddenly, boom, you don't need 100 testers. You just need five good guys and some beers. So those kind of approaches, which scrum really gives you that kind of space to bring in and coordinate with, that's really the difference. That makes the difference?

Dave West  39:09  
Yeah, I think it's the point you raise that most teams can deliver a lot faster than it's the environment that they're delivering into that is slowing them down. It isn't actually the problem solving. It isn't actually the building code. If it's a software project or testing it, or even deploying it, it's the environment that gets in the way of that. And they spend all their time dealing with the environmental issues, going to meetings, making sure that you know, as opposed to actually getting work done and what you're doing in a using Scrum, a very almost, I don't want to say a simple approach, but a very straightforward approach, cascading turtles. Yeah, exactly turtles all the way down. Hey, I could talk all day about this stuff, Jay, as you well know, and it's super interesting. Because, you know, my personal mission is always about helping teams deliver stuff a little bit better and create an environment that fulfills their potential. And I think what you're describing is creating that environment at the at the enterprise or at the large program level. So I think it we could talk for hours, but we'll, fortunately, we can't, because we have, we have a time box for our podcasts. So as we finish up, you know that what we've talked about is really this idea of using Scrum as a fractal, almost applying it at many different levels in the organization, and up and down the organization, creating that transparency, ensuring we people know what they're trying to do, particularly in the area of middle management, dealing making these starting with retrospectives, to to sort of like frame the mission that we're on, etc. But if for our listeners, if you're listening to this today, how can, what can they do? Maybe they're in a program that seems to be on a spiral to disaster. What you know, is there any resources that they could leverage?

Jay Rahman  41:13  
Yeah, absolutely. Um, so what? What one thing that we we always give to our current clients or clients that are working with us, we have a resource that we give out, which is basically all the principles that have helped us reliably over the last 20 plus years, deliver our programs faster than ever before. So if you reach out to me at j@fractalsystems.co.uk I'd be more than happy to pass it along. Or you can find me on LinkedIn, as it's Jay Raman, and obviously it's fractal systems consulting in London. If you ping me on LinkedIn, or if you reach out to me and said on email, my team will be more than happy to send that along, and that contains all our principles that we've learned over the last 20 plus years helping firms deliver value faster than ever.

Dave West  41:56  
Cool. Well, thanks. Thank you, Jay, and thank you for sharing this today of our audience and and thank you for listening. Listeners to today's Scrum, to all community podcast. If you like what you heard, please subscribe, share of your friends, and, of course, come back and listen to some more. I'm a very lucky chat because I get to talk to a variety of guests talking about everything in the areas of professional Scrum Product, thinking, of course, today, obviously today, I was with Jay Raman talking about, how do you deal with large programs that are on a spiral of disaster? What? How do you solve those problems and get those move that move those programs into the area of success, delivering value, continuously, making stakeholders happy, and obviously ultimately delivering value to users. Let's let's get, let's stop that 95.5% of failed large programs, that's what we talked about today. So thank you for thank you for listening, and thank you and scrummorg,

Transcribed by https://otter.ai