October 31, 2020

Agilists

News for Agilists

How to get started with a new team as a new Scrum Master? | by Zoltan Csutoras | Serious Scrum | Oct, 2020


Photo by Jukan Tateisi on Unsplash

When entering a new position as a new Scrum Master, your organization will expect you to make the team better. But, how can you start this journey with a new team?

The first thing you should grasp for true success is that this responsibility doesn’t only rely on you. It’s not you who will make the team better, it will be the whole team who, with your guidance, will change their behavior, their beliefs, and their values. Note the word “guidance” — as a Scrum Master, you can facilitate that change, but you can’t force it.

This journey begins before you join the team. The team doesn’t operate in a vacuum, but usually in the context of a larger organization with an established corporate culture.

Success won’t be at your sole discretion. There are organizations that are fully incompatible with agile values, and there is almost zero chance that you can facilitate a successful agile team within that context.

Try to notice if the company culture is inherently incompatible with agile, and keep away from organizations that are not compatible. One aspect of the company culture I’m always paying attention to is how managers talk about their subordinates. I find it a bad sign when managers refer to team members as „resources” because it might be a sign of the lack of respect.

Do they truly share agile values, or simply follow a few practices and apply some “agile tools” on the surface, still sticking to a command and control based culture deep inside?

Before joining a company, have a conversation with the managers who oversee your future team and try to understand why they are following agility. Some important questions to ask are:

  1. What are their expectations of Agile?
  2. Do leaders understand the real dynamics of Agile, or do they just want a silver bullet that will skyrocket the teams’ performance without any investment?
  3. Do leaders want to participate in the change, or do they want you to change the organization for them?

Don’t get me wrong, I’m not suggesting that an experienced Scrum Master should only join an already agile organization. I’m not saying that you should expect all leaders to be full-heartedly agile. However, I am advising you from previous experience to ask yourself an important question before joining the club: do I truly believe that “this” organization will be able to accept the agile mindset?

Once you decide to accept the challenge with the company, you can focus on the team.

Your new team members are likely to be nice and friendly people. However, just like you, they will feel a bit insecure. If they love their previous Scrum Master, they will miss her. If the former Scrum Master was a jerk, they will be suspicious about Scrum Masters in general. If they are just starting their agile journey, they will be completely unsure of what to expect.

When possible, it is better to meet the team before you sign the contract so they can see you as an option, not an imposition. You’ll look less intimidating as an option that can allow you to break the ice.

Many agile organizations would probably involve team members in the process of selecting the new Scrum Master anyway, but if your future employer doesn’t offer the possibility to meet the team, ask them to do so.

When you meet the team, be humble and friendly. Listen more than you speak, and be ready to talk about you and about your vision of a great Scrum Team.

Talk with the product owner of the team. Ask her to explain the purpose of the product. What do you think? Would you be proud of assisting this product to be born? Is the product owner the kind of person who can talk about the product in a way that inspires you?

If you find that you can align with the company culture and both parties have positive feelings about working together, your most important task is to earn the team’s trust.

Have you ever met someone who enters a room where a group of people are already having a discussion and jumps into the conversion awkwardly, without any understanding of the context?

Don’t be that guy.

Listen first. Observe, ask, and learn. Repeat.

The best way to alienate yourself from the team is by trying to show how clever you are. You might be an expert on the Scrum Guide and all the agile values, but there are a few things you know almost nothing about: their history, their values, the dynamics between team members, and you know less about the product they’re working on than any of them.

Understand their values, their habits, and definitely never try to be a Scrum Guide Preacher.

Invite team members to informal meetings — like lunch, breakfast, a walk, etc. Find opportunities for one-on-one conversations. Get to know them as a person but also take the opportunity to ask them about the product, their processes, and their difficulties. Take notes when they talk about the product and its processes.

Photo by Helena Lopes on Unsplash

