B (4:03)

So what do you use? So of course the line going up and down is a great conversation starter, but what do you use to investigate the moments of happiness and the moments of stress? Because both of them contain information, right? Like somewhere in the middle there's very little information, but if it's very much at the bottom or very much at the top, there's a lot of information there. How do you investigate those moments with the team?

C (4:30)

So I would get them to write a post it on it. Great. So let's look at this moment of great happiness or great sadness. Get everybody to put a post it and when you have gather information that way, common theme emerges so we can actually group them and get the team to discuss them. And of course, if everything, whenever the thing goes well, that's something we should continuously do it out of the not so very great moment, like the themes. Then the question becomes, so what do we need to change over here so that we could lift your mood from the bottom part of the chart into the positive? The top part of the chart, it doesn't have to be, you know, high, high, even if it is across, you know, that middle line into the positive zone can be that little, little small happiness or it can be great happiness. So get a data from here, there. So that becomes that, you know, the continuous improvement plan.

B (5:48)

Absolutely, that's a great point. All right, now we do run this retrospectives because we want to help teams succeed. And of course that is because that means our success as SCRUM Masters.

A (6:01)

Right?

B (6:01)

Like when teams succeed, we are succeeding. But when you look at yourself and how you're performing and how you're working with teams, how do you define success for yourself as a SCRUM master? Carmela.

C (6:16)

If you asked me a few years ago, I would have given you like cycle time and those kind of metrics. But after having to work in this environment, I would actually say the advocacy of Agile and scrum. And so this team I was working in, so initially I just became, I was the business analyst of the team and eventually because they trusted me that much, they asked me to help Them as a Scrum master as well. So I was holding two roles and that team was very tired of Agile already. They had a Scrum master who was absolutely micromanaging type of project manager style. And they constantly plan and things still goes wrong and everyone was overworked. The delivery was bug and bug and bug. And so they just hated hl. They just absolutely hated. And they, they used to breakdown story. Not just story, they broke it down in it is almost a task like project management type of Agile. You had a story for death, you had a story for testing and they don't connect with each other. And at the end of the day you ask them, so what do you deliver? So this is in production, is it working as design or is it a bug? Like nobody knew. So everybody just had this Agile fatigue. They hated it. So because I felt like maybe because I was a business analyst, I come across as less of a threat, I came across as friendly. So I came in as like, you know, just tell me about your problem, I'm here to help. And so I actually don't know exactly what I did. So I have implemented a few things, a few things with the team. So I had this planning session, I love my planning session of breaking down a feature. And I've told the product owner saying, you are great, you have business knowledge, but at the same time the team needed your business knowledge more than your technical knowledge. And because I didn't have any industry experience, so I just came in waving the flag of I'm new here, I have no idea about your industry, but I have no idea about data. But I'm a great business analyst, I could help you figure things out and put things together and create traceability for you. So because of that I feel like, and I've given the, the product owner time to vent. So one day he just wanted to talk about how much he hated Agile. Yep, yep. So in a retrospective. So I just let him run. I just let him run. Just go ahead and just say it. And for some reason after that things are starting to take a turn. So after I show him how you can break down your stories, how we could document things, how we could share it with the team, with the developers, with the qa. So to create a greater visibility, so to give them an understanding of end to end, how these things actually work together and how we could put something on just a document end to end, like a report document, end to end report, what do we need to do? And show the team how we could grab one section and build it as A story and grab another section and build it so they could build starting to build section by section in. And the product owner has the ability to tell the team which one is more important in his view.

B (11:06)

Basically, they weren't even aware that they were just learning how to do Agile properly.

C (11:11)

Yes, it feels like that they were following all these Agile framework, but without leaving Agile. Like the true meaning of Agile.

B (11:23)

Was it like before you joined, was it that they had just a very, very large list of requirements and they just trolled through it? I mean, you already said that the stories weren't even connected and there was a test story and a development story and nobody could say something was in production. Like, was it that when you joined, you kind of helped them realize some of the core aspects of what work management feels like in an agile organization or Agile team? In this case.

C (11:53)

Not only just work management, it is to have the common understanding of how this feature actually links, how it is being put together, because it is. So what they were building is actually a massive data product. So they were going field by field without looking at how this entire data product, how they should be connecting to each other. That's when they go field by field. And the top part doesn't talk to the bottom part. So in the end they're building something that's completely disjointed. So a data table, these columns, the data in this column. And doesn't, it's not really. Doesn't have a lot of relationship to the data in the end column.

B (12:50)

The other column. Yeah.

C (12:52)

Yes, because they were just looking at one thing at a time.

B (12:55)

Yeah, basically they were. They were looking at themselves as a team, as task deliverers. Right. Like they were just delivering tasks instead of delivering value. From a end user perspective, I assume.

C (13:10)

Yeah, absolutely.

B (13:11)

That's a great story. Thank you for sharing that, Carmela.

C (13:15)

You're very welcome.

A (13:19)

All right, 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 Estimate 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. And 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.

B (15:09)

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