← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
How To Be A Data-Driven Scrum Master Or Agile Coach | Season Hughes
00:15:09
Season Hughes: How To Be A Data-Driven Scrum Master Or Agile Coach 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: . Season approaches Scrum...
Loading summary
Transcript21 lines
- [00:02]
Pasco Duarte
Hi there, Pasco Duarte here, your host. I wanted to share a story with you. You know how sometimes Agile just feels like following another checklist when like processes and frameworks feel more important than what we are trying to achieve and sometimes even like handcuffs. I was talking to a customer of the Global Agile Summit and he used a term that kind of stuck in my he said, I have Agile fatigue. And I've heard that a lot from people since then. But here's the thing, it doesn't have to be this way. So we started thinking and at the Global Agile Summit, which is happening this May, we're bringing together practitioners who've actually done that, who've broken free from this, you know, install the framework kind of mindset. We want to focus the summit on real life, first person stories of Agile all succeeding that inspire you to action. We're talking real experiences, practical solutions, and of course, amazing insights from leaders like Gojkoacic, who will be one of the keynote speakers, and Jurgen Apelo, who will be one of the keynote speakers as well. If you're ready to leave the Agile fatigue behind, just join us in Dalit. The Early Birth tickets are now available@the globalagilesummit.com and mark your calendar. We will have workshops on May 18th, that's a Sunday. And then the conference itself will happen on May 19th and 20th of 2025 in Tallinn, Estonia. So let's make Agile exciting again. And remember, go to agile globalagilesummit.com that is, and get your early birth ticket. Now. It will only be available until early March, so grab it now. And now onto the episode.
- [02:06]
Season Hughes
Hello everybody. Welcome to our Success Thursday. This week we have with us Season Hughes. Hey Susan, welcome back.
- [02:14]
Susan
Thank you.
- [02:16]
Season Hughes
So Success Thursday is of course all about success, as the name goes. But before we dive into what success means for us as Scrum Masters season, share with us what's your favorite retrospective format and why?
- [02:29]
Susan
Yes, and retrospectives are my favorite event of Scrum, which you will hear from Scrum Masters a lot. And I just love it because it's our time to really dive into improvements and to be able to facilitate conversations. And that's what Scrum Masters do best. So here is the retrospective format that I could do in my sleep at this point. I also want to point out like I still get nervous facilitating events, even if it's a retrospective from a team that I know very well. Like I was just talking to someone who is newer to facilitation and she was talking about how she's nervous and she has all these notes and she prepares. I just said, you know, I've been doing this for almost seven years, and Me too. So I just. I want to throw that out there, that it's always okay to be a little bit nervous about facilitation. I want these to be good experiences for my team. So that's a little bit where my nerves come from. But here is something that I have practiced and I feel very comfortable in. I start out the retrospective with icebreaker, which I've heard recently referred to as a warmup, and I'm starting to like that term a little bit more, too. So something to get the team talking and to be a little bit vulnerable and to let them see each other as people. So it could be, if it's a newer team that I'm working with, something like, where is your favorite place that you've ever been on vacation? And if we're using a tool for the retrospective, like lucidspark or Miro or Mural, I may say put a map on the tool and have them mark that spot to get them used to using, using the tool. But it's important to me that every person who is participating has a way to speak up at the beginning to really break the ice or warm them up. So that will get them more comfortable talking throughout the retro or chatting or just participating. So that's what that is designed for. Then something very important that I see often missed in retros, and I'm guilty of this, too, if I'm kind of in a hurry, is we really need to check in on our last retrospective. What did we commit to doing? Action items, experiments, improvements, changes, whatever your team calls them. What I like to do, and again, I usually use a board for this, is I will have those experiments up on the board, one or two of them. I try not to do more. And we will. I'll have them drag a thumbs up or a thumbs down or hearts, whatever it takes. How did we do with our last sprints experiments? Do we need to discuss them? Do we need to tweak them? Should we keep trying them? Is it something that we want to abandon entirely and never do again? Let's learn from what we committed to last time. And then my favorite format for retrospectives is lean coffee. It's something where I will have the participants be the ones to decide what it is that we will talk about. I'll lay out sticky notes on the board, and they will fill them with anything that happened in the last sprint that they feel would be valuable to discuss as a team that might help them improve their work or the next sprint. So they get to vote on what we talk about. Whatever has the most votes, we talk about first. We start with five minutes per topic. They get to vote if they want to extend that time on the same topic or if they want to move on. I just love it because it is driven by the people there and they are the ones who are deciding what we talk about. So it's not going to the loudest voice or it's not going to the facilitator to be the one to come up with what to discuss. It's really the team. And as a Scrum Master, I do also participate in the retro, which makes it a little bit tricky, but I do try to say, hey, I'm going to be a participant and put a topic in myself, too. Now I'm switching back to the facilitator role. Like, man, being a Scrum Master is hard.
- [06:47]
Season Hughes
It is hard because it requires us to be always fully aware of the role that we are taking, since we have a clear goal to help the team, but we actually can't get them there right. Like, we have to figure out how to get them to first figure out what the goal is and then themselves figure out how to get there Right. Which is quite different than most of the leadership roles that many of us, including people who are just getting into the profession, have seen. I mean, if we think about school as an example, which someone just coming into the profession will have been at, we are constantly taught that somebody is there as an authority and knows better than we do.
- [07:29]
Susan
Yes.
- [07:30]
Season Hughes
But guess what? There are not that many Scrum Master experts out there. So that's why I started this podcast, because I knew there were a lot of people experimenting and there are, and we needed to share that experience. Right. It really is important for us to do that sharing, because there isn't a university degree on being a great Scrum Master yet.
- [07:54]
Susan
Exactly. And it's different for every person what a great Scrum Master looks like. And that's why I loved listening to this podcast, was hearing all of these different ideas and thoughts and just taking a little bit from each person and just also knowing, like, hey, I'm not alone when I encounter these challenges or when I say being a scrumester is hard because you have to participate and facilitate. Like, if you're feeling that way, we are too. There are other people out there. So thank you for the service.
- [08:23]
Season Hughes
Absolutely. It's a pleasure. And which gets us to the next question, which is what does Being a successful Scrum Master mean for you season?
- [08:31]
Susan
Yes. Well, I, I can't see you if you're listening, but raise your hand if you're tired of me talking about the Scrum Guide. I'm tempted to apologize for it, but I'm. I'm kind of not. I go back to the Scrum Guide to see if I am a successful Scrum Master. This again is where I start with things I'm not, as always saying to do it exactly by the Scrum Guide. And I'm not saying that Scrum is a flawless way of working, but this is understanding where it comes from and what the expectations and accountabilities are. As a Scrum Master, I check the Scrum by is it coaching teams on self management? Are we creating value? Are we meeting the definition of done? Are we having positive and productive events? And I really like data and measurements, so how do I measure these things? This is really tricky for a Scrum Master because a lot of the time what we're doing can't be measured be measured, but I think that there are ways to approximate it. So something I like to do to test self management is when I'm starting out with a team, I may facilitate daily Scrum just to demonstrate, give a template for what it looks like and then I may start missing daily Scrum like on purpose. Like maybe I'm free during that time but I choose to not go. And I may ask someone like, hey, how did daily Scrum go? Are they saying, oh, we kind of fell apart, like, okay, opportunity to help them self manage or oh, it was fine. And we discussed the sprint goal and we knew what to do. Great. Sometimes to test the are our events positive and productive? Most of my teams that I've worked with work in Zoom. We'll have a Zoom meeting at the end. I'll do a poll that just says on a scale of 1 to 10, was this a productive use of your time? And I'll measure those scores and how they change over time. And then I also like to have one on ones with team members to say, you know, what's working for the team, what's not, how could I better support you? And they do something similar of if you had to talk to a friend who wanted to join the team. And a score of one is you're telling them to run far away from the team. And a score of 10 is this is the best team you've ever been on. What is your score and why? And I love diving into that data and picking up on themes and comparing data across past quarters, just seeing where the scores are. That is how I measure my effectiveness as a Scrum Master because I'm directly contributing to these things. What I would not measure my effectiveness on is teams velocity and is it increasing or the number of JIRA tickets that a team is doing? Or how many lines of code is each individual developer committing? Like these don't reflect the value of Scrum or the product or customer value. And plus they can be like super easily gamed. Like you can write a line of code with like a letter on it and commit it. Like these are not metrics I would.
- [11:52]
Season Hughes
Use or just a tab or closing curly brackets or.
- [11:57]
Susan
Exactly.
- [11:58]
Pasco Duarte
It is sad that in this day.
- [12:00]
Season Hughes
And age there are still recognized organizations out there talking about developer productivity in terms of lines of code. And in fact, these days with ChatGPT, one has to ask, why would they ever think that's a good idea? Because I can take a one liner and make it a 100 liner with the help of ChatGPT. It makes no sense.
- [12:22]
Susan
Exactly. It feels like an easy and comfortable way to equate to productivity. And it avoids that deeper look of what actually are we trying to achieve as an organization and what do we value and how are we doing towards that? Because you might not like that answer.
- [12:44]
Season Hughes
There's this quote, I don't remember who said it, but it's something like this. Leaders not knowing how to measure what they want end up wanting what they measure. And this is the lines of code is a great example because we don't know what developer productivity is. It's a fraught topic. We don't actually know the definition of developer productivity, even though there's a lot of speculation about 10x developers and whatever. But we don't know. So we end up measuring what we have, which is lines of code, and then calling it productivity. But that makes a mockery of great professionals. I had a colleague who was able to reduce the source code lines of code count by 1/3 while adding features to the code base. Yes, I would say that's a lot more productive.
- [13:40]
Susan
I was just thinking about that the other day. Like, what if someone writes one line of code that changes the lives of millions of people versus someone who writes a million lines of code and doesn't provide any value. Yeah, what? Being very clear on what value is and how you measure it. And again, it is. It's tricky in any role, especially I think, a Scrum Master, because a lot of it has to do with autonomy, purpose. Like do people know why they're here and sometimes that can be intangible, but I think there are some measures to measure that.
- [14:17]
Season Hughes
Absolutely. But that was success everybody. I hope you took notes and wrote your own self assessment questionnaire. I think it will be great this Friday when you sit down and reflect on the week season. Thank you very much for sharing that with us. Yes.
- [14:34]
Susan
Yay. To success.
- [14:39]
Pasco Duarte
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.