Lindsay Velecina: 0:00

Music. 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. This episode is a previous recording of our live ask a professional scrum trainer series where a live audience asks questions of professional scrum trainers. We hope you enjoy this episode. Good morning, good afternoon, good evening, wherever you're located today. Welcome to today's Ask a professional scrum trainer episode. I'm Lindsay delacina with scrum.org and I'll be your moderator today, and I'm super happy to have with us, Jay Rahman here, one of our professional scrum trainers. And today we're our session is going to focus on avoiding and recovering from product delivery failure, a really burning topic. And we're expecting lots of great questions from our audience. You can start entering them now, actually, and welcome audience, and welcome Jay.

Jay Rahman: 1:07

Great to be here Lindsay, so

Lindsay Velecina: 1:10

very quickly about who is scrum.org. We are the home of Scrum, and we were founded by Ken scwaber back in 2009 and we offer professional scrum training and certification and ongoing learning. Our mission is to help people and teams solve complex problems, and we do that through these three things. And we have a lot of great ongoing learning resources on our website that are free, so feel free to check those out. You're probably familiar with them if you found this webinar. So that's awesome, and I hope that today's session plays an important part on an important role I can't talk today, apparently, in that learning journey. So with that, I will hand it over to Jay to introduce itself.

Jay Rahman: 2:04

Thank you so much. Lindsay, so great to see everybody. Me, everybody, hopefully. My name is Jay. I'm founder and CEO of fractal systems. We are proud representatives, I guess, and members of scrum.org but focus primarily in the coaching, consulting and delivery space. Our business is primarily focused on helping firms recover and deliver tricky projects and programs. Around 80, 90% of our work is around actually helping firms recover delivery and actually deliver those critical products that actually help forward affirmed strategy. So that's a bit about us looking forward to. Been doing this about 30 years now. So I've got, I've got some gray, gray, gray beard kind of thing going on. So really looking forward to to the questions. It's going to be fun,

Lindsay Velecina: 2:54

awesome. All right, so start entering your questions. I'm going to stop sharing. All right, so just utilize that Q A at the bottom of your screen, and that's where our questions will will be able to populate those So Jay, first question here, so what are the most effective strategies for recovering from a product delivery failure.

Jay Rahman: 3:23

So that that is a that is a big, big question. So what, what we tend to find is that just encouraging and ensuring alignment across the organization is probably, probably the first thing to look for. So what I mean, what I mean by that? So we try and coach companies and help firms align their mission, their management and their methods, or the mechanics. So mission, what we're talking about there is, is ensuring that firms have their leadership teams engaged. That's right at the top of the house. We firmly believe that actually the leadership area is the is the fundamental, or the foundations of any kind of successful transformation. Lots of people feel lots of people feel that way, but what that actually means for leaders is that not only do you understand what you're going and why you're doing Scrum and Agile, but you're also accountable and focus on actually supporting your teams from delivering and that also means the organizational change bit. So the mission has to be clear the very top level, then we kind of go into the management space. Now, interestingly enough, the middle piece managers tend to be left out of agility in most in most kind of organizations, there's these myths that managers aren't needed. But actually what we found is is that helping managers understand their role in an agile transformation and in a delivery, in a strong, focused or tough delivery, is critical. It's actually your management teams that can really supercharge the results that Scrum teams can generate. And then finally, the mechanics. So mechanics is at the scrum team level, making sure the methods are right and appropriate, making sure that teams really. Understand how to get the best use of Agile and Scrum approaches, knowing what they're doing, why they're doing it, making sure they're doing everything well. So as an example, you know, a review is not just a show and tell, it's actually a review, and understanding what that means. So those are the kind of three areas that we look for initially. The other thing is, is that we want firms to be aligned front to back. So what does that mean? So that basically means business and technology working as one. You don't have a scenario where, and you see in lots of large firms, where businesses told, hey, you know, technology will do the Agile thing. Don't worry about, you know, engaging. We'll figure it out. We'll train your product owners, and that'll be it. And then, so you tend to see a part time engagement from the business into the delivery side of things, and that can be problematic. So we want to make sure that the business is also aligned front to back, so vertically, so from the leadership teams through to management, through to the teams and horizontally, from business and technology working together.

Lindsay Velecina: 5:58

Awesome. That's a great way to set the stage here today. So thank you, Jay for that. So this next question here, so can you describe a taxonomy of product delivery failure? What are some common modes of failure, and how do you identify which you are dealing with?

Jay Rahman: 6:18

A taxonomy of prompted every failure? Not quite sure what that means. So in terms of when you're when you're looking at Broad delivery failure, what we tend to do is we tend to focus on delivery. So what you want to see is Scrum. Scrum, in essence, gives you an opportunity to inspect and adapt in terms of what the teams are generating and why and sorry and how. Most importantly. So what the most important piece to really is to kind of go through, you could even go through, like a Theory of Constraints, kind of element where you're looking at other teams delivering on time. Are there teams delivering as per, as per their product roadmaps? If they are awesome, there's not much for you to do. If they aren't, then it's really kind of like a detective fact finding kind of space that you need to get into. What is it that you know that the teams are failing at? Is it the teams are failing at the mechanics they don't really understand that? Is it that the teams are heading up against organizational challenges, and you need to look at those. Is it that the leadership teams or the the stakeholders response at the very top are not supporting organizational change or not, or are not unlocking resources, or, you know, or making the changes from an organizational perspective, or empowering people to make the change from an organizational perspective. So that's, that's the vertical piece that we tend to look for. A really common pattern, by the way, is that business tends not to be engaged, so certainly in the asset management space. But you see it everywhere, really, where business leaders are super busy, tend to have multiple jobs wearing multiple hats. And if you have a senior person operating as a sponsor or operating as a product owner service, then what tends to happen is they tend to pay the role lip service, and they're not giving the time that it actually needs. So that role, by the way, is a really, really big role. Product owners tend to be very involved in not just the delivery side of things, but thinking about strategically, thinking about where they need to be taking the product and tactically, how they can be supporting their teams. And that is that is nine times out of 10 full time job, but if a senior sponsor or senior leader in the business has a day job, then they don't have the time to do the product owner stuff, either. So what tends to happen? You tend to see conflict in that respect. So I'm not quite sure if there's a taxonomy, per se, but that's, that's kind of, that's kind of how we approach it,

