Hey Reader,

I've got an interesting comment on the video "Everyone must go to the Sprint Retrospetive".

It said: "Saying so, you force the member. It's not agile"

I replied: ""forcing" is an interesting word to use when it comes to expecting someone to do the job they are paid for."

Even more interestingly, I got another reply that said: "to go to meetings because someone has to is not an argument".

..which to be honest, got me a bit confused.

We have to go to work, right? That's what we are getting paid for. So that's natural for the employer to expect us to show up.

For me, going to the work meetings is another requirement. Ok, some meetings may be not as useful as we'd like to, but that's a whole another point.

The important thing is, there are some rules and expectations set in place when it comes to paid work.

I think the challenge comes in when we start changing the ways we work. When we implement Agile.

When it comes to Agile we set new expectations on the people working in this environment, and this often clashes with what we used to do previously.

That's why in the requirements for a job we often see things like: team player, can work independently, proactive, etc.

We no longer want just someone doing the job. We want someone who can do more than just the job itself, because we've finally recognized the value of individual contributors.

So.... that leads me to the question I asked in the subject line: "when should you put your foot down?"

Of course, I'm more specifically asking from the point of view of a Scrum Master.

And I often find myself during mentorship calls explaining that concept of new expectations put on team members.

Many struggle with, what it seems to me, silly and capricious team members: who don't want to come to meetings, who don't want to participate in retrospectives, who don't want to learn new things....

And for me that's the point where you often need to put your foot down and set the expectations straight.

Each person in a Scrum team (or any other team, but Scrum team specifically in this example) has a certain role to play. The role, while it allows every person to choose how to accomplish their purpose, also holds each one accountable for the results.

This is exactly what I talked about with Giulio in the latest episode of the Agile Audit podcast.

We covered so many topics in this discussion.

But there were a few related directly to the topic of this email. We started with the role of the Product Owner and how to work with them to build strong relationships and lead the team to success.

We specifically discussed expectations for the role, and making sure that those expectations are clear.

Especially when you are working with a team that worked in waterfall for over 15 years and just switched to Agile 3 months ago (which is exactly the case for Giulio).

Watch the full episode to learn more about this and some other very interesting topics we covered:

I also wanted to share another comment with you, this time a comment I agree with. It was on my last week's video where I talked about dependencies.

Here's a screenshot:

@ToriMarinucci made a really great point here.

Why I bring it up because I think it comes back to our point on setting expectations.

So I often talk about self-management / self-organization when it comes to the Scrum team, and how a Scrum Master should let the team figure out the problems and address them themselves if they can.

Of course, if the team is new, still figuring out this new Agile thing, then you'd need to have a bit more hand-holding.

As I discussed with Giulio. At first, the expectations about the roles are not exactly clear.

More specifically, it may be unclear to the team members how exactly this new way of working changes how they work day-to-day.

It will take some time to get adjusted to it. And at first as a Scrum Master, you can't really put your foot down, as I said, because that would be unfair to the team.

So instead you would be guiding them to that new understanding of their role in an Agile environment.

If you want to learn more about dependencies and how to manage them when working with a Scrum team, then you should watch my last week's video:

Oh, and the last thing I wanted to share with you is....

Would you like to be a guest on the Agile Audit podcast 🎙?

If you are interested in coming over to share your experience OR to get some coaching from me, then fill in this form.

I can't promise I'll be able to have everyone submitting the form join me on the podcast, but I'll do my best to review every single submission.

​

Remember to put your foot down if the situation calls for it!