Can a scrum master reprimand his team?

Scrum master is a facilitator for the delivery team and acts as a bridge between Project Management and the team. In course of time if he realizes that his team is not delivering the deliverables perfectly possible w.r.t competency of his team, can he question his team members why it is not happening?

It is more like a show-cause notice to them. He knows why it is not happening eg:- spending time on social sites or wasting time on less important issues.

Is it okay for him to say “reprimand” the delivery team on their style of working? Or should it be escalated and left for the functional managers to deal with it?

Important thing to note is that usually in an Org, the scrum master is a good friend with his team and so it makes all the more awkward to react to such a situation.

A Scrum master doesn’t reprimand. He or she sees problems and facilitates the team to tackle them.
If the team struggles, it’s his or her job to articulate the problems and try to get the team to do a root cause analysis on those problems.
To elaborate on your example: spending time on social network sites is not a root cause. If the team is spending too much time on those sites (and that’s still an “if”), there’s probably a reason for that. Maybe they need a relief, maybe their work is too boring because they can’t take charge of architecting the solution, maybe…
The first step is talking to the team. Let them figure out what’s going wrong.

They certainly can. Not everything that a team does is perfect or acceptable in any sense of the word.

Scrum masters should enable a culture of open communication, and scrum masters… are part of the team! So, why would they not point out problems with the team?

Some teams are excellent, self-organizing, industrious and effective. Some other teams are mediocre, incapable of organization, lazy or ineffective. Why wouldn’t it be so?

That said, there’s a big difference between having a blame culture and pointing out clear problems with the team so that they can be addressed.

Also, a scrum master is a facilitator, or helper, role, not a leader in any sense. So they have no particular right to literally reprimand people. They can certainly influence the team and point out problems or even calling out people if needs be.

In summary, this is what we want:

Open communication
One team which includes the scrum-master
When problems arise, they are clearly communicated and addressed
When people clearly misbehave, the bad attitude (never the person!) is addressed openly and fairly
People accepting responsibility

This is what we don’t want:

People keeping secrets or cultivating resentment, while pretending to be happy in the team
Scrum master vs. team attitude
Finger pointing
Fear/blame culture
People ducking responsibility

As long as the SM is aiming for the former and avoids the latter, there is no problem is communicating negatively with the rest of the team.

The scrum master advocates for the team to management and the customer. The product owner advocates for the customer to the team. The manager advocates for the company to individual team members.

That’s an oversimplification because good leaders try to balance all concerns, but those are their primary responsibilities. They are split into separate people to make it easier to separate conflicts of interest.

So issues of personal productivity, like excessive web use, should be handled by the manager. However, issues of team productivity which are not a direct result of personal performance can certainly be addressed by the scrum master.

Take your example of wasting time on less important issues. A scrum master can find out why team members feel they need to spend time on those things, and advocate for the team in resolving it. That’s why we have retrospectives. Maybe time really does need to be carved out for those things. Maybe other groups like product management are applying pressure to work on tasks not in the plan, and that pressure needs to be removed. Maybe team members simply aren’t aware of how much time goes into those activities. Maybe priorities aren’t being communicated clearly. Maybe your team commits to too much work in progress, so team members try to finish it all instead of focusing on the highest priorities. These are the kinds of things a scrum master should fix.

Reprimand is very strong word. And it’s not a question of can you do it. Of course you can reprimand anyone you want. But should you do it? I find that when management/leadership takes this type of approach, it generally demoralizes the team and doesn’t really improve anything. So you tell me, I can’t be on P.SE during work hours. How would that translate into me giving you higher output?

As others have mentioned, low output and people browsing the internet is an effect. Your question is how do you fix this symptom but you need to look deeper for the root cause.

And before you look too deep (and the reason why I want to add my 2 cents here) is you (and possibly some of your management) should familiarize yourself with the core ideas behind Agile and motivations to have those ideas in the first place.

In essence, Agile advocates a decentralized form of control, where the management sets general direction but leaves everything else up to the team. Decisions such as how we are going to deliver, how long its going to take, what technology to use, who will work on what. The team should decide that on their own. The reason for that is because people doing the work, really have the most knowledge about how to do that work and when it comes to schedules, if my boss tells me that I have 5 days to finish a task, I go back to my desk and continue working as usual. If it takes 10 days, it must be poor planning on my boss’ part. If it takes 4 days, I’ll spend the other day doing who knows what. Whereas when your developers make the decisions, and developer is the one who says, it shouldn’t take me more than 5 days, that developer has a stronger personal pressure to deliver on his word but it only works if those 5 days aren’t shoved down his throat from up top.