Lindsay Velecina: 8:33

okay? And you did address some of the common modes of failure, and identifying them a bit, if you need us to dig into that at all a little bit more. Matt was our listener who asked that, so please clarify in the chat if for some reason we didn't address your question completely. But I think you covered that pretty well. Jay, thanks, by the way, if

Jay Rahman: 8:54

there is, if there is some further follow up questions, you can connect to me on LinkedIn, I'd be more than happy to jump on a call with anybody, and we'll kind of figure it out from there. So

Lindsay Velecina: 9:03

fantastic. All right, so based on your rich experience, what are the key areas a scrum master must focus on to avoid project failure? Can you give some specific scenarios?

Jay Rahman: 9:18

So I think you know, the thing is probably the most annoying response to that question is, it depends, but, but, you know, we, we, we always say context is king. Okay, so if you so as a scrum master, make sure that you yourself are well versed in the practices you understand what your business is doing. How does this business make money? How does the business work? Understanding all those sorts of things and how the business is structured is fundamental to being a great scrum master. And I'm assuming that you already know scrum well, and you're continually working hard at your coaching skills. You continue working hard at your soft skills. You continue working hard to build relationships. So those are. Those are the kind of areas that you should have as a baseline. The as sort of, as I mentioned to Matt a little bit earlier on, Scrum Masters need to be very kind of problem aware and have a low tolerance for problems. What does that mean? So as a team is struggling through and as transparency gives you the opportunity to kind of inspect where the team is doing well and where they're not doing so well. So as an example, you have scenarios where, I'll give you an example. Actually, we were working with a firm that generates over a billion dollars in revenue, and they had a scenario where their teams were consistently getting stuck on multiple dependencies. And what that was about was that someone somewhere had decided that the best way to optimize that optimized, optimized collaboration across teams was have multiple specialized teams, so which sounded great on paper, right? Because you have these ninjas that are working these kind of in these teams, which live in golf and then do stuff for people. What actually happened was, was that, inadvertently, those teams became brittle. What does that mean? So whenever one team wanted to get something done, they'd have to draw on the specialized team for support and for help. Now, being the only specialized team in the firm meant that they had a massive drain in their time, that those specialized teams were constantly context switching, which slowed them down. And what's what slowly, slowly happened as more and more teams came on board was that you had severe bottlenecks, you had massive dependency problems, and people started complaining. So it didn't really matter what the teams themselves did, as long as they had a dependency on another specialist team, they couldn't get stuff done, they couldn't get stuff out the door, and they certainly couldn't move rapidly. So what we were helping the Scrum Masters do was actually to help teams understand that actually, it's probably a great time now to start to begin to cross skill. So now what you're doing is the principle, simply, is, is bringing in all the skills into the team, right? And even if it's a specialist function, the idea is, is that, can you do it well enough that you're that you can get the majority of the work done? So moving team members away from just being, you know, one skill, one function, to multi skilled and being able to operate two or three different skills and do it in a way that's generally good, was was an organizational change that we had to make so a scrum master would be able to support that and help that and basically raise that to the surface. Part of the challenge that Scrum Masters have, by the way, when they're making organizational changes, is being able to convince the business that actually or or even technology or the leaders to be that actually this change is a change worth making. And so what we what we teach and coach SCRUM masters to do and teams themselves, is to also think about when you have friction, is to try and work out, what does that friction cost the organization? All right, so if you've got something which is mission critical, but it's going to take six months to deliver it because you've got a dependency on something, then what is that in terms of cost? What is that in terms of lost opportunity? What is that in terms of delivery delay and revenue generation? When you start to think and and start to articulate your challenges and those sorts of terms, what you tend to find is you tend to find senior leaders paying close attention and being able to you're giving them the right information, then to be able to make the calls that they need to make to help you then get your job done. Hope that helps so context, use problems and transparency as your signposts, is what I'm saying. Yeah,

Lindsay Velecina: 13:23

that is great advice there. Thank you. Great question that came in. So this question here, so why are companies and businesses focusing on implementing frameworks and methodologies rather than implementing reflection on the individual level and continuing from there and creating real impact. So I think the question is very much focused on companies that just focus on the framework and don't think about any anything else affecting their business and adapting to their business or anything like that. So what have you been seeing with that? And maybe an example or story of how you, how you helped an organization adapt a framework to their needs.

Jay Rahman: 14:08

I think, I think a lot of times agility is sold as a silver bullet. So people come along and say, Hey, let's do this collaboration thing, and we're going to make millions, and it's going to be fantastic. And collaboration as as a sales pitch is a great thing to sell. Very few people are going to say, hey, let's not collaborate. So you tend to get high uptake when it comes to very much right frameworks tend to be sold as silver bullets. Good leaders will understand and when you when you approach them, good leaders will understand that actually the purpose behind agility is probably the most important piece. So we worked with a Swiss FMCG firm. We had about 17 of their senior leaders in a room together, and the first question I asked them was that, Hey guys, so why are we doing this? Why are we doing Agile? Is it because I. The firm across the road is doing it? Is it because of Spotify? You know? Why is it? What is the reason behind this? And what? What do you think you know are the benefits from the business in terms of going down this road? That's an important question to ask, because, without a strong why a firm will not, will not stay the course when things become difficult because most firms are not optimized to work in an agile way. And there is turbulence. There is things that need to happen to make agile, agile work. So I think the thing is, is that the key piece of this is being is bringing the entire group on the journey, on the ride, leaders and managers, by the way, need to understand why Agile is appropriate for the firm, and most importantly, understand and be cognizant of the barriers and the frictions that they're going to encounter when they're going Agile, right? Because most firms, as I mentioned, are not optimized for that. They're optimized to work in a more of a sort of waterfall way, in a more of a kind of slower kind of a slow kind of way. You know, they're managing through PowerPoint and Excel and email. They're not managing through rapid conversations and all this kind of stuff, right? They're not, they're not designed to operate like that. So a lot of the times, you want to be able to help them understand the purpose beyond why they're doing it, and, most importantly, become aware of the challenges that they're going to encounter along along the journey. That way, when things slow or they don't get the results that they're looking for, because of transparency, right? They can start to look at, okay, what obstacles are we facing? What do we anticipate, and what do we need to do? And therefore, they're they're much more engaged. I think also the way that Agile is sort of sold to the business is that a lot of the times it's sold as a technology initiative, which is completely incorrect for Agile to work well, business has to be engaged. We always engage the business. So we will never work with we seldom work with, actually, any firm that hasn't had a strong understanding, from a business perspective, of the reasons behind agility, what the journey is going to look like. So we always engage with the CXO layer, CTO layer. See, we frequently find ourselves speaking to directors, program managers, but engaging with CIOs, CTOs CEOs, so they understand what they need to do and understand the fact that they are they are accountable, right for the actual change to happen. Hope that helps.

