scrum master

Okay, so cognitive friction might be kind of the overall, let's say, constraint or perhaps even early alert signal for us to consider.

But as scrum masters and agile coaches out there, there's something very concrete that we need to be looking at, which we look at normally every day.

That is collaboration.

And one of the things that can happen is that if we have no speed limits, then the use of AI can actually start damaging collaboration.

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

Yeah.

And that collaboration is very important, right? And often we as scrum masters are trying to get that collaboration going because, of course, not all product managers or product owners are technically minded.

Sometimes it's even worse if they are, but that they are not technically minded is not an obstacle if there's a good collaboration with the team in the technical decisions, right? If the product owner is open to what the team can bring from the technical perspective and the team is open to understanding the business outcomes, the actual impact that the product owner is trying to aim for.

Yeah, and touching on that specific point of this gap on knowledge is I don't think it's that bad as well, not only because of the collaboration, but because he doesn't say how.

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.

Okay, now we turn our attention to success, Deborah.

So share with us, how do you define success for yourself as a scrum master?

Uh, I...

There's only one thing that comes in mind.

So go, go back and check it.

And also, uh, a link to a heuristic that was defined in the '20s to try to manage agricultural production, and then later on used in the war effort during the Second World War to improve the output of manufacturing.

That's statistical process control, something that Deming talks a lot about, and is kind of a lens into the productivity of a system without you needing to understand all of the inner connections, relations, and dynamic behavior of the internal system, but by observing it from the outside, which is what we need to do as Scrum masters because the systems we work with are infinitely complex and dynamic.

Analysis will not help us understand.

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.

[outro music]

But those stories, we need to understand where they are, uh, what they are, and also how they got started, right? Like, so tell us that story, Deborah, and, and, and start from that early set of signals or behaviors that eventually led to the problems, but, but how did it develop over time? Tell us that story.

Yeah, that is a hard one, uh, because as a Scrum Masters we do our best to avoid that type of situation.

But I had one case where the direct leader from that team was so toxic that the turnover was high.

Uh, it was a team composed about 12 developers and QAs, and the ongoing toxicity of the direct leader, and mind you, and at that situation, that leader was above me as well, so I had limited things that I could do.

The solution, it wasn't as good.

Uh, the team morale was on the floor, and it reached a point where the project was canceled.

So th- this is an interesting case because first it illustrates how certain things are a property of the system we're working within, and there's very little we can do as Scrum Masters.

And it, uh, it also, because of the way you explained it, it also illustrates how important it is to understand how the different people in the system behave and what examples are being given.

Hello, everybody.

Welcome to one more week of the Scrum Master Toolbox podcast and this week to explore so many Scrum Master stories.

Deborah Colombari is joining us.

Hi, Deborah.

So we're going to go straight into it, Debra.

Welcome to the show.

And tell us a bit more about yourself and how did you end up becoming a Scrum Master?

Okay, first of all, I live in Brazil, São Paulo City, and I ended up being a Scrum Master.

Because, uh, one of the problems that I see is that even the product owners that maybe want to become a product owner like Scrum describes, right? Like owning it end to end, understanding the customer, the business, transforming ideas into business outcomes rather than just more stories.

Even those fail because they have not yet realized that the collaboration between product owner and Scrum Master is critical, so that's one of the typical usual failures.

And then the other is that it- it's not enough to understand the business from your perspective.

You need to understand the business from the stakeholder's perspective.

And do you know what he said to me? And this is something that I believe to this day.

"Your goal as a product owner is to get as many people to pat you on the back for a job well done as possible.

That is your goal." And that has been, for me, what I've taken into, um, you know, my way of working over the last, you know, 18, 19 years as a Scrum master, as a product owner, as an agile coach.

I want people to pa- I have an ego like you would not believe.

The product owner didn't bother to help me.

I spoke to my scrum master.

My scrum master said he was gonna do something.

Didn't bother to do it.

As a consequence, I wasn't able to finish my story.

A look back on how these last two weeks went.

And or three weeks or four weeks, you know, depending on your screen duration.

However, I've noticed a lot of Scrum Masters do it in that different way.