When a Scrum Master joins a team, there’s so much to do. It’s daunting and sometimes a bit overwhelming. We have so many questions! Where’s the team need our help? Are they entrenched in how they operate or open to change? How do they interact with each other? How receptive are they to me, their new Scrum Master? Today, I’d like to explain one approach that I’ve find successful, and it all begins with a conversation.
People Over Everything
Forget solving problems. Forget process. Forget all the other organizational noise. Instead, focus yourself on one simple truth:
People > *
Sit with team members individually and get to know who they are. Listen for the lens through which they see the world and learn how they use this lens to view the team. A white board is great for this. Put this matrix on the board and use it as a primer for a rich conversation. Fill it in as questions are answered:
- What’s your biggest strength and weakness? (In other words, their lens.)
- What’s the team’s biggest strength and weakness? (Their perspective.)
- Where should I help the team first?
The final question is often the most valuable. It gives ideas as to where we should place emphasis later. It’s also useful to take a picture of each matrix as the conclusion of each conversation. Later, we can place them beside one another to look for themes, similarities, and differences. Finally, these questions also reinforce a priceless life lesson:
Listen to be heard.
Speaking of which, I’d like to mention a word of caution with respect to our matrix. While the result of the conversation is a completed matrix, it’s not the goal. The goal is to shut up and listen so avoid entering these conversations with an agenda. Instead, allow the team members to guide what we discuss. While doing so, we can quietly determine if they wish to teach us something useful or be taught something that can benefit them or the team.
My emphasis today is a reminder of one of the first lines of the manifesto: individuals and interactions over process and tools. Before we end though, let’s talk about two other activities that can help us integrate with our new team.
- Partner with the Product Owner. Quickly begin to forge a strong relationship with the new PO. Understand her goals and needs and account for these factors in all things. That’s not to say the PO’s opinions and thoughts are our only concern. Instead, it will help us stay ahead of areas where friction could develop between team and PO. The PO will be a great ally as we grow the team, and we need to ensure this relationship is healthy.
- Shadow and observe. If given the opportunity, shadow the exiting Scrum Master on his final sprint by attending all team ceremonies. Doing so provides a preview into how the team members interact and also allows us the opportunity to see how they prefer to conduct their ceremonies. Consistency can sometimes ease the transition from one Scrum Master to another.
Each team we join requires an approach contextual to the situation. The method explained here is one way to quickly determine that context. Do you have your own techniques for getting to understand a new team? I’d love to hear about them in the comments below.
Do you want to get notified when new posts are published? Leave your email below.
14 thoughts on “Scrum Master for a New Team? Here’s What to Do.”
It’s nice and brief matrix to start with. I will be using it.
When, I start with a new team (which i do quite often being a consultant). I start with a dedicated retrospective with the whole team on items to be kept and need improvements especially issues which are hurting more to the team.
From there on, prioritizing issues and creating action points for follow-up.
Let me know how it works for you, Salman. Conducting a retro is another great way to gather information. It definitely would take less time out of my day considering the technique above takes 30 to 45 minutes per a team member. My own technique was borne from my own biases. I’m an introvert, and I prefer individual conversations at the start over the group setting. It’s more intimate and less formal.
Also, thanks for pointing out that I missed one detail in my post. I revised it to add a sentence around taking a picture of the matrix so we can look for themes and the like as we establish some action items for ourselves.
This is great advice Tanner!
This could be valuable for anyone joining a new team in any kind of leadership capacity.
Thanks, Jesse. It is. I agree.
Very helpful and wise advice. This point is spot on:
“Speaking of which, I’d like to mention a word of caution with respect to our matrix. While the result of the conversation is to fill out the matrix, it’s not the goal. The goal is to shut up and listen so avoid entering these conversations with an agenda.”
Thank you, Shelly. That’s probably the most important element of this week’s blog post. I’m glad you emphasized it.
Tanner, that’s a great suggestion, talking to everyone individually. Especially with something external to focus on, i.e., the matrix on the board.
I’ve been shadowing Scrum Masters recently, and one interactional pattern I look for is who talks, when they talk, and what they talk about. In my work as a mediator, I have to asses people quickly, and look for where their conversation isn’t helping.
So I look for who talks. Usually, even on mature teams, people talk in different amounts.
I look also for when they talk. Do they start talking when someone else is talking? Do they wait for silence before they start? Do they talk on certain subjects?
And what do people talk about? Most people will talk about the subject at hand, for example, how to point a certain story, or what are possible explanations for a bug they’re trying to fix. Others will make meta comments, for example to point out that not everyone in the team is talking about the same thing, or that they’ve actually agreed on some issue and they can move on; they tend to be natural organizers.
I look for conversational patterns because that’s easy to observe. Actual, physical observables. I don’t need to try to figure out what their motives are or anything complicated like that. Not at the start.
Brilliant! I do the same thing, but until you penned those words, I hadn’t considered the meta of it all. What you mention is something I try to teach Scrum Masters, but I struggle to verbalize what it is I see when I shadow. What you mention is at the heart of what I write above:
“Instead, allow the team members to guide what we discuss. While doing so, we can quietly determine if they wish to teach us something useful or be taught something that can benefit them or the team.”
Reading through your old and recent posts it’s pretty much relieving for me, as you talk about very relevant topics for me at the moment and I find it very helpful.
On this particular one, I’m helping various ops & dev teams across my organization adopt the agile mindset, by coaching them, facilitating the ceremonies and helping them overcome the resistance to change.
What I found useful while serving multiple teams is to make each one of them feel as they are my only team, as if I’m part of the team. One of the approaches is what you also suggested, by having individual conversations. Then, to be open to get involved, to offer hands-on help to solve a problem. This has proven to be very effective to gain their trust in the beginning.
In order to understand where they might need help, I often ask the team that we create team skills map, not only to show who they can ask for help but also to determine what are the skills we lacking. At this point, I’m trying to be the connector for them and help them develop/grow the necessary skill, so I’m initiating meetings across teams/roles I look over, so they can pair or work in groups on specific skill or problem. The goal is to make this kind of networking/collaboration a habit, so they fully assume the ownership in future.
I’m glad I stumbled upon your blog Tanner. Looking forward to your next entry.
Thanks, Mihail. I appreciate the vote of confidence, and you provide some excellent advice in your comment above.
I just discovered your blog and I love it! Thanks for the valuable advices distilled in each post.
I really like the idea of Matrix with individuals chat, I have not done this on my previous Scrum implementation and I think I will use it definitely for the next one.
What I have done is first gathering insights from everybody. Non-orthodox quick chat and coffee breaks to take the temperature of the teams.
The best is to go outside the office for quick walk, people tend to really change and open up easily outside walls.
Then, I organised a sprint retrospective with the speed-boat format. I found this one really useful and simple for everybody to understand it and to gather a maximum of data.
I would also say, it is good to chat with the team members and Product Owners but if one can, have a chat with the upper management and see what is the vision on the teams. Sometimes you might found there is really frustration and mistrust going on by the upper management and that’s a potential killer for a team so I like to take temperature on this side as soon as possible to re-establish the communication link.
Looking forward for the other posts.
Thanks so much, Diane. I hope some of my musings help. 🙂 . Great advice in your comment and many of those things I employ as well. Especially the part of getting people out of the office to chat. Even a walk around the block or neighborhood makes for a better setting than a stuffy conference room.
Pingback: Confluence: Agile at Large
Pingback: Confluence: Agile at Large