Lindsay Velecina: 17:23

That is great. Thank you, Jay and thank you for submitting that question. So this next one here, so does an increment where there's only maintenance of the product or an internal improvement rather than a new function or feature mean failure in the Agile world,

Jay Rahman: 17:45

does an increment that. So what was that? An increment that does

Lindsay Velecina: 17:48

an increment where there's only the maintenance of a product or an internal improvement, rather than a new function or feature mean failure in the Agile world? So instead, instead of them releasing a new feature, they're doing maintenance or an internal improvement. She's they're asking if it's failure. I don't,

Jay Rahman: 18:12

I mean, that doesn't constitute as failure. To me. If you're improving, you see updates happening all the time, right? So most firms will release a product, they'll learn. They'll learn better ways. They'll find they'll find challenges, and they'll make it better. And I think that's, that's probably the hallmark of agility. You know, incremental improvement is, is not a bad thing, and it doesn't mean failure. If you've got a live product. I think it's

Lindsay Velecina: 18:33

a good thing. Yeah, I agree. I feel like this person is probably facing some sort of backlash or something where they're at now, if you have any follow up questions, please feel free to enter those. I mean, we're happy to help if you

Jay Rahman: 18:48

kind of, if you kind of think about EBM, one of the things that sort so that kind of prevents products from doing well is the friction in using the product. If a product is an amazing as an amazing product, but it's too hard to use, then the uptake isn't going to be there. I mean, I remember back in the day when windows would release a new you fix. This is years ago, right? I'm an old guy, you know, a lot of a lot of admins would not up, would they would not upgrade this their OS. They wouldn't, they wouldn't do it because they knew that if they upgrade their OS and it goes badly, the rollback would be too hard to do. They wouldn't be able to recover from it well. So what you tended to find was that people would not, they wouldn't move to the new operating system, because it was so it was so traumatic a journey to get there, and then, if it went wrong, you couldn't take it back. So, you know, maintaining and making your product easy to use is, yeah, it's not, it's not a bad thing at all. It's a positive thing. Keep it going.

Lindsay Velecina: 19:49

It's great. Thank you. All right, so next question, sure, this seems like a loaded question, but per your. Expertise, which part of the scrum framework is often crucial to avoid project failure?

Jay Rahman: 20:08

Which part, which part of the scrum framework is It's crucial? Yeah, the way to look at Scrum is, it's, it's, it's got practices which are self reinforcing. So as an example, if you don't plan, your teams are going to be struggling, you know, all the way through, right? So if you don't, if you don't do daily, if you don't do your your daily scrum, teams may may not understand what's going on. They might not be able to detect challenges and these sorts of things. So the way to look at the framework is, it's not all or nothing, but aim for all. Okay, if I was to say there was one thing that you should never, never, never drop. It's the retrospective. You know, there's, there's lots of there's lots of practitioners out there, us included, that believe that if you if, if you started off with just retrospectives, you would eventually find your way back to scrum the retrospective, the ability to inspect and adapt every couple of weeks or every week, depending on your sprint size or your sprint current cadence, is the thing that will save you when things are going badly, okay and act on what you learn. But look, I mean where possible, not every firm is is ready to go. You know, full on, full on Scrum. It can be challenging where possible, aim to implement the framework. It will save you when things get difficult and challenging.

Lindsay Velecina: 21:26

That's great. Thank you. I hope that helps. So this next question, So, how can you move forward when three quarters through a project, it is failing on all levels? Do you accept that there's an issue and go back to the drawing board, delaying the project, or do you continue to pull in additional resources and skills to get it over the line and then do an evaluation piece?

Jay Rahman: 21:55

