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...
The Scrum Master is variously the coach, the facilitator, the teacher and more. Analogies don't end there: the bulldozer, the guardian, the sheepdog... it remains a hard role to define, often perhaps because it is frequently moulded moulds to fit the client - and their limitations.
For now this paper, The 8 Stances of a Scrum Master remains
for me one of the best things ever written about a Scrum Master.
© Agiliqui Consulting Ltd