Vasco Duarte (4:39)

Very good, very good. This sounds familiar. The whole story of code is interesting. Technology challenges are interesting, but then you get to work in a team or a group of teams, and then you figure out that actually the technology part is the easy one.

Antti Horeli (4:56)

Yep. At least that you can solve. Like you can like to say now, this is done very rarely in the teamwork in the process area. You can say that, okay, this is now done.

Vasco Duarte (5:09)

Yeah, absolutely. That's a good point, actually, because when it comes to people, nothing is done. We're in constant flux. And when you put loads of people together, collaborating and being affected by decisions, moods, illnesses, whatever you have in mind, that becomes a lot more complex. Now, of course, that complexity and the human side is filled with amazing things, right when people reach their potential, when they achieve great things together. But as Scrum Masters and Agile coaches, we sometimes need to go through some difficult stories before we can achieve those great things. And today's Fail Monday here on the podcast Anthy. So let's explore one of those stories, tell us a little bit about the context, and then walk us through the story. Like we'll take the takeaways later. We'll discuss what we can learn from it later. But tell us that story, Anthony.

Antti Horeli (6:02)

All right. Well actually I've got kind of two short ones and one is kind of small scope one and other is bigger. At the early parts of my Scrum Master career, I very clearly remember one Sprint planning that was kind of my go to horrible Sprint planning ever later on. And we my team, we kind of thought we had Scrum going, we were doing decent there. But for some reason we came into Sprint planning like totally unprepared. I guess that happens. Something more important took our time in the previous weeks and then we didn't really realize that we just started planning and then the whole planning thing took about two days and every.

Vasco Duarte (6:47)

Wow, tell us a little bit more.

Pasco Duarte (6:48)

So you frustrated, you get into the room, right?

Vasco Duarte (6:51)

And you're thinking maybe it's going to take one hour or two hours, right.

Pasco Duarte (6:54)

And then things start.

Antti Horeli (6:56)

We kind of looked at, okay, we're not really clear. So maybe it'll be like half a day or something, three hours. That might be usual tricky planning for us but, but then we, we slowly start to understand we don't really know the stuff we have on our backlog. We look into them, they started kind of sort of exploding like okay, actually this is way bigger. We have to look into this before we can commit to anything. Before, before we can even say can we do this or not and all that. And for some reason we didn't realize this, we just kind of slugged all this refinement stuff into the planning itself. Maybe we should have just, you know, stepped back and split or something and do refinement. Just focus on that or something and okay, okay, that was half of the problem. The big, big kind of bummer game actually after the two days because for some reason and this, I think this wasn't typical for us but for some reason there was something business wise happening in the background that kind of missed our whole backlog up. The thing we had just very painfully tried to get a grip of and it messed it up like the very next day. So we had a painful two day planning and then on third day we just started kind of the sprint. The PO came back and said actually this is all the wrong stuff.

Vasco Duarte (8:11)

Wow, that must have been very frustrating for the team.

Antti Horeli (8:14)

Yeah, I think the whole team kind of says oh really? Okay, we're going to go to the bar right now. We'll be back in an hour.

Vasco Duarte (8:21)

We'll not be back in an hour.

Antti Horeli (8:23)

Oh well, let's see. We were fairly, how do you say, responsible, but still that was, that was like, oh my God. No, no. That's like maybe the single most frustrating moment in a lot of, you know, my co care. I remember the emotion still.

Vasco Duarte (8:41)

Yeah, that stays with us. Right.

Pasco Duarte (8:44)

Like you put a lot of effort.

Vasco Duarte (8:46)

Into understanding stuff that, okay, we weren't ready, but we need to work through them. And you put a lot of effort into trying to understand those back and forth, making technical decisions, maybe even being committed, emotionally committed to some kind of architectural pathway. And then sudden everything changes. Wow.

Antti Horeli (9:06)

Yeah. And it kind of, the emotion kind of piled up there. So it's kind of bad luck, I guess, in that sense as well. But still.

Vasco Duarte (9:13)