So is this like a Have you got any details on how this is is it single project, or is it multi team, or it's kind of a difficult one to so what would I do? So imagine, imagine it's what my team's delivering some stuff, and I've got dependencies on four other teams to deliver stuff and and they're failing, and that's going to impact the product, the product release or the launch, or whatever. The most important thing, actually, is that one of the things that you should be doing is in your reviews, your stakeholders should be seeing that day in, day out. They should be seeing every couple of weeks, or every time you're coming back on the sprint, the team's reporting on how they're doing and talking about their challenges and talking about their risks. I'm assuming your other teams are using Scrum. So there's going to be some kind of retrospective that's happening, and then together, you guys would work with your leadership team to figure out the best course of action. It's hard for me to say, hey, just, just bring in more resources and all these sorts of things. I don't, I don't know the context of your business. What I will say, though, is that we have been in, you know, we do turn around. That's, that's part of our DNA. And a lot of times, what will happen is, is that multiple teams are struggling with delivery. So some of the things that work are thinking about, what is it that you're delivering, figuring out where the frictions are in delivery, and fixing those and making sure your mechanics are strong, ensuring that your management team understand what's happening, and they're doing everything they can to unstuck, unstick your teams, ensuring that your sponsors understand what's going on, and also they your sponsors and leaders understand their role in being accountable executives and responsible for not just change but delivery, right? So that's I mean when I talked about that alignment from leadership all the way down, leadership, management and teams, you have to make sure transparency goes up and down the chain of command and everyone is aware of their responsibility and making sure that delivery happens. So if you have other teams that are struggling again, look at the mechanics, look at the management structure, look at the leadership teams. Make sure that you've got alignment and engagement all the way through and work work from that. If it's mission critical, like, say, for example, you've got regular reg stuff coming through, so regulatory change, which will impact the firm, you know, dramatically, then you need to take a call. And if you can, bring in stuff, manage scope, reduce scope. If you can, I always find that reducing scope is a lot better than adding scope and bringing in more teams, because then you've got the whole ramp up side of things that has to happen as well, right? So, you know, it really is a it really is contextual, and it really does depend on the risk that your firm, your organization, is going to face if they don't deliver. So as an example, we were working with an asset manager that had reg stuff that needed to be hit. So if we didn't hit it, the bank would face tremendous penalties that they couldn't afford. So in that respect, it was an easy call to start to bring in some more people, start to think about how we can manage the scope, have conversations and open up conversations the regular regulators to try and reduce or mitigate some of this. Job that we had to deliver. Think about what we could deliver on a piecemeal basis. But all of those things were business decisions, and the management team sponsors and teams themselves were aligned all the way through the process, so that that's what you need to do. All right, the thing to be aware of is that when you're delivering product, or if you're delivering something that you must deliver because of their financial difficulties or whatever. If you don't do it, then your entire chain of command, including your sponsors, including your managers and your teams, need to work together to figure out what's the best way we can achieve this for the firm. There's no There's no sort of silver bullet in that respect.

Lindsay Velecina: 25:40

Awesome. Thank you. I hope that helps. If you need any clarification, please enter that into the chat. So come

Jay Rahman: 25:47

on, come and find me afterwards on LinkedIn and whatnot, and we'll, we'll chat. Awesome.

Lindsay Velecina: 25:53

All right, so this next question, senior leadership wants to report velocity across multiple teams, but story point values and team sizes are varied. How can we roll up reporting across multiple teams? What alternatives are there to velocity?

Jay Rahman: 26:11

So velocity, so senior leaders trying to compare velocity is probably one of the oldest challenges that we see everyone what, what actually the term velocity is, in itself, is a challenging term. Velocity is a planning tool. It's a tool that's designed to help you think about, for you as a team, how well, or, you know, how much stuff that you can pull into a sprint to have a strong confidence of actually delivering it. So that's what it's about. And every team has its own challenges. Some teams are doing vanilla work, which is pretty straightforward, and so their velocity is going to be different. The way they size their work is going to be different. If you have a team that's doing highly complex work, we work with quants, for example, looking at markets and you know, they're literally rocket scientists doing high level mathematics and all this kind of funky stuff. So, you know that, you know for them, you know that the way they story point and the way that they size work is going to be different. You know, it's not the same thing. So teams are not comparing apples to apples and oranges oranges. So that's, that's the first thing to think about, right? So the other thing to think about is, what is it that they're trying to do? So, you know, what is the purpose of looking at velocity? What is it you're trying to do as a leader? A lot of times, when they're looking at velocity, they're trying to find ways to generate efficiency. They want to know, are we actually going quicker and faster, all that kind of good stuff. So if that's the case, then really, a really simple, a really simple thing to think about is that, are we achieving our sprint goals? That that's really probably the most telling metric that you've got, if you've got a sprint goal that you need to deliver, and the team has you've got, imagine, you've got a 10 person team, that team has worked together, thought things through. You've got a fully engaged product owner. You understand the work deeply, and you've gone, you know what? We can get this done in two weeks, and you miss it, and then you miss it, and you miss it and you miss it. Then what that's telling you is that your team needs help, okay? And leaders, if that's if they're trying to help you go faster, all they need to do is to pay attention to just bring goals. Are you achieving them or not? If you're not, then you need help. And either the Scrum Masters doing everything they can, or there's organizational impediments, or there's something else the teams need to look at with their leadership team to try and figure things out.

Lindsay Velecina: 28:29

Hope that helps. That's great. Thank you.

Jay Rahman: 28:32

And you know, follow up, a follow up question is absolutely fine. So if it's something else, apart from speed, then ping us back and we'll try and go from

Lindsay Velecina: 28:41

there. Awesome. Thank you. Hope that helps. So this question so it says this comes from Brian. Let's shift the discussion a little bit to the aftermath of a product delivery failure. What for you are the best practices to adopt in order to recover from such failures at the scrum team level,

Jay Rahman: 29:04

