← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
The Sprint Planning That Wouldn't End - A Timeboxing Failure | Alex Sloley
00:16:16
Alex Sloley: The Sprint Planning That Wouldn't End - A Timeboxing Failure Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: . "Although I knew...
Loading summary
Transcript19 lines
- [00:04]
Vasco
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, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this 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 membership. That's scrummastertoolbox.org 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.
- [01:12]
Host
Hello everybody. Welcome to one more week of the Scrum Master Toolbox Podcast. And joining us from Sydney, Australia is Alex slowly. Hey Alex, welcome back. Or actually I should say welcome to the show. Not back yet, but you know, who knows? The future is open. Maybe.
- [01:31]
Alex
Yeah, maybe I'll come back someday.
- [01:33]
Host
Who knows? Okay, so Alex believes that a great Scrum Master can have a long and lasting impact on people and teams. He's also a global agile and product management evangelist, author of the book the Agile Community. Check out the link in the show notes. Also, frequent international speaker and a former Microsoft Leader with 15 plus years experience who now trains, coaches and drives transformations worldwide. He's certified with Scrum IC Agile Kanban, and he energizes communities, guides leaders, and as he was saying just before we start recording, yeah, he enjoys a good beer at the pub and that's what we'll try to make this conversation feel like. Alex, to get us started, tell us a little bit more about yourself and how did you end up becoming a Scrum Master.
- [02:24]
Alex
Yeah, this is a classic thing that Agile people talk about after the conference has ended for the day and they're in the hallways or at the coffee shop or the pub. And the way I like to think about it is every Scrum Master has their superhero origin story, like Batman and Superman have their origin story. Every Scrum Master, whether they know it or not at the time, is going through an origin story. And it's only later that they figure out, oh, that was my Scrum Master origin story. So I actually know exactly what my origin story is. And I talk about it all the time with other people who tell me their Scrum Master origin stories. So it's, it's 2007 and I'm at Microsoft and I've been at Microsoft for a pretty long time at that point. And I delivered into many Microsoft products and I was like an expert at waterfall because that's what we did really good at Microsoft at the time was waterfall. I mean, I was really good at it. And for some reason, I don't know if I ever got the answer, but for some reason my organization and Microsoft decided they were going to try Scrum. So they hired a person with some Scrum experience and she came into the organization and she was the first Scrum Master I'd ever met. In fact, I didn't know what the Scrum Master title was. I'd never heard it before. I didn't know what Scrum was. And my team was chosen as the first Scrum team in the organization, like the pilot team, right? So she comes in and she does a one day training for our little team. We're like six people, you know, it's a small little software development team. And after our one day Scrum training from the Scrum Master, I was like, wow, this is insane. This is never going to work. This is like the craziest thing I've ever heard.
- [04:23]
Host
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.
- [04:32]
Alex
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.
- [05:51]
Host
And it showed. So what happened when you took the role, Alex?
- [05:56]
Alex
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.
- [07:03]
Host
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.
- [08:04]
Alex
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.
- [10:50]
Host
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.
- [11:58]
Alex
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.
- [13:34]
Host
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.
- [13:51]
Alex
Just make it transparent.
- [13:52]
Host
Exactly. Alex, thank you for sharing that story with us.
- [13:56]
Alex
My pleasure.
- [13:59]
Vasco
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.
- [15:51]
Host
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.