Try to learn as much about their history as you can. You can’t truly understand a team without knowing their history. If you do the interviews well, you may find some (hidden or explicit) tensions between certain team members. Make sure not to make judgments. Those conflicts will probably make your job harder, and it’s good to know about them, but don’t try to solve them yet.

And refrain from taking notes when they talk about sensitive or emotional topics.

The 5th principle behind the agile manifesto says:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

When you talk with the team members, make sure you ask about their feelings towards the product. Do they love it? Do they feel engaged? Are they a part of the discovery? Or is it just another list of work items?

Talk with the Product Owner and try to find a way to assist her in refining and selling the vision of the product.

Don’t underestimate the importance of having a compelling vision.

Once I had the opportunity to work with a team at a very successful cheminformatics company. A company that serves big pharma organizations with solutions that can speed up pharmaceutical experiments via complex simulations. This particular team was involved in the development of the Javascript version of the company’s biomolecule drawing tool that was originally running on Adobe Flash.

To be honest, I found this project to be quite boring at first sight. And I got the feeling that so did most of the team members as I felt.

When I met the product owner, I immediately realized how bright she was. She was an expert in chemical simulations with a Master’s Degree in Computer Programming and a Ph.D. in Chemical Science. She knew everything about computer-aided chemical simulations.

When I asked her to tell me more about the product, I understood that this software shortens the development cycle of medicines by months.

She told me a story about the development of a medication to treat malaria that their tool helped to speed up. I was then able to immediately translate the importance of the tool they develop.

Around 500.000 people die of malaria a year. That’s more than 40.000 victims per month. If their tool is capable of accelerating the development of a malaria medicine by 3 months, it could potentially save 120.000 lives. Yes, I know that it’s extremely simplified and overly idealistic, however, this kind of thinking immediately boosted my motivation. So, I asked her to tell me and the team more stories about what kind of medicines have been developed with the assistance of their tool.

Knowing the impact of their work can become that igniting fire.

If the team is passionate about the project, it’s already half of the success for you. The more the team members love the product, the easier it is to build a high-performing, enthusiastic team. If the team has no passion for the product at all, chances are high that you’ll end up as a psychological assistant of an unhappy club instead of a performance-improving agile facilitator of an empowered team.

When you talk to team members, try to understand the rules and norms they already agreed upon.

The agreed values and rules will be the primary source of your authority. You’re not a manager who dictates. As a Scrum Master, you lead by adhering to the collaboratively developed and mutually accepted rules and values of the team.

It shouldn’t be you who holds team members accountable to meet the shared norms and values, but you should be the one who facilitates a flourishing atmosphere where team members care about their culture and hold each other accountable towards shared goals and norms.

Do they have a written working agreement?

If not, being the new Scrum Master creates a great opportunity to organize a discussion where they explain to you the way they work, and where you can create notes that you share with the team as a basis of a written working agreement.

If they already have a working agreement in place, organize a retrospective session where they can explain the evolution of their rules, and review and update the agreement together.

We can think of the next idea as part of building the team working agreement. Fabian Schiller and Jürgen Hoffmann presented a retrospective exercise, called BYOSM — Build Your Own Scrum Master — that helps the team to envision the ideal Scrum Master for that specific team. The exercise focuses on three questions:

  • What properties does your perfect SM display?
  • What does the perfect SM have to know about you as a team so that he/she can work well with you?
  • How can you support your SM to do a brilliant job?

This exercise helps you to understand what the team thinks about their ideal Scrum Master, and also creates a sense of mutual responsibility: it’s also their job to help you to become the Scrum Master they need.

Provide value to the team as fast as you can, but don’t be an eager-beaver. Keep in mind that while you’re striving to prove your value, their primary pain is to meet the expectations of the organization and deliver a working product. Try to find the best way to contribute to this endeavor and make their life easier.

The best way to make yourself useful is to resolve impediments that hinder their progress.

My final thought is to be your true self, to be authentic. This is a key element of building trust — the fundamental basis of becoming a successful Scrum Master.

Do you want to write for Serious Scrum or seriously discuss Scrum?



Source link