sure. So the first thing is, is that for so when, when a product delivery failure is occurring, I'm just going to kind of go back a bit, then I'm going to go forward if, if teams are operating in an agile fashion, then leaders, teams, managers will have been signposted ages ago. You will see Scrum Masters team members being vocal during the sprint review, saying, Hey, we're managing this risk, this risk, this risk. We haven't achieved our spring goal. We're trying to do this, we're trying to do this, we're trying to do this. And you'll see it. You'll see a pattern of challenges. Okay, so product failure, in and of itself, shouldn't be a surprise. You shouldn't just go, Oh, we didn't deliver it, you know? Or we missed the target. You'll know that the target's being missed. Uh, you know way, way before you know the target comes if your, if your product owners are engaged, they're going to have a product roadmap. They'll know that your, you have a series of product goals, or sprint goals, sorry, that you should be achieving to achieve the, you know, the end goal. And if those sprint goals have been consistently missed, then savvy, wise product owners will be engaging their sponsors will be engaging their leadership teams and saying, Hey, listen guys, this isn't going the way it should be going. Okay? So you should never arrive to a scenario where you have a drop dead date and you missed it and everyone's surprised. Everyone should know what's going on. Okay? Way, way before it actually happens. We ask, we ask, we ask our product owners to have different product roadmaps in terms of timelines. They'll have a long they'll have a yearly goal. They have a yearly timeline, broken into quarters that have quarterly goals, that have, you know, sprint goals themselves. So as an example, what we tend to find is that imagine you've got a quarterly goal. Well, that's six sprints, okay, if you miss three sprint goals in a row, you're behind 50% which basically means you have to go 100% faster to achieve that, that quarterly goal. So in essence, if you miss three sprint three sprint goals in a row, and you're communicating that well to your your leaders and your sponsors, you're going to see that in the sprint reviews, and they'll have six months, six weeks notice, saying that these guys are going to fail to sprint. You know, the quarterly sprint goal, they're not going to make it because they can't go 100% faster. So that's the first thing, right? So the thing is, always, always, always, set it up that so that your teams are managing risk, are being vocal with their risk, right? And are engaging leadership teams all the way through delivery that way. There's no surprises. Now, that being said, if for whatever reasons, you know frequent you know nature, you know system goes down, power goes out, something crazy happens, an act of God, and you miss the goal, or there's something's happened and you kind of missed the goal, and everyone's surprised. The first, I think the first I think the first thing to do is to do a retrospective. So we've run program retrospectives. We have 5060, up to 100 people in a room, all the teams, and we go, okay, guys, and you structure it. You can use things like liberating structures and all these sorts of things. Have the leadership teams there, and then start to think through and run all the you know what happened? You know, when we think about our program of work, what happened? What? What went right? What went wrong? What could we have done differently? What were the triggers that we missed? Right? So, for example, if we were falling off a cliff and as a slow car crash, there must been some trigger there, right? What? What do we miss? Did we have regulators come in last minute.com and give us a regulation that we weren't prepared to to prepare to meet. We couldn't pivot quick enough. Was there a market shift? Was there a market change that we released a product then that wasn't viable? Was did someone else release the same product faster than us? And get, you know, get first mover advantage? Did all that stuff happen? So all of these sorts of things come through your retrospective. So, and don't be afraid to, you know, have a retrospective at the program level, at the multi team level, once you gain the data, that should then give you an opportunity to reflect, think about, what are you going to do differently? Are you going to continue with the product? If or are you not going to continue with the product? What is the call you need to make? But I think the first thing really is, that when you're dealing with failure, I mean, I'm assuming from a from a program level or from a multi team level, that if you haven't done all the right things and you haven't signposted and you haven't you haven't been running your reviews properly, or your retros properly, then you're going to be surprised. But if you've been doing all those things, and no one's going to be surprised, and everyone's gonna be working really, really hard to help you succeed and win.

Lindsay Velecina: 33:43

That's some great advice, and that retrospective really is key, and this is a really good segue into our next questions. So sorry for the rapid fire, Jay. We're just trying to get through all these questions. There's some really great ones that came in. Thank you. Audience. Keep them coming. So do you have any advice for managing, launching a new product when prior launch of a similar and now obsolete product and the same organization was poorly received and there are negative associations?

Jay Rahman: 34:16

Yeah, yeah. So that, I mean, I think the first, the first thing is, is, if you've so the great thing about your situation is, is that someone, somewhere has done it before. So what the first thing to do is, if that, if team members that were around, I mean, we did some stuff with a with a with an insurance firm, actually, that had a very similar scenario. A product release happened a year ago, or something like this. I'm changing the names and the dates and everything to protect the innocent, and it was poorly managed. There was, you know, support wasn't on board all kinds of things. All the things that should never have occurred occurred. So the first thing. Did this time round was to bring in all the people that were engaged in that previous release. And we just, we just went through hate. So what went wrong? What happened? What you know, what challenges did you guys encounter? What challenges you know came up that you didn't anticipate? And so look, if you've got a scenario where people have done it before, a retrospective, believe it or not, is probably the easiest way to gain data. Data gives you transparency, okay? And most importantly, what we ask them to do is that, if you were to do it again, what would you do differently? What risks would you be aware of? Who would you engage? How would you manage it? So those people have got the benefit of hindsight, and you know, hindsight is always 2020, okay, so the first thing is to get data figure out what they did wrong. Now, nine times out of 10, you'd already figured that out, but it's always great to get help from people that have already been there, done there, and got the t shirt. And, you know, bad experience is great still, is still great experience. So learn from or at least have them highlight some of the challenges that they found that will then give you insight into some of the frameworks or some of the difficulties that they encountered and some of the things that they anticipated or didn't anticipate, which should hopefully feed into your plan. Asking them differently, you know, how would they do it differently? Will also give you some insight into a plan that they would then use. Okay, then make sure you plan as a team. Okay? So a lot of the times when releases are happening or new product launches are happening, sometimes what you have is you have a very small subset of the entire team working together to kind of deliver, to deliver it or make it happen. It's critical when you're planning to bring in as many appropriate heads and many appropriate people as you can so that's your senior developers, that's your test team, all these kind of people that are going to be involved in the delivery, and have them think through what are the risks that you think that we're going to encounter? Catalog the risks, figure out what they are. Be risk, be risk aware. All right. Agility, the transparency piece of agility helps you, certainly in Scrum, helps you figure out what risks you're going to be facing, then work hard to mitigate and manage those risks. Okay, and be aware of them. Risks don't just disappear, and your team will have insight in terms of what challenges you're going to be facing. Most importantly, right? The guys and girls that have done it before will tell you what they didn't anticipate and what and what the right thing to do is this time around, that way, when you're making a group plan, all right? So it's not just you or three guys or girls planning. You've got a team planning together will help you kind of come up with something which is robust, right? Takes into account previous organizational experience. And next thing is to probably pressure test it and go, do you know what can we? Can we do some? Can we run this and see if it works? Can we do a small release and see if it works? So if possible, if you can take the pressure off some, can you drop it down to a bite size release, something that gives you what you need or delivers a part of the functionality without breaking, you know, breaking the organization on the firm, planning as a team makes it makes a massive, massive difference. We do this all the time. We tend to find that engineers, testers, you know, architects, business heads, will come along and give you insight that you hadn't thought about. The guys I've done it before, they will give you insight that you've never thought about, and most importantly, they'll give you a vision that if they if they had done it differently, what they would do, and that will then factor into your plan. Hope that helps.

