After working with 100+ teams this is a short framework for a Scrum Master/Agile Coach starting in a new team to avoid disaster and get some sh*t done 🙌🏼 (part 1)
Part 1 of 2 - on initiation and observation.
This is part one of a series of two. Let’s dig in!
What are you doing here? 🤷🏼♂️
Some questions to think about before you say "hi":
Who are you? What is your role? Why are you there? What is your intention?
Depending on why you are starting to work with this team, there might be some steps before you are introduced. If the reason is that one of the stakeholders is not happy with the team's work - they should share the feedback directly.
Don't get caught in being a middle-man doing the dirty job. If someone else noticed something - they should be the one to share it.
How do you work? What do you value in working with a team? Are they ok with that? What are the team's expectations towards you?
At the nearest meeting or a retrospective, you can briefly share what being a change agent mean to you and how you do your work. You can also gather initial expectations. This will help to avoid assumptions which, if unspoken, will only make you and the team grow apart.
What do you plan to do in the initial days of working together?
Listen and observe 👀
I listen and observe for the initial 1-2 weeks joining team meetings and chat rooms and talking directly with team members, stakeholders and other teams they cooperate with.
I always mention what I’ll focus on and why and share candidly and transparently my observations with the team.
Some of the things I focus on:
Product, e.g. product quality, feedback loops, doing the right thing at the right time, the usability of delivered increments, what does ‘done’ mean?
Process, e.g. flow of work, bottlenecks, empiricism, what is measured and why, how people learn and adapt, company’s performance expectations.
Interactions e.g. communication between team members, group dynamics, underrepresented voices, honesty, respect.
Self-organisation, e.g. what can the team handle and what they can’t, handover of work inside the team, decision-making skills, assertiveness.
Some additional questions to think about (a non-exhaustive list):
Is the whole team engaged in working with the product? How do they collaborate to do the right thing at the right time?
How does the team handle change during the sprint and work with other teams?
What are the most significant challenges the team is facing right now? Do they have support to solve them?
How consistent is the team with their learnings and validating them over time?
What is the other team’s feedback on how your team is working?
I collect my thoughts in an old-school paper notebook, including quotes from conversations I hear. The latter might sound controversial but I will shed more light in on it in the second article. I don't, of course, copy data from Jira and create diagrams on paper. That said, I value the analogue aspect which is not distracting.
Part two will focus on sharing findings, searching for the right leverage and showing progress. Read it here 👇🏼
—
Is the above framework bulletproof? Nope. Will it make you feel safe? Maybe. Should you always follow it? Nope. Treat these points as an inspiration and things worth placing focus on. Follow your gut and don’t forget to have fun!