Hey there, Agile Adventurer. Just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best Agile content on the planet? That's audio, video, e-courses, books, presentations, all that you can think of. But you can also join live calls with world-class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Fashko, your Scrum Master Toolbox podcast. No, this is not a drill. It's the Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org forward slash membership. That's scrummastertoolbox.org forward slash membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast. Hello, everybody. Welcome to our Success Thursday. This week we have with us Mukhtar Kadiri. Hey, Mukhtar. Welcome back. Hello, Vasco. So Thursday is Success Day here on the podcast. and we'll talk about success in a minute, but we also talk about a very important tool that we use to succeed with the teams we work with, and that's the agile retrospective, of course. And I guess in the PMP world, the most common term is probably lessons learned session or post-mortem. How does the PMBOK call it these days? It's been a while I've studied. I got my PMP a long time ago, But I think lessons then, even retrospect, because I think the PNPC is agile as part of the PM umbrella. So retros are fine as well. Yeah, especially these days because PMI acquired the Agile Alliance. Right. So let's dive into it. So share with us, Mokhtar, your favorite retrospective format and why. Yeah, so I'm a big fan of just keeping things simple. So I like the, you know, what worked, what didn't work and next steps. Right. So I, yeah, I just try to keep it simple. Why do you feel that that simple approach works in the context that you've worked, that you have worked in? That's a good question. I mean, I know there are like all these different ones, like mad, sad, glad. So number one, I just like simplicity. I think like as human beings, the rule of three is just something that we human beings just naturally understand. You know, so like, so yeah, I usually like when things are, you know, broken down into three parts. So yeah, and I think the retrospective can also be a very, it's a meeting that can easily go wrong if you don't run it well. So I like to just remove as much complexity just to create a safe space. And yeah, I think there's also a personal preference where I just like simplicity. you know absolutely and simplicity also allows us to to focus on the actual content of the conversation right but but one thing that i um i want to explore with you because simplicity is there to provide some sort of benefit right like whatever that benefit is if it is because it's easier to explain it's easier to get started it's easier to document it's faster to get to an whatever that might be, one of the core aspects of the retrospectives is productive conversations, right? Like, you know, we have a conversation about something we care about, whatever that is whether it was an incident or a sprint or a whole project or whatever or a customer interaction whatever that might be And then we want an outcome like an improvement something we learn from And that happens through conversation So in your experience, how does this simple rule of three style retrospective lead to better, more insightful, and therefore also more consequential conversations? Yeah. Yeah, that's a good question. So I think, yeah, and I'm thinking out loud with you here. So I don't know if it's necessarily just the structure. So I think number one, it's easy for people just to sort of know the map, right? So, okay, this is where we're going to go. There are three parts to this entire meeting. So I think it's nice to just have that map easily, you know, as opposed to like a six point agenda. So there's that. But I think you can also have that simple structure and have a terrible retrospective. So I think really what's important is making sure that everybody feels safe at the very beginning. So that's really critical. And, you know, I know there are some exercises that you can do, like icebreakers and all of that. But there are many retros that I've done without icebreakers. Right. But, you know, once there is underlying trust, you know, that allows people to be able to open up. And a lot of times trust is not necessarily built in the retro, like trust is built before the retro, right? Again, going back to the one-on-ones, right? So, and then, you know, coming in and maybe just level setting because a lot of times people are joining your meeting after another meeting, right? So, you never know what headspace that they're in, right? So, maybe just reiterating like, okay, you know, there's no wrong answers. This is just, you know, whatever you do just to make everybody feel OK, then you do that. So in my experience, to answer that question, not to have a very productive conversation. I think how you facilitate the meeting is really very important. You know, even things like tone of voice, even things like making sure that everybody participates. So, you know, we have a moment of introspection where everybody just puts things down on a post-it so that, you know, you can hear both quiet voices and loud voices. So how you facilitate actually matters more. And even this brings a good point, like for retros, I never go into retros blindly. Like I prepare for retros because if you run a bad retro, you could do damage to team morale and your project. Right. You know, because you can just, oh, yeah, you know, let's just knock this agile ceremony out of the. But if you don't do well, you can end up damaging your project. So you want to make sure that you prepare for the retro and then you come in and you are really facilitating it. I don't want to put it because there are different types of facilitation. You can just facilitate, well, OK, I'm running this meeting and I just want to see it to the end. But there is the active facilitation looking at who is not saying what, you know, encouraging quieter voices to, you know. So that is really what creates a productive conversation is the facilitation. on. Absolutely. I think that's a great addition to the point. It's not only the simple method or simple structure, but it is also the quality of the conversations through the facilitation we are able to perform. All right. And we, of course, do these retrospectives because we want our projects to succeed and our teams to succeed and ourselves to succeed. And you come here both with experience as a scrum master as well as a project manager so uh let's take those two perspectives together and uh share with us muhtar how do you define success for yourself yeah so i i think um yeah that's a good one so success for myself is usually success for the project you know um i don't know if this is yeah this might be a bit of a tangent but i'm the kind of person that when I'm leading a project, like I'm emotionally invested. I think about the project. That why like after a project finishes I need time just to just recoup I can just start the next project So some people so you know like when things don go well like it affects me you know emotionally as well I know, yeah, I've tried to separate, but, you know, so that's just the way I am. Like I'm fully invested in the project. So to answer your question, like what does success, so success for me when I'm leading a project, is the project being successful? And what does that mean? So I think if you're not careful with success, you can deliver a project, but the project will really not do much for the business. And I think there are lots of projects like, okay, we finish on time and everything, but what value has it brought? So I think it's defining what will be beneficial to the business. I know there's not always a straight line, but you want to make sure that you articulate that before you start a project. Like what value? Because projects don't exist in a vacuum, right? So that's one thing that I would say. Now, of course, you can now break that down. And the way I also think about metrics slash success criteria is that you can break that down. There are three buckets. there is like, okay, maybe the product slash business metrics, and then you have the project management metrics slash, you know, APIs, and then you have the software slash system metrics, right? So an example, product business, all right, we want to make sure that we increase MPS or, you know, weekly active usage, daily, you know, what have you, or we want to, you know, we want to be able to break into this market, increase revenue. So like that falls in the first bucket, business slash product metrics. And then the second metrics, which is project management metrics. So I think this also includes like the agile metrics, like, you know, velocity, your burn up, burn down. And, you know, if you want to add risk score, you know, like all of these things that have to do with the mechanics of driving this thing forward, right? So that's the project management metrics. And then the last one is the software slash system metrics. So I I bucket things like platform metrics, availability, memory, transactions per second, the things that actually show you the health. So I think, again, going back to the rule of three, I think a lot of times I'm able to define metrics that will be relevant to my projects in these three buckets. Very good. And when you think about these metrics for the success of the project, how do you go about setting up your own system to track those? Because one thing is to know, okay, this metrics I care about and I want to make sure I track them. But then how do you keep yourself accountable to yourself, not necessarily even to others, but to yourself that, yeah, I am actually doing the work to surface these metrics, to somehow have productive conversations, Maybe bring them to the one-on-ones or presenting them to the stakeholders. Like, how do you define your own kind of, let's call it, personal process of self-accountability towards that definition of success? Yeah, no, that's a good one. And so for me, I know I'm very, very driven by, like, I'm the kind of person that I like to make commitments publicly because that forces me to be accountable. right so at the very beginning i'll be like okay i i'm going to be giving expect status updates for me every week right and expect these kind of updates from you want to want to the steering committee want to leadership want to you know so i think just doing that like making that commitment and then making sure that i i do that every week um like that number one that forces me to ensure that I understand the story of the project because I see like a project is one big story and it's a story every week, right? So because there are lots of things going on, but you need to be able to articulate that story at the end of the week and say okay this is where the project is at This is the story right So in order to do that you need to be able to look at all your metrics wherever they are and then interpret and then surface what is relevant to your stakeholders So for me, that's how I keep myself accountable. That's kind of a great wrapper on this. Also because the story also implies that we have been able to build that story for ourselves, that we are able to narrate, to make sense of what happened during that week, which is a great kind of self-check, right? Like if I can't make sense of the data that I have, there's something I'm missing, and then I can go and fetch it or search for it if I don't know where to fetch it. So just on that point, Vashko, because I know like sometimes I feel like a status report, like this is so administrative. But I realized that like in order for me to do a status report that makes sense, I need to have a solid understanding. And sometimes before you actually get to the start, like there are other things that you need to do. Like, you know, it keeps you accountable and it also challenges you to, you know, to sort of make sense. and to, there's a lot of lead work that you need to do sometimes so you can actually get that report. So it's not, because you can do a status report where it's like, okay, I just send something that's more clerical, but you need to be able to articulate the narrative that's going on. And yeah, so I just wanted to add that point. Like it's not just sending out a status report, it's understanding what goes into it. I really like that because status report can feel, like you just said, very bureaucratic. But if we put it together with our understanding and how we bring it together to that status report, then it forces us to be accountable to ourselves through the accountability to others as well. So great point. Thank you for sharing that, Muhtar. I know for sure. All right. I hope you like this episode. But before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing Agile every day. We're talking access to over 700 hours of Agile gold. CTO level strategy talks, summit keynotes, live workshops, e-courses, deep dive interviews, books. And if you're into no estimates, we got the pioneers of no estimates in those deep dive interviews as well. Agile business intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community, which is free of all of that AI slop you see everywhere. and of course, without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org forward slash membership and join the community that's shaping the future of Agile. We have so much for you. So check out all the details at scrummastertoolbox.org forward slash membership because listening is great. It's important, but doing it together, that's next level. I'll see you in the community slack. We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or iTunes? share this podcast and let other scrum masters know about this valuable resource for their work remember that sharing is caring