Lindsay Velecina: 38:30

Great. Thank you. This next question, so it says not necessarily a question, but it actually is a question. Could you share some of your favorite ideas, themes and ways to organize a retro, maybe particularly around a failure, like what we're talking about. So

Jay Rahman: 38:53

I like to. I like to so if something, if something bad has happened and the team. So let me my best. My best retro is really, and I'm telling you a secret here is, is the donut restaurant? Is that it's the donut retro? So whenever I'm whenever I'm doing retrospectives, and it's tough, or we've just been through some horrendous scenario, and that happens, right? This is real life. You're working really, really hard. Something's gone wrong outside your control, or even or even worse, it's inside your control, and you didn't anticipate it. You know, the team, the first thing to do is to lift the team up. I think so nothing helps lift the team up better than first the change of scene. So if you're going to do a retrospective, and it's going to be something which is difficult and challenging. The first thing to do is to change the scene. Get out of the office, try and go somewhere else. Do it somewhere different. I like to, I like to think of, I like to try to get to parks, or I try to go to an environment where there's lots of windows and lots of air. I'll bring donuts. I'll make sure we've got donuts and coffee and food and all these sorts of things. I. Then what I'll do is I'll always, always, always start my retrospectives, especially when they're challenging, with the retrospective Prime Directive, so that basically I haven't memorized it. But basically, if you check that out the retrospective Prime Directive, what it does is it emphasizes the fact that everybody in a team is trying their level best to deliver okay, and that the results we we achieved, we achieved because of the limitations in terms of what we did and didn't know. But never, when it comes to delivery is there a bad actor, and I think that's really, really important setting the scene, that look, we're all trying hard, and that there's a positive intent behind everything that we've done, and we've all worked to do this and it, and it's, it's a team. It's a team. Sort of impact is probably the thing to start the retrospective with. Then you can, you know, I think the next thing to do is to, I don't think you need to do anything fancy. I know people do, like, do boats and anchors and all this kind of stuff. I think once you've set the scene, then you can, you can just do a simple, Hey, so what went wrong? You know, what? Where do we go wrong? What are all the things let's, let's collect that Intel. What, what happened? And giving yourself, you know, time to think that through and actually have the team reflect on that is probably the first thing. You can use patterns like one, two for all. So if you're using liberating structures, you a one two for all pattern to gain that information is a great pattern, especially if it's a big team, and that if you don't know one two for all, it's simply asking team members to think about top 345, reasons why they think things didn't go well on their own, and then finding a buddy, working out between themselves, what then you know, what was? What were the top 345, reasons coming to a consensus, and then doing that with a bigger group of four, and then finally reporting to the the entire team. What that does is it kind of helps people think through the challenges. Helps them think through probably what the most impactful, most important challenges were, and then presenting it back to the group, and then thinking about, Okay, now we've got the challenges, all right. Now we've got the things that derailed us. Well, what do we you know, dot voting those those challenges. So then what you can do is you then go, 124, then you do a dot vote. The team tells you, hey. The whole team says, Hey, this is the most important. This is the most important. It's the most important. And then tackle them. That's probably a good on the off the cuff, on the fly retrospective,

Lindsay Velecina: 42:21

using that is awesome. Thank you. And think a key takeaway from this session is, Don't skip your retrospective.

Jay Rahman: 42:30

Don't skip your retro. I mean, I think, I think the most powerful element of Scrum, really, is transparency. Transparency and the ability to get data, okay, is the key. You know, if you can create insight and data, you can then act on it. I mean, I know there's this whole AI revolution going on at the moment, but AI is nothing without great data. You know, it's garbage in garbage out, right? So the first thing to do is to work hard at building transparency, then you can inspect and adapt. Without transparency, you're not going to get anywhere. And transparency is the hallmark of agility and, most importantly, key for our retrospectives, for great retrospectives, also work hard at your soft skills, right? Soft skills really are the hard skills. So if you don't know exactly that kind of stuff, get out and learn that stuff. It's important, absolutely critical.

Lindsay Velecina: 43:15

Yes, definitely. So here's a product owner focused question. So what kind of support can a product owner contribute to the team, and how can the product owner help with avoiding a product delivery failure?

Jay Rahman: 43:32

