Host (4:23)

I feel for you because that's exactly where I was when I got started with Scrum. Exactly the same words came out of my mouth so many times.

Alex (4:31)

I've heard that same Scrum origin story where I was super skeptical and I'm like, no way, it's not going to work. And everyone on the team was thinking the same thing, I think, and but you know, we had to give it a try because our managers and leaders wanted it. And we're like, okay, whatever, we'll give it a try. And we didn't have an assigned Scrum Master. It was one of those situations where there were no Scrum Masters in the org. We weren't going to hire Scrum Masters. So what the team said was, okay, we're supposed to have this thing called a Scrum Master. What are we going to do? And we did the classic let's each try a Scrum Master rule thing. That's where the, you know, a new team like rotates the role around. So our team decided that every single person on the team had to serve as the Scrum Master for a minimum of two sprints. And that's what we did. So the first two sprints was one of the developers and she did. Okay. And then the next two sprints. Was one of my good friends a developer? You know, I would say a pretty typical developer, because they reluctantly did the Scrum Master role and they hated it, and they were terrible at it. And after two sprints, they were like, oh.

Host (5:51)

And it showed. So what happened when you took the role, Alex?

Alex (5:55)

Yeah. So then it became my turn, and I was like, wow, this is actually kind of fun. But because we were rotating the role around, it's one of those situations where you're like, 50% developer, 50% scrum master. So, you know, all of us were doing that 50, 50 thing. So I was a 50% dev and 50% scrum master, but I was like, oh, okay, this is kind of fun. I enjoy doing this. And, you know, reluctantly, over time, I'd say a couple of months, I was. I was like, okay, fine. The Scrum thing seems to be working, you know, against all logic. Maybe, maybe I was wrong. And then I gave it a little more time, and over time and over time, I could see it having more benefit for the team and myself. And in me, in my Scrum Master origin story, I was like, wow, I actually like being a Scrum Master more than I like being a developer. And I actually think it brought joy back to my life at Microsoft. I think it's really revitalized me.

Host (7:02)

And then I can totally see that, because developers can sometimes be put in a position where they're just drones. I mean, we used to call developers code monkeys. Of course, it was used as a derogatory term, meaning your work isn't that important. Just type eventually. Exactly. Eventually. At some point, it was only the requirements engineers who really mattered and the project managers, obviously. But Agile turned everything around. Then the developers and the testers became the most important people. They are the team. Then later, the product owner gained notoriety, also a critical role. We'll talk about that on Friday. But the Scrum Master is also a critical role. And we're not perfect, right? Like, we make mistakes. So today's Fail Monday here on the podcast, Alex. So we want to hear one of those stories, a story of failure. So tell us that story. Give us a little bit the context, and then we walk us through the steps, what happened and what you learned back then. But first, tell us the story.

Alex (8:04)

Yeah, so it's the exact same team for my failure story. And it makes sense because that was my first team that I was being a Scrum Master on. So after about six months, I'd been a Scrum. I actually wanted to Keep the scrum master role. So the team let me do that and I kept being the scrum master. And after about six months, we had four week sprints back then because that was like kind of like the standard back then. Like nobody did one week sprints. Everybody did four week sprints. So we were doing four week sprints. And that meant our planning sessions, our planning, sprint plannings were one day. So a full eight hours on the first day of the sprint. You don't see that too much anymore. But anyways, that was also the old days where sprint planning was only two parts. Nowadays it's three parts. But back then it was only two. In sprint planning and you were supposed to do the what? Like, figure out how much work to take into the sprint. That was part one. And then part two was you figured out like how to do that work. And most people did that by like breaking the PDIs down into like technical tasks. So anyways, here I am and I think I'm doing great. We're in sprint planning and it's eight hours long, which is like a, you know, like a hardcore thing. You got to keep it on track in the time box. And we got to our time box after eight hours and we'd only completed part one of sprint planning, which was the what. So what did I do? I said, okay, team, we still gotta do part two sprint planning, so we're gonna continue sprint planning tomorrow. And essentially I forced the team to come in the next day and do the rest of sprint plan for four hours from like nine to one the next day. So yeah, I accomplished the part one, part two thing with the sprint planning. But I totally blew out the time box by like 50%. You know, when I reflect on that, that was a huge mistake. I wanted to control the team. Like, I wanted to do stuff by the book and make a perfect sprint planning. And I blew out the time box because although I knew about the steps of sprint planning, what I didn't really understand was the box of time versus the box of scope, right? You pick one or the other. And in Scrum we preferentially pick the box of time, which is called the time box. So if I had to go back in time, which is a bad pun, that's definitely what I would do. I would focus more on the time box rather than the scope box.

Host (10:50)

One of the things when you say that, the box of time and the box of scope, one of the things that comes to my mind. I was also a waterfall project manager for many years before I became a project Manager. And one of the things that we really learned, got ingrained into our heads as project managers, that you need to keep the scope. The time is whatever it is, the budget is whatever it is. You have no control over time or budget. So you control the only thing that is there, which is the scope. But you try to do it the opposite of what Agile does. Right. Like in Agile we think let's do whatever fits the time. In waterfall, you try to fit the scope and the time altogether, which of course usually blows up 60% average project delays, and so on and so forth. When you look at that contrast, like this tendency that even many Scrum masters still today have, which is to try to keep to the scope, we agreed like what comes to mind and how do you deal with it today? Because of course it's still happening today. It will happen forever. That sometimes the scope just doesn't fit the spread.

Alex (11:57)

Yeah. And so I think that switch of mindset from the box of scope to the box of time is fundamental and one of the first big lessons I learned as a Scrum master. The reason we have a box of time and not a box of scope, or we prefer a box of time or time boxing, is because it helps you keep focused and limits the amount of work you can come into the team. So essentially the sprint itself is a time box and is the method by which a team limits the amount of work in process. In a four week team, which was what I was in, that was a four week team. So we were limiting the work in a four week time box. If I had to think of one big action item that really kind of taught me how to, how to handle that was using visible time timers. So now if you go into my closet here at home, you'll find gigantic time timers. I've got like the big kind of time timers they have in like gymnasiums. I've got a clock above my head, a smart clock that I can like create time timers. And it shows light, lights. I've got a little pomodoro which is a, which is a tomato timer on my desk. So using these visible timers, I've trained myself and my teams visually how to stay within those time boxes. And if I had to think of one action item that's really easy to do that produces that, that understanding of limiting the scope to fit into the time, it would be using a time timer.

Host (13:33)

Absolutely, that's a great tip. And also very physical and visual, which is cool because our mind can't ignore what is making noise. In the corner, but can certainly ignore the time box we had in our mind.

Alex (13:50)

Just make it transparent.

Host (13:52)

Exactly. Alex, thank you for sharing that story with us.

Alex (13:55)

My pleasure.

Vasco (13:59)

Alright, I hope you liked 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 membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great, it's important, but doing it together, that's next level. I'll see you in the community Slack.

Host (15:51)

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 carry.