8 conversations to have with your new team in the first 30 days
Scrum Master onboarding. How to quickly build alignment with your new team?
When you join a new team as a Scrum Master, the “pressure” of “implementing Scrum” is high.
“I must justify my presence by showing how knowledgeable I am in Scrum.”
That’s the thought in most SMs' minds.
But…in reality (as experience has shown) your first 30 days shouldn’t be spent worrying about “implementing Scrum”… at all.
This crucial time should be spent strategizing how to build TRUST and ALIGNMENT.
On your first day with a new team, they’re thinking: “Is this person going to make my life easier… or harder?”
And if you don’t bridge the TRUST and ALIGNMENT gap faster, the journey may be harder.
In today’s post, I’m sharing 11 conversations successful Scrum Masters have with their new team within the first 30 days.
The kind of conversations that surface the “invisible stuff.”
Let’s get started.
If you are new to Winning Strategy, check out the posts below that you might have missed
Got an urgent question?
Get a quick answer by joining the subscriber chat below.
#1: What does good look like for this team?
The goal of this conversation is to align on outcomes and expectations before you start “fixing” anything.
Early on, ideally in your first week, sit down with the Product Owner.
Ask: “When you think of a great Scrum Master, what do they do for you and the team?”
Then: “What two or three outcomes would make you thrilled in six months?”
Next, talk to the team.
Ask:
“What things regarding your current working methods must remain unchanged?”
“What frustrates you about how you deliver?”
Then look into the future and ask:
“If we see progress in three months, how will your daily life feel different?
This conversation will help you capture expectations and identify those that are not spoken about. You’re not here to impose Scrum, but to work with them to design how you’ll succeed together.
#2: How do we make money and create value?
In your first week or so, try to learn how the product actually creates value. This will help you support better team and product decisions, not just better Scrum events.
Here’s how to do it:
Sit down with the Product Owner, Product Manager, or a senior stakeholder and ask a few powerful questions. For example:
“What problems does our product solve, and for whom?”
“How do we measure success today, i.e. revenue, retention, conversion, NPS, something else?”
“What are the current big bets or strategic themes for this product?”
“What’s the cost of delay if we ship slower than we do now?”
Then:
Link this back to day‑to‑day Scrum. For example:
“When we’re in Planning or Refining, how can we keep these metrics visible?”
“If we had to cut 50% of the backlog, what would we keep and why?
By doing this early, you’re making it clear that Sprint events are about value creation.
#3: How do work and ideas enter this team?
Once you’ve been around for a week or two, it’s time to understand how work actually flows.
Not how it should flow on a process diagram.
The goal of this conversation is to map the workflow from idea → production → value.
Here's how to do it:
Bring the whole team and the Product Owner together. Pick the last release the team shipped.
Ask:
“Let’s take the last feature we shipped. Step by step:
how did it start,
who touched it,
where did it wait?”
“Where did we get blocked or slowed down?”
“Who outside this team can stop or delay our work?”
As your team talks, sketch the following on a whiteboard:
Triggers: where did requests come from?
Queues: where did work pile up (analysis, QA, ops, legal, design, etc.)?
Feedback loops: where did the team get product feedback, user data, or stakeholder input?
By the end of this conversation, you will start to see bottlenecks, such as constant UX wait times or unstable environments, and you and your team will have a shared picture of the current system.
That picture becomes the foundation for future improvements, such as WIP limits and better refinement, etc.
#4: What does “Done” really mean for this team?
In your first couple of weeks, use a Refinement session or Retro to uncover what “Done” actually means for this team.
Do not lecture them about what a DoD should be.
No!
Ask them:
“When we say ‘this is done’, what does that currently include?”
Then talk about the pain points:
“What’s delayed the team in the last few months, i.e. bugs in production, rework, compliance issues?”
Finally:
“What should ‘done’ include so we don’t get those surprises again?”
As they talk, walk through different angles of “done”.
Things like:
code (merged, reviewed, maybe feature‑flagged),
testing (unit, integration, exploratory, performance, security),
documentation (user‑facing and internal),
product (acceptance criteria and sign‑off), and
ops (monitoring, alerts, rollback).
Aim for a team-owned Definition of Done, not something you impose. Set a quality level that feels ambitious yet realistic in the current context.
If you’re helping your team create a Definition of Done from scratch, this post might help.
#5: How safe is it to speak up, experiment, and most importantly… fail?
In your first few weeks, you want to understand not just how the team works, but how safe it feels to tell the truth.
You’ll often see the surface level politeness, not what’s not being said.
Here’s how to do it:
In small groups or 1:1s, ask things like:
“When was the last time someone raised a concern, and it was genuinely welcomed?”
“When was the last time you tried something that didn’t work, but you still felt it was a good decision?”
You can also probe Scrum: “If you think something the team does in Scrum is pointless, how easy is it to say so?”
In 1:1s, go deeper with questions such as:
“If a new joiner asked you, ‘What should I be careful not to say or do here?’, what would you tell them?”
The answers will disclose the unwritten rules.
You’re not going to fix all cultural issues in 30 days, so DON’T even try.
What you can do, however, is show that YOU are a safe person to talk to and that you’ll protect and encourage honest conversations.
Take a look at the post below for a unique insight into building team cohesion!
#6: How do we want to use Scrum events (really)?
By your second or third week, start exploring how the team actually experiences the Scrum events. The goal is to make the events serve the team and the product, not the other way around.
Approach each event with curiosity as if you want to define a new process for the team.
For Sprint Planning, ask:
“What does a useful Sprint Planning look like?”
“How do we currently decide what fits in a Sprint?”
“What information do you wish we had before committing?”
For the Daily Scrum, go straight to its value:
“If Daily Scrum disappeared tomorrow, what would you miss?
“What would you celebrate?”
“What needs to change so Daily Scrum helps you deliver value, not just report status?”
When you talk about Refinement, focus on preventing the chaos:
“How often do we need refinement to avoid last‑minute stress in Planning?”
“What makes an item ‘refinement‑ready’?”
For Reviews and Retros:
“Who should be at our Reviews to make them genuinely useful?”
“What topics are we currently avoiding in Retros?”
From whatever you hear, suggest a few small (not big) experiments.
For example:
“For the next two Sprints, let’s try X in Planning and Y in the Daily, then see if it helps.”
Make it clear you’re not here to enforce rituals.
Scrum is a framework, and together you’ll shape how each event works as long as it stays anchored in transparency, inspection, and adaptation.
7: What’s the real relationship between PO and Team?
Around the middle of your first month, start exploring how Product and Delivery actually work together beyond the polite surface.
Here’s how to have this conversation:
Begin with a joint discussion. Ask:
“How do we currently decide what goes into the next Sprint?”
“When scope changes mid‑Sprint, what happens in practice?”
Then check the alignment between the PO and the Team:
“How often are we surprised by what was actually delivered versus what was expected?”
The answers will show you how decisions are made and how transparent they are.
Now split.
With the Product Owner in a 1:1, ask:
“What do you wish the team did more of to support product outcomes?”
“What do you feel are only your responsibilities that you’d prefer to share with the team?”
Also check for pressure from above:
“How comfortable are you saying ‘no’ to stakeholders, given our capacity?”
Now have a 1:1 with the team:
“How easy is it to ask ‘why’ about backlog items?”
“Do you feel you can influence what you build, or only how you build it?”
This will reveal whether the team is an active partners in product decisions.
Your goal here is also to make decision boundaries clear:
who owns priority
who shapes the scope
who decides the technical approach
This will also help push more product thinking into the whole team, not just the PO.
#8: What do you need from me, and what do I need from you?
In the second half of your first month, have an honest expectations chat with the team and Product Owner, so you don’t end up as their meeting secretary.
You might say:
“Let’s exchange our expectations with each other. What do you need from me to do your best work?”
“What should I stop doing if you ever see me doing it?”
Then share your side:
“Here’s what I need from you to be effective in my role…”
This is a good time to spell out how you see your job.
For example:
“I’ll help surface impediments, but I need your honesty about what’s really going on.”
“I’ll protect focus where I can, but I need you to raise concerns early when you’re overloaded.”
Follow up with 1:1s to make it personal:
“How can I support you specifically in this role?”
“What’s one thing a past Scrum Master did that you never want to see again?”
This conversation will change your generic “process person” image to that of a “partner” in how the team delivers.
Takeaway
A few suggestions for turning this post into action:
First, you don’t need a bunch of extra meetings. Most of these conversations can live inside things you’re already doing, i.e. Planning, Refinement, Reviews, Retros, or quick 1:1s.
Change the existing agenda instead of sending another invite.
Keep the conversations light. Focus on listening more than talking.
In your first 30 days, your credibility is not built by having all the answers. Specifically, in your first 30 days, your credibility is built by showing that you really understand how the team and the system work before you suggest changes.
Also…
Make a habit of writing things down.
When you hear a clear agreement, write it down. Share it with the team so everyone can see it and correct or refine it.
Once you have these conversations, you will find yourself more confident in your new team.
Show your support
Every post on Winning Strategy takes ~ 3 days of research and 1 full day of writing. You can show your support with small gestures.
Liked this post? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone who would find this helpful? Make sure to recommend it.
I strongly advise that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.
Further Reading
Connect With Me
Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.
Brilliant framing of how trust comes before process. The question about what should stay unchagned is subtle but powerful because it acknowledges the team probably alredy has useful patterns worth preserving. I've seen new Scrum Masters rush to impose frameworks and wonder why teams resist, when the real block was skipping these alignment convos first.