So that's a great question. So the first thing is, is that what, when I see product delivery failures, sometimes, what tends to happen is the team, you know, the product owner asked for an apple, the team delivers an orange, and they go on, what's going on here? The challenge that most product owners have is, especially if agility has not been well introduced into the firm, that they think that the product owner role is a part time, it's a part time gig that I can do whilst I get my day job done right. So that basically means product owners are not working hard to help teams really understand what it is they're trying to deliver and what it is they're trying to get out the door. So I think the most important thing that product owner can do is give their teams time. Be present, be available. Okay, we, although we don't mandate product owners to turn up to dailies. We highly encourage product owners to turn up dailies. So nine times out of 10 when we're whenever we're involved in a delivery, you'll see our product owners rocking up to dailies and just listening in and working hard to try and understand that. Does it is a team on track? Do they understand what they're delivering? Do you know, is there any kind of signs here that they need support and help, clarification, all that kind of good stuff. So that's probably the first thing give your team's time. The next, the next, probably the most important piece, really, is work to ensure that you're doing great refinement sessions. Now this really is a secret source of speed. Okay? Okay, a lot of the times refinement sessions are missed. For those of you that don't know, I mean, Scrum doesn't mandate refinement as being mandatory, but we do. We make sure that our product owners and product owners that we're coaching, product owners that we're putting into firms, any kind of recovery that we're doing, product owners are working hard in their refinement sessions. Refinement session is basically where the team is thinking about the work coming down the line, and they're working really, really hard to understand what it means. They're thinking about the nuances. They're thinking about the risks associated delivery, the assumptions, any kind of issues, any kind of dependencies. So that when the PBI, the product backlog item gets to the actual sprint. It's, it's so well understood, right? That it's like, it's, it's almost, almost estimated. All right? A lot of times in our environment sessions, you find teams able to estimate the work because they understand it so well. That is one of the secret sources of speed. So product owners should be spending time with their teams, giving them their time, turning up, making sure that they are on track, that they understand what they're doing, that there's no questions around delivery, in terms of what is it that I'm delivering? They they're making sure that the teams understand the work prior to the actual sprint commencing. Okay, they've worked hard to articulate clear roadmaps. They know. Teams know the why behind the product. They understand what good looks like to a strong depth and all that stuff takes product owner time. You can't, you know, gone are the days where you can just write some funky requirements and throw them over the fence and expect your agile team to deliver them. Because, you know, as far as they were thought, as you know, you've mentioned some you described something, and the written medium is probably the worst way to describe stuff, because you miss all the nuance, right? So spending time making sure you're doing the refinements, making sure you've got strong planning, you're engaged is important also, I we sort of encourage our product owners to run their sprint reviews. As far as we're concerned, product owners should be running the sprint reviews, and the delivery should not be a surprise to the to the product owner. The sprint review is not for the product owner. You should know what your team is delivering and know how they're doing and know where their challenges are, because just like you, just like everyone else, is responsible for the the achievement of the sprint goal. So those are some, and I'm giving you a lot here, product owner. Product ownership is probably one of my favorite areas of support, and actually one of the areas that firms really, really struggle with. It's one of the areas that we really kind of focus hard on in terms of helping firms kind of pivot away from failure.

Lindsay Velecina: 47:36

That is great. Thank you, barrage.

Jay Rahman: 47:38

There's a barrage there. Lindsay, sorry

Lindsay Velecina: 47:40

about that. It's okay, possible. I think this is very valuable to our audience here. So this next question, there were a few stakeholder focused questions. So this one kind of touches a few of them. So what is the best way to prioritize requirements from stakeholders if the stakeholders themselves are not in agreement with reach impact and complexity of a feature. So there are a few questions like this with stakeholders not being on the same page.

Jay Rahman: 48:17

So if you have, if you have three or four stakeholders and they all disagree, then I would, I would work hard to try and get agreement. That's the first thing. The thing is, is that what you should probably do, so, just to be really clear, in most from a framework perspective, from a scrum framework perspective, the product owner has the final shout when it comes to or the final call when it comes to building out and figuring out where we're going to go and what we're going to do. Right now, in practice, most firms are not, they're not, they're not structured like that, and stakeholders get really annoyed if a product owner takes a decision which they don't agree with. So the first thing to do is to try and work hard to build consensus. Think about what are the what are the key metrics and the key levers that stakeholders are thinking about, right? So and ask them, you know, what is? What is the most important thing to you? Is it? Is it revenue? Is it delivery? Is it what is it the I mean, and work hard to understand what those metrics are that all the stakeholders can agree on. So what are the key metrics that you Mr. Stakeholder, or you miss a stakeholder feel is the most important thing work, work to get that work to get that sorted first. Okay, that way you can then you can then figure out where the consensus lies. Because ultimately, if, if the, if the most important thing is ROI versus cost, then you can figure out that. Then gives you some ways to kind of think about your your product roadmap and all that kind of good stuff. If you still have, if you still have disagreement, okay, then the next piece is escalation, right? So if you, if you cannot deliver safe. Be without the team getting in trouble, or without you getting in trouble, then you need to escalate and find ways for your senior leadership to get involved, to break the deadlock. A lot of times, sponsors and stakeholders are super, super senior. I mean, we've been scenario. We've had scenarios where product owner is, you know, here, and you've got someone from the board, or, sorry, someone from the, you know, the management team, so the CXO layer, who's taken a specific interest in a particular project, and it's their pet project, and they're really interested in getting it done, and they want to get it done their way or the highway, right? And the product owner doesn't agree with the direction, or the team doesn't agree with the direction. So a lot of the things that you can look at is, you know, what is it that we're using as as key differentiators to be able to make that decision? Okay? So, yeah, ROI delivery. You know, ROI, time to market. If you're doing something which is which requires first mover advantage, then, you know, that kind of stuff. So those are the kind of metrics that you'd be looking at. I think these are business decisions more than anything else. All right, that helps the leadership team. Then kind of prioritize, okay, what we're doing first, what we're doing next. You know, if you don't, for example, if you, if you, if you're, if you're going for first move advantage, and you don't deliver, deliver something, then how much is that gonna How much is that going to impact the firm? How much revenue loss are we going to generate if we don't, if we don't deliver something? So those are the kind of conversations and questions that you should be bringing to your stakeholders and make sure that you agree what the framework is with all of them. Most stakeholders are quite reasonable, by the way. There they will. They're usually, their intention is usually to do something for the benefit of the business. No, I don't. I've never met a stakeholder says, you know, hey, let's run the business into the round. They're thinking about, how can we move this forward? And then turn internally, they'll have some ideas around what are the key things that they're looking for. So I think the most important thing is to bring those things forward, make them transparent, and then try and get agreement across that. If you don't get agreement across that, and you are not empowered to make the final call, alright? Then escalate. Make sure your management team is supporting you. Get those guys to break the deadlock. If you do have, if you are empowered to be able to make the call, then make sure no one's surprised, and make sure that if you do make the call, you're backed by data. You understand why you're making the call. You understand what it's going to do for the business and what would happen if you didn't. Happen if you didn't, if you didn't do it, and the impacts, and make sure that's really, really clear across your stakeholder team.

Lindsay Velecina: 52:28

Really great advice there. Thank you. I hope that helps. That was, that was great, and that touched a few of the questions that came in as well. So we have time for like, one more question here. I i apologize to the audience that we weren't able to get through all of them. I am going to share them with Jay. We will figure out a way to get them addressed. So don't worry. It was, yeah, I've had to sift through a lot of questions here, and they're all great. So everyone's

