As a scrum master at a consultancy, beginning a project with a new team is an exciting challenge. There is much to learn about the client and their industry, the product, and the goals of the stakeholders. You must also decide how the team will work together to achieve those goals. But what is the […]
As a scrum master at a consultancy, beginning a project with a new team is an exciting challenge. There is much to learn about the client and their industry, the product, and the goals of the stakeholders. You must also decide how the team will work together to achieve those goals.
But what is the role of a scrum naster joining an existing team? This year, I joined a project mid-stream, on a team that had already been working together for years. They already knew the product and one another. They had established processes and ways of working together.
At the surface, my task was to lead the development team and facilitate scrum ceremonies. But my real job was to help the team work better together and do their best work. To do that, I first needed to discover what type of scrum master the team needed.
Scrum is, first and foremost, about individuals and interactions over processes and tools. Any new scrum master in this situation would be eager to introduce improvements. But try to remember it’s not about you – first, focus on your team.
The very best thing a new scrum master can do during their first sprint is be quiet and listen. Observe the practices and dynamics of the team. You can (and should) ask questions to understand, but don’t provide any directives yet.
Try to learn more about:
Once you’ve spent a sprint learning the ins and outs of the project, you’re still not ready to take the lead. It’s time to establish trust with the team.
Begin by providing context about why you’ve joined the team. Make it clear that you’re not there to enforce the Scrum Guide to the letter. Rather, your goal is to support the team in self-organizing and doing their best work. Your focus is to help them achieve their goals, as opposed to pushing your personal agenda.
To identify the team’s goals, host a retrospective to learn what’s been working and what hasn’t. When deciding on action items, look to the recommendations of the team. Share suggestions and past experiences, but let the team determine next steps.
During our retro, the team expressed some frustration around a specific pain point. They felt product owners valued new features over necessary platform maintenance. We reviewed some of the stories the team had written, which they hoped to work on in future sprints. Many were very technical and did not demonstrate value to the product owners. Over the next weeks, we rewrote them as a team and worked with POs to prioritize the work into our backlog. Following through on this action item was a win for the team and helped show that I was in their corner.
Equally important to team conversations is taking time for 1:1 sessions with individual team members. Get to know them as people. Learn what they like to do outside of work. Ask about their time on the project so far. You may hear feedback they might not feel comfortable sharing with the larger group. Let them know your door is always open for future 1:1 conversations.
A key part of helping the team meet their goals is doing so in a way that is visible to the rest of the organization. This might look like spending extra time preparing for a sprint review or helping the team determine the story they want to share with stakeholders.
Be generous with specific verbal praise, both 1:1 and during meetings. If a team member has gone the extra mile, send a quick handwritten note to thank them.
Don’t forget to celebrate victories as a team. This could be as simple as bringing in a special snack. Mike Cohn of Mountain Goat Software has plenty of great ideas for facilitating a larger reward for agile teams.
When ramping into a new project, focus less on the process and more on the people. Learn what type of scrum master the team needs, and where scrum can help address existing pain points. Build genuine relationships while you build up the team. Doing so will pave the way for successful teamwork down the line.
Source: Atomic Object