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.
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.
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.
- Distinguish between communication styles and ineffective communications.
- Use a technique like the Five Whys to uncover the underlying problem you're actually trying to solve for.
- Focus on the expected results of proposed process changes.
- Optimize for team efficacy rather than communications efficiency. There is certainly overlap, but they aren't synonymous.
- Ensure that inclusivity and diversity are supported for the entire team. This will require respect, honesty, and (most importantly) trust.
- Acknowledge that team culture is a living thing, and is built (or changed) slowly over time.
- 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.
- Pick your battles. This may or may not be a hill worth dying on.
- 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.
- 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.