So when you look at this story, like what would you do differently today?

Antti Horeli (9:19)

Well, one thing I have really taken taken to heart is that refinement work really pays off. So the first kind of bigger problem or the smaller problem, we try not to get into that. Or then if we do realize that in the sprint planning, we're all over the place, we don't really know the items here. Then maybe like say we're not doing planning today, we will do refinement work today and kind of focus on that and figure out how to do that best. Maybe split into smaller groups or something, depending on how big of a team you have, and then do the planning the next day or something like that. But I guess the bigger problem was that we just did not for some reason have visibility into the backlog or like the backlog we did, but kind of what was happening like on the higher level. And usually our product owner knew this stuff and kind of brought it into the, to us. But for some reason that didn't happen at that time. So making really sure that these kind of higher level things that happen and that might kind of affect what we do eventually absolutely will affect what the team does. We know about them at least a little bit. So it doesn't seem so emotionally stressful when they kind of mess things up. I mean, change happens and that's something to understand and that's okay. But it's always worse when you kind of get blindsided by something you maybe didn't have to get blindsided by. You could have known.

Vasco Duarte (10:42)

So that's where the famous trade off comes in.

Antti Horeli (10:47)

Right.

Vasco Duarte (10:47)

Like you can share a lot with the team so that they are aware of what's going on and what might be coming their way. But then there's also the, the point where is this too much? So when you look at that trade off, which is, I mean, it's a fair question, like how much can we share? Because not all things that are going on will turn out to be decisions or they won't turn out to be reality because they are just hypothesis ideas that are being discussed. When you look at that question, how do you define it for yourself? Where do you draw the line between what's sharing just enough or oversharing with the team?

Antti Horeli (11:24)

Wow, that's a really good question. So kind of balancing communication so you don't overwhelm anyone, but still, you know, enough. That's a really tricky thing. And I think it goes wider. Like between development teams, for example, how much do they need to talk to each other so that they know what they're doing? So they don't like to take decisions that hamper each other, but they can't know all the details because then they'll just be, you know, communicating all the time and not, not getting anything else done. I don't have kind of a rule for that. I think it's maybe, maybe more of a instinct or something like that. And, well, maybe it's kind of the litmus test is that if, if we seem to have retrospectives or other situations where this thing comes up as a problem often, then we have to do something about, we have to share more. But if it's, if it's on the other side that people feel that they're getting overburdened with information, they would just, you know, want to focus on developing the work. Then we have tried to tone it down a little bit and it goes kind of up and down. It depends on the situation, the kind of volatility of the organization, stuff like that.

Vasco Duarte (12:36)

So I really like that, using the retro as kind of a thermometer, checking if it's too much or too little. Another thought that I had is that the owner would come into the team, like for example, a Sprint review or even a retrospective. If the PO is participating and say, hey, there's these things going on, not sharing any details. Do you want to know about it? Right. And this is also an aspect of self management for the team because some teams will want to know more about something than others and that's okay, right? Like, as long as it's information that is not somehow confidential, then it's perfectly okay to share. So I think that for us as agile coaches and Scrum masters, it's also about being able to always check in with the team. Hey, there's some stuff going on regarding possibly new integration that is coming. Do you want to know more about it? It might not happen but we're talking about it. Do you want to know more about it? Right, like leaving that option for the team to make a decision on their own. What do you think about that?

Antti Horeli (13:43)

Yeah, that's a very good point I think and it also has the benefit of the team can kind of realize maybe even from the kind of short two sentence description that okay, this might have technological impact that you actually might not know about. Let's talk about this a bit more and kind of gets them engaged in that way as well.

Vasco Duarte (14:02)

Absolutely.

Antti Horeli (14:03)

I like that idea a lot.

Vasco Duarte (14:05)

Great point, great point. Thank you for sharing that story Anthy.

Antti Horeli (14:10)

Alright, thank you.

Pasco Duarte (14:14)

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.

Vasco Duarte (14:27)

Remember that sharing is caring.