If you need a scrum team to do something, as a servant leader what is the best way to influence them?

I was thinking of talking individually to each and explain why seeing their faces is important for me to do my job ie is it reasonable given the situation to ask scrum team members to turn on their cameras during ceremonies?

I am finding it difficult to “read the room” otherwise.

  • 1
    Comments are not for extended discussion. While there were some insightful comments, the overall tone of the thread was argumentative and inflammatory. All comments have been purged, and I strongly encourage folks on all sides to reframe their comments as constructive answers instead.
    – Todd A. Jacobs
    Commented Aug 8, 2020 at 1:59

4 Answers 4


Adding to the excellent answers you have already.

Perhaps consider asking the team to do an experiment? Make the change you propose for a given amount of time and then review if it made things better or worse.

There is often less resistance to an experiment than to something perceived as a permanent change.

  • 1
    This can work if there's already a lot of trust between the team and SM. But if you don't do it carefully and very, very honestly--willing to go back to the old way if that's what the team prefers even slightly, then it's really easy for the team to feel coerced or like you are only getting their agreement pro forma. We have some SMs who think they are actually managers who are always looking for ways to get people to agree with them or at least stop objecting, rather than genuinely trying to see the team's perspective. Commented Aug 7, 2020 at 19:05

Raise the matter first during a retrospective and find out how the team feel about it. One time I can see when visual feedback might be important is during sprint planning. In planning sessions the SM may need to guide both the PO and the team and will want to know that everyone on the team is comfortable with the sprint goal. There are alternatives to video feedback though. You could create an opinion poll in whatever collaboration software you use.

During daily standups the team's preference ought to take precedence over the SM. The development team ought to own and run daily standups collectively whereas the SM's attendance and involvement is discretionary (unless the SM is also a developer of course).


I think it is valuable to make a distinction here between a need you have for yourself vs a need the team has that you are helping them with.

If this is a personal ask, then servant leadership has nothing to do with it. It's a request from one co-worker to another (or a bunch of others). You could raise this at a retro or in conversation - that's largely up to you.

On the other hand, if you are seeing an impact to the team that they are perhaps not seeing, then this is where you are acting in your capacity as a Scrum Master. Often times, a good approach can be to share what you see with them and see how they'd like to move forward. Again, it could be brought up in many different venues, but retro is the most likely.



As a member of the Scrum Team, you should articulate your needs and preferences as worthy of consideration by the whole team during a Sprint Retrospective. However, as a Scrum Master, your job is to facilitate the team's smooth functioning within the framework by supporting whatever works for them, so long as it doesn't contravene essential framework requirements.

The Scrum Master Role Doesn't Define Non-Framework Process for the Team

If you need a scrum team to do something, as a servant leader what is the best way to influence them?

You are conflating needs, wants, influence, and control. A servant leader coaches and supports the team in self-actualization. Your job is to referee the process, not dictate it. That needs to be front and center in your thinking as you evaluate a suitable approach.

Unpacking Some Assumptions

I was thinking of talking individually to each and explain why seeing their faces is important for me to do my job ie is it reasonable given the situation to ask scrum team members to turn on their cameras during ceremonies?

"Important to me" isn't the same thing as "essential to the framework." That doesn't mean it's irrelevant, though. Let's unpack this one a little bit.

Scrum is silent on this issue, but the principles behind the Agile Manifesto include this one:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

While this statement is arguably true, it is not the sole consideration. There are other factors that should be carefully considered in deciding how (or even if) the team needs to tackle the videoconferencing issue you're raising.

Communications Bandwidth

This is a statement of principle, not a framework requirement. It's presumably based on the widely-repeated meme that 80% of interpersonal communication is non-verbal. This source and validity of this figure is a matter of dispute, but it's probably safe to say that a non-zero percentage is non-verbal, and that narrower communications channels require more verbal and other soft skills to make up the difference.

When considered solely from a bandwidth perspective:

in-person > videoconferencing > audioconferencing > chat > email

Of course, bandwidth is not the only criteria that should be considered. Many people also have emotional responses to different types of communications, whether positive or negative. It is often these different visceral reactions that cause disconnects such as the one you're experiencing with the team.

Other Considerations

Teams are made up of people, and people are extremely diverse. Respecting that diversity is an important factor in creating effective teams. Forcing face-to-face communications can therefore be counterproductive for some teams.

As a member of the Scrum Team, you are well within your rights to articulate the challenges you experience with verbal-only communications. However, other team members may have other considerations than yours, ranging from household privacy concerns to neurodiversity needs. Team cohesion comes from finding ways to work effectively together, not from requiring everyone on the team to work the same way.

Measuring Results & Outcomes for Continuous Improvement

As a member of the Scrum Team, you are perfectly within your rights to share the challenges that a team's preferred mode of communication present for you. From a process point of view, though, you need to define the impact in a measurable way so that the team (including you) can focus on outcomes rather than preferences.

In other words, rather than focusing on the differences between how you and other team members prefer to conduct your Scrum events, you should collectively be focused on the outcomes of your current and proposed processes. If your current process is creating muda because of miscommunication or ineffective framework events, then the team needs to collaborate on improving the process in a way that works for everyone on the team, including you!

Recommendations (Because Top-Ten Lists are Awesome)

Here is a distilled list of things a Scrum Master in your situation should consider. You're welcome to mix-and-match or roll your own, so long as the end result has buy-in from the entire team.

  1. Distinguish between communication styles and ineffective communications.
  2. Use a technique like the Five Whys to uncover the underlying problem you're actually trying to solve for.
  3. Focus on the expected results of proposed process changes.
  4. Optimize for team efficacy rather than communications efficiency. There is certainly overlap, but they aren't synonymous.
  5. Ensure that inclusivity and diversity are supported for the entire team. This will require respect, honesty, and (most importantly) trust.
  6. Acknowledge that team culture is a living thing, and is built (or changed) slowly over time.
  7. Express your own needs and preferences when appropriate, but find ways to support the needs and preferences of the rest of the team as well.
  8. Pick your battles. This may or may not be a hill worth dying on.
  9. Always remember that you can lead by example or offer recommendations, but you can't make people change. The only person you can change is yourself; that's a limitation of life, not Scrum.
  10. Not every team culture is a good fit for everyone. If you have an entrenched communications culture that is a poor fit for you personally, consider finding another team to work on.

As with many things in the field of project management, there are no simple solutions to complex challenges. That's why Scrum focuses on empiricism, and that's why the whole Scrum Team is expected to focus on measurable outcomes rather than abstract principles.


Not the answer you're looking for? Browse other questions tagged or ask your own question.