As you keep doing your sprints, part of your process should be to continuously look for improvements, which is what retrospectives are about. And again, the whole thing is completely developer focused. “Guys, let’s discuss what slowed you down and what frustrated you.” Identify the biggest frustrations and eliminate those first and repeat. People will feel more energized and motivated to deliver if they see that the company structure is designed to help them and make their lives easier.

If you do it right, your entire team should get into the mindset (it will take some time but not as long as you’d think, I’ve seen it done in 3 months) of we are in this together. We control our schedule. We want to build a great product. The key is “we”. When you get to that point, a) if someone isn’t carrying his own weight, his own teammates will call him out and ask, Bob “we” are waiting for you to finish this, what’s up?? and b) people will feel more strongly about delivering because their own teammates, not management, are depending on them. So when you get to that point, there will be absolutely no need to reprimand anyone.

This answer is based partially on Agile, partially on management theories they teach in MBA school (yes I went back to school to get masters degree in the dark side), and partially on my own experience in my previous company. I had a great boss who let me try all kinds of things with our team. We implemented a lot of the ideas that “true” agile advocates, and although we haven’t fully gotten there (didn’t have regular retrospectives and unit tests were significantly lacking) but in terms of attitudes, motivations and general ethic, our team really did turn around 180 degrees in 3 months. And while we worked hard, and often logged in at night or at other random times just to complete stuff here and there, a) no one ever asked or forced us to work extra hours and b) we were probably the happiest development team in the entire organization because a lot of corporate BS stopped at our manager.

Not to be too picky but the Scrum Master’s duties are all about Scrum and not giving promotions, checking time sheets, tracking days off etc. That doesn’t mean the same person can’t be the SM and the department manager.

I don’t know about reprimand, but the Scrum Master’s roles involve: making sure Scrum is being done correctly, balancing work loads with stake holder expectations, helping the team perform at a high-level, etc. Some Scrum Masters come from a team lead/manager position, so there may be additional management duties where the SM plays a different role like doing an annual evaluation (not very Scrim-like).

The SM is obligated to let a team know that there is a problem. Teams have to be held accountable and it is very difficult for a SM to tell everyone outside the team that they are working at capacity when they are not. It may not be accurate and/or fair, but if an outside manager sees the team slacking-off, it’s going to be that much more difficult for the SM to defend the team when they fail to deliver.

If it is a particular individual that the team has failed to motivate, that person may need a reprimand not from the SM but some other manager who could in fact be the same person.

Filed under: softwareengineering - @ 12:44

Thẻ: agile, productivity

Can a scrum master reprimand his team?

It is more like a show-cause notice to them. He knows why it is not happening eg:- spending time on social sites or wasting time on less important issues.

Is it okay for him to say “reprimand” the delivery team on their style of working? Or should it be escalated and left for the functional managers to deal with it?

Important thing to note is that usually in an Org, the scrum master is a good friend with his team and so it makes all the more awkward to react to such a situation.

They certainly can. Not everything that a team does is perfect or acceptable in any sense of the word.

Scrum masters should enable a culture of open communication, and scrum masters… are part of the team! So, why would they not point out problems with the team?

Some teams are excellent, self-organizing, industrious and effective. Some other teams are mediocre, incapable of organization, lazy or ineffective. Why wouldn’t it be so?

That said, there’s a big difference between having a blame culture and pointing out clear problems with the team so that they can be addressed.

In summary, this is what we want:

Open communication
One team which includes the scrum-master
When problems arise, they are clearly communicated and addressed
When people clearly misbehave, the bad attitude (never the person!) is addressed openly and fairly
People accepting responsibility

This is what we don’t want:

People keeping secrets or cultivating resentment, while pretending to be happy in the team
Scrum master vs. team attitude
Finger pointing
Fear/blame culture
People ducking responsibility

As long as the SM is aiming for the former and avoids the latter, there is no problem is communicating negatively with the rest of the team.

The scrum master advocates for the team to management and the customer. The product owner advocates for the customer to the team. The manager advocates for the company to individual team members.

As others have mentioned, low output and people browsing the internet is an effect. Your question is how do you fix this symptom but you need to look deeper for the root cause.

If it is a particular individual that the team has failed to motivate, that person may need a reprimand not from the SM but some other manager who could in fact be the same person.

Filed under: softwareengineering - @ 12:44

Thẻ: agile, productivity

Thiết kế website giá rẻ

Danh mục

Can a scrum master reprimand his team?

Can a scrum master reprimand his team?