Fast start guide for ScrumMaster

Question

I have been hired as a new ScrumMaster for two existing teams

I would like a fast start guide to use as a plan of attack for how I should start.

I am literally going to be dropped into the teams and I want to know what process I should follow.

What should I do first what should I focus on how should I work with the team and POs etc.

Update: I have many years of Scrum and Agile experience as a developer and more recently as a Scrum Master however I would like to inspect and adapt by taking on new ideas from you fine folk

Answer 1

1. Do you do diligence and figure out as much as possible about the project, the people, the customer, and the stakeholders on your own.
2. Talk to each team member face to face about the things above, do not tell them anything besides your background. Let them tell you as much as possible on their own.
3. Mark the common thing you learned from your discover process and the discussions. There is a high chance that this information is solid and you can work on it.
4. Figure out as much as possible about the next delivery.
5. Start socializing with the team, other teams, stakeholders etc. mingle, build up a network, which will be useful when you are about to change something; supporters, helpers etc.
6. Start working with the team and do not change anything; you'll have to learn how they work and they have to get used to you.
7. When you see something is not going well and you know how to change it, use the solid information to make that change.
8. Change only one thing at the time, and let it sink, evaluate the result, discuss the results with the team.
9. Change another thing, and start from 4.

Answer 2

Zsolt gave a really great checklist for tackling any new project. I'd even point traditional project managers at this. I'm going to try and provide some additional Scrum focused detail.

Brand New Team, Brand New Scrum Master: If everything is brand new, you're going to want to set up your ceremonies and cadence right away. At this stage most agile experts advise a slightly more hands on approach (You're in the Shu phase of the Shu Ha Ri or Beginner, Journeyman, Master of learning). The team needs a lot more direction and guidance at this stage. Self-organizing comes once patterns are established. So you want to set up those patterns for the team.

Get your backlog: Before the development team can even start, they need a backlog. Work with the product owner and the team to develop a backlog of at least two sprints worth of work. This means the stories are completely ready for development to start working on them without any more guidance.

Set a Sprint Length: Two weeks is the absolute longest. Many leading Scrum experts advise one week sprints when starting out. If the team says "we can't build anything in a week" you say "well we'd rather see we can build four nothings in a month in a couple of weeks than in a couple of months."

Set your Sprint Start Day: Don't run your sprints from Monday to Friday, it breaks so many good work practices it's not funny. You should never have important meetings before noon on a Monday and you should always avoid major work completion on a Friday afternoon. I personally recommend a Tuesday to Tuesday or Wednesday to Wednesday sprint length. Also don't put your sprint planning and sprint review/retrospectives on the same day, too many meetings in one day.

Set up the Daily Standup: Find the earliest time in the day when everyone can meet. If your last developer doesn't get in until 10:00am, start the standup at 10:00am.

Sprint Planning, Review, Retrospective: Set these up as reoccurring meetings. Since it will likely take you a couple of weeks to get your starting backlog, you can set all these up to start roughly three weeks in so you don't have meeting conflicts with one off meetings.

Information Radiators: Even if you have online project tools, set up a Task Board and a Burn Down chart. Make them very visible and where you will hold you Daily Standup (even better if the other Sprint meetings can also be held here).

Existing Team and Sprints, new Scrum Master Easy, don't do a thing. As Zsolt says in #6 above don't change anything. Spend at least two sprints observing and asking questions. Then you start making suggestions. It is much harder to drop into a team doing "bad Scrum" and help them than it is to start with a fresh team.