Any Advice for New Scrum Master Joining in New Team

What I personally typically do, is just to listen the first week or two. Write things down that you feel are worthy of it, don't directly start coaching or teaching or whatever from the get-go. Feel the dynamics, read the room, talk to people individually, ask them question. Figure out what they're trying to achieve,  take a look into the way they develop the product and so on. Start working from there:)

In addition to what Sander said...there's a Sprint Retrospective you can do with your team, called Build Your Own Scrum Master (BYOSM). You can google it to find out how to facilitate it.

Essentially you draw a Scrum Master with a brain, heart and stomach. Then you ask your team questions, in three phases, about what a Scrum Master needs to have in their brain, their heart, and their stomach. The questions are something like:

• What skills and traits does your Scrum Master need to be effective for our team?
• What does your Scrum Master need to know about our you to help our team succeed?
• How can you help and support your Scrum Master to do a great job?

Be curious!

Totally agree with Sander and Chris, but if the team is completely new, I would start with a kick-off for two reasons. First to have the team get to know each other, as they will have to work closely together. Second to check if they are familiar with Scrum or if you need to talk about certain things beforehand.

Also in that session, I would go for Chris' mention on BYOSM or even build your own scrum team, to define how you are working together, when and where the Daily is done, how long you want to go for the Sprints etc. In most cases, be curious, let them start to self-organize and only moderate or coach if needed.

I like Tim's suggestion to do a kickoff, perhaps a Scrum reboot or tuneup, if you observe a Sprint and it is warranted. My experience is that many teams say they are using Scrum, but that is sometimes not the reality.

Can any one adive me tips to engage with them or setps should I take before I start steering them on agile

I remember Gunther Verheyen once remarking that Scrum Begins with Done.

I think there's enough truth in that statement to provide a starting point. What will a team actually do to ensure that the work they produce, each Sprint, will be of release quality? Why is it important for them to ensure that this is indeed the case?

Meet with each team member one-on-one and have a conversation. Get to know them first, and build trust. Schedule team-building exercises, like an online, live Trivia Game. Training on Agile can come after, and will happen more naturally once they know you.

Very Nice responses Folks ! Really appreciate. I personally being with joining the team with child like curiosity and keeping it very simple and asking genuine questions in one-o-one touch points and mingling with the teams.

I agree with the responses above. Sometimes we forget the people and focus on the skills e.g. Scrum.

I like the sound of BYOSM, fun https://www.linkedin.com/pulse/do-you-want-join-team-scrum-master-marek…



I have also learned:

1. Not to presume the level of existing knowledge of Waterfall, Agile, Scrum or anything else, some developers have only worked in chaos.
2. When coaching Agile and Scrum explain the "why" and not just "what" they are, developers need to know where we came from and why.
3. Learn how to Team have been working up until now and ask them "why". Kanban or something else could be a best fit for what is going on right now. I would question "why" in order to get a to the root cause.
4. Do not overwhelm the Team with Agile and Scrum;
   1. Story Points for example can be a huge source of contentment, so don't bring it up for a while.
   2. Start with the Standup and get it down to 15mins and get the Team to work as a Team and explain "why".
   3. Get the Team demoing. 
      
      
      
       

https://medium.com/serious-scrum/how-to-get-started-with-a-new-team-as-…

All I would say is, start connecting with people first. Know them, understand them. If you start dwelling on the metrics to figure out people, then it will simply set the tone as Dev Team vs Manager (scrum master will only be for you)

I'll add one other point to Niall's list.



4.) Don't sweat sizing - it's a learning curve and the team, especially devs, may be overwhelmed with sizing a project. They don't know what a 3 or a 5 is (in the fibonacci sequence) and they can get flustered at first in a sprint.