Jay Rahman: 52:57

going to be hitting me on LinkedIn and stuff. Yes, feel free, right? Just come and find me on LinkedIn, and you know, I'll do my best to try and help you perfect.

Lindsay Velecina: 53:06

So this question, so how can we, how can we foster a culture of accountability and ownership to ensure everyone is committed to turning our failures around, utilizing OKRs? So that's part one of the question. And part two,

Jay Rahman: 53:24

hold on, was it the so you want to use OKRs to foster ownership and accountability? Is that what it was yes

Lindsay Velecina: 53:32

to? So how? I'll repeat the question one more time, sure. So how can we foster a culture of accountability and ownership to ensure everyone is committed to turning our failures around, utilizing OKRs. And the follow up question that is here is, in your experience, what have been the best metrics measured to support delivery progress and identify potential issues early on? All

Jay Rahman: 54:01

right, let me do the first one, so you might have to remind me of the second one as I get involved. Okay. So, so look, OKRs is a great tool for aligning. You know, we talked about the chain of command earlier on. We talked about sponsors, managers, teams. So OKRs is actually a great tool. We use OKRs all day, every day, but in terms of changing culture, what we find is the guys and girls that really, really, really make an impact in culture change are senior leaders and managers. It sell them the teams, you know, teams you know when we when we see as an example. So I'll give you examples. So we working with an asset manager, asset manager in in Switzerland, in Zurich, and we were one of the things that we were doing, one of the things that we always teach is that we teach this concept of the the Accountable executive, right? So working with the CXO layer, working with the sponsors, working with the very top of the house, what we, what we, what we, what. Um, what we sort of not demand, but what we encourage people to do is to say, look, if the teams aren't delivering and if the organizational change isn't happening, Mister leader, then ultimately it's you are responsible and you are accountable. Okay, so that's the very top of the house. Okay? So that that is actually really, really important. Because then those leaders that take on that responsibility, it's uncomfortable as well, right? Because, you know, no one really wants to be told that, hey, if the teams fail, and I'm super senior, that it's it's on me, but, but ultimately, leaders and manager, sorry, senior leaders are the ones that can make organizational stuff happen really, really quick, happily for us, is that that that that particular notion was well received and well understood, and as an example of that, one of the things that was happening was when the teams we asked, what we asked the teams to do was to kind of collaborate in one space. So this particular bank had something like, you know, you know, 3040, different locations, where people were spread all over the place. And what we wanted was, we wanted everyone to come into one massive space and where all the teams are working together. There's no way the teams were going to do that. There was no way that they could manage that. The team leaders couldn't do it, the managers couldn't do it. It fell to the Coos to try and make that happen. And they did make it happen. So within, within, I think, about four weeks or two sprints, they committed to making the move happen. And not only, not only, that's 100 people moved into a particular building, and that's 100 people moved out of a particular building without causing undue organizational stress and challenge. Now, when teams see their leaders doing that kind of stuff going first. And by the way, that those leadership teams were operating in a scrum cadence. So we were doing, we had, we had, we didn't have dailies, but we did have, we had semi daily, so Monday, Wednesday, Friday. And that was primarily because, at the time, these guys were super busy running a massive bank, and so we had to kind of flex a little bit on that. But we were doing retrospectives. We were doing reviews and all those sorts of things. And when the teams saw their leaders going first, like, if the if the leadership team at that level can do a retrospective and learn what they're doing badly and figure this out and turn it around and change their behavior, then that, that behavior, that example, begins to trickle down. You then start to see managers doing the same thing, right? Then you start to see teams doing the same thing. So by by then, by extension, you know, if a leader believes, hey, it's on me, if my teams aren't doing well, what they'll do is they'll work with their management teams. Hey, how can we support the teams? What can we do to get ahead of the teams? What can we do to get ahead of the challenges? What can we anticipate? You know, what are the things that are going to come along? They're going to bite us? What are the teams telling us? And then what happens is, you see this cascade effect. So you see the leadership teams at the very top making the necessary changes. You see the management team working hard to understand what the teams are doing and working hard to eliminate challenges and issues and all that sorts of stuff. And then you'll see the teams. The teams actually come last when team, when you see teams, we have, we've had feedback from teams saying, I never thought I'd see, you know, Bob CEO, involved in a sorry COO, involved in a retrospective, right? But the fact that he's doing that and learning and getting our feedback and actually being engaged and helping us is tremendous. So that kind of culture of accountability, openness, transparency and a willingness to learn trickles down. Okay? Now you've heard me say things about managers and management teams throughout this call, throughout this conversation, one of the things I want to emphasize is that, you know, although we practice and work for self organizing teams, that doesn't mean we leave behind our strong managers. Our managers are really kind of the glue between the very top of the house and the teams that are kicking ass at the bottom, and so those guys and girls need to have strong understanding of what makes things work. Their accountability isn't about micromanaging. Their accountability and their responsibility is to help eliminate the frictions that the teams themselves are going through. And when teams see that like tangibly, see that they see that their leaders and their managers see themselves as being accountable for support and helping their guys and girls, you start to see the culture shift

Lindsay Velecina: 59:21

that is awesome. Thank you so much. So we are at our time, and I want to thank Thank you, Jay, for taking the time today to answer these questions about product delivery failure, really big topic, and I want to thank our audience. You all stayed on for most of you stayed on for the entire hour. So that's that's pretty amazing to take an hour of your day to listen in. So thank you so much, and we will hopefully see you all again soon. And thanks again, Jay, and I hope everyone has a great rest. Of your day or evening pleasure. Come

Jay Rahman: 1:00:02

and find me on LinkedIn. Let's

Lindsay Velecina: 1:00:03

talk. Take care. Connect with Jay on LinkedIn, if you want to get in touch with him. All right, so scrum on and see you later. Take

Jay Rahman: 1:00:11

care. Bye, bye. You