← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
How a Miro Board Experiment Changed the Way His Team Understood the Big Picture | Njegos Ilic
00:11:23
Loading summary
Transcript15 lines
- [00:04]
A
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 warfree 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 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 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. Hello everybody. Welcome to this very special week where we focus on the product owner role with Niegos Ilic. Hey Niegos, welcome back.
- [01:22]
B
Hey Roscoe, thanks for having me.
- [01:24]
A
Absolutely. So usually with Scrum Masters we would do the coaching question, the challenge question, but because we are doing the product owner question or the product owner week rather with you this week we're going to focus on the change question. And here the focus is from your perspective as a product owner, what was one thing that you worked through with the team and how did you do it so that you could successfully help bring about change either in the organization itself or just in the team? For example, helping a team adopt story mapping. So tell us your story of change, Niegos. We'll dive into the details and the takeaways later. But first tell us that story, Nikos.
- [02:09]
B
So I'll actually share one really interesting story with one team and one company that I work with. And I think it was really changing for me and I think for the team and it was basically about trying to visualize things and to change approach how we were doing our assignment and at the end of the day planning.
- [02:32]
A
So
- [02:35]
B
what we did actually, and I did that with the help of really good, like the official role in that company. He was a tech lead, he was really good, really, really good. And he was also working as a Scrum Master before and as a PO as well. And he actually helped to facilitate that. But what we did back then was basically, you know, once we break down these, I don't know, epic to couple of or multiple user stories, then trying to break that down into the tasks. You know, we, I think we back then use a sana. I think what we did actually in the mirror board on these refinements, we would basically try to map it out on the board, you know, and try basically to connect the big picture with all of these concepts, different concept concepts that we try to build and basically copy paste the, you know, the ticket numbers into the mural board and basically on each daily or I don't know, I forgot which other meetings we had. But mainly refinements, we would basically do kind of, you know, check ins and trying to see where we are at on that board instead of using, you know, regular boards with just, you know, some small cards and everything. I think that helps a lot because it really provide the team a way to see, hey, how these different pieces that we are building, you know, fit in the big picture.
- [04:02]
A
And how did you introduce that change to the team? I mean, did you just have like a workshop at the beginning? Did you share some YouTube videos and then have one on one conversations? How did you go about helping the team first understand why you were introducing that and then actually getting it implemented?
- [04:20]
B
So as I, as I mentioned in the beginning, this one, this, this one was a little bit easier actually to implement because I had a really good support from this guy. But at the end of the day we just show them, hey, we will do it and we will show you what the impact of this is, what are the results? And basically that's what we did. We just said, hey, just give us a chance to try this and then just tell us do you like it or not? That was it.
- [04:48]
A
And you picked like a specific upcoming feature or set of features that you would work through.
- [04:53]
B
We did experiment of course, so we picked a feature and we said for this Sprint, we'll do it like this, we will change the approach. And I can tell you like the dailies, like the communications, everything was much more, you know, transparent. It was much more, you know, engaging from the team. And to be honest, it was much easier for me to track the progress because you know, I'm really visual guy and probably most of the people, not everyone, but it's much easier for them to connect, you know, connect the dots. If they see some big picture and how it changes, then you just have some list and then you, you know, you have some statuses. So that, that was something that was really easy. But still whenever I'm speaking with someone, I'm always bringing that example because it was really, you know, something that, that was really impactful. Back Then, you know, and I'm trying to mimic this whenever I can, actually. It's just, you know, you cannot implement everything with, you know, every people. So. So that's why, you know, so let's
- [06:02]
A
say that Luke, our F Scrum master, just heard this episode and he's thinking, oh, it would be really great if we could do the same. And he gets together with Leah, the product owner, and Luke and Leia are trying to help the team understand and adopt this practice. How would you advise they go about this? Like, let's help them out. Like, where would they start? Like, selecting a feature or how would you help them go through this adoption process?
- [06:36]
B
To be honest, I think it's fairly simple. I think the pitch itself should be just, hey, let's try this out, and let's just try to see how we can learn from this experiment. And basically, if it doesn't work, just drop it. Maybe there is something else that works better for you, but at the end of the day, the whole idea about that's how I see it, all of these practices is, you know, how you can get the result as fast as possible. So if this doesn't work for some team, you know, you just drop it. But at the end of the day, getting back to this, you know, parable from the previous conversation that we had, like, at the end of the day, you have to fall. You have to experiment, you know, in order to learn how to run or walk. So that's basically it. I really don't have anything, you know, profound. It's just, hey, because I think this is the mentality that should be adopted from everyone. You should be motivated to experiment with a lot of different approaches in order to improve your way of working. And as simple as that. I really don't have anything more.
- [07:47]
A
I really like that experimentation mindset because it's also what we need to bring to the product. If we are not willing to experiment with our process, which is the thing we control, of course we're not going to be able to bring ourselves to experiment with a product which is a much higher risk, much higher exposure to failure. So I really like that approach. Hey, you know, we'll try it. And it's worked for some teams and maybe it works for us, we hope, but if it doesn't, that's okay too. Like, we just drop it and move on. And I hope, and I wish we would do that a lot more often with our product features as well.
- [08:26]
B
Yeah, exactly. Like, you have this concept, you know, with the product, you know, every feature you know you shouldn't communicate it as a feature. It's a product bet. I would call this process bet. Just call it like that and just try to see what works the best for you.
- [08:42]
A
Yeah, I really like that idea of a bet because a bet you already know there's a chance you win and then you might actually make some money back or there's a chance you lose. And that also tells you that you shouldn't make very big bets very often because you're going to go bankrupt very quickly. That was great. Thank you for sharing that. Niegos. 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 accessibility 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 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 is caring.