My approach is to create a collaborative environment using Scrum's inspect and adapt core, to get the most valuable things done first and frequently.   Get the team up and running with a steady flow of work towards an identified product goal, and then look at what problems are being surfaced.

I've worked long term with about a dozen scrum teams, and been involved in some form of cross team capacity with probably about four times that number.   Individuals and contexts change, but the same patterns and behaviours often repeat.

When I'm embedded in a team as a Scrum Master, I am one of the team, and that's an important foundation.   I start by trying to establish the team's permission - their consent -  for me to guide, suggest, facilitate and contribute.  Even this can take some working at, and is not always immediately granted in practice.

For a new team, I'll start with some form of initiation activity. Some call this Sprint 0, and that works for me but it's not always a popular term, so I go lightly here.   But the point is, a team can rarely start working on Day 1 despite the purist view.   If they can, great, but in big organisations it can take a month to even get a systems log-on (and that's a real example).

A new team needs to know its individual's skills, preferences, aspirations, boundaries.   We need to iron out enough  differences in our experiences to date so tat we can have a common way of working whilst benefiting from all that diversity of experience.  We need to agree how to visualise work, how to estimate, how to version control, how to release. 

I'll make sure we start with a basic roadmap showing the product vision, a sufficiently stacked backlog to start meaningful feature development, and a working structure which allows measurement for predictability.

 

As a Scrum Master to 1 or 2 teams,  I can help...

 

• Team spin up from new, or team re-boot
• 'Run' a couple of scrum teams day to day
• Help struggling scrum teams become aware of and fix their problems
• Surface realistic information about likely outcomes for predictable planning
• Assistance with user stories / product backlogs, MVP selection
• Team empowerment, trust building and accountability
• Advice on how to move beyond constraints
• Complement the work of incumbent agile coaches by relating teams' reality to wider improvement initiatives