What you can do to earn your new team’s trust and help them succeed
Barry Overeem has an excellent paper called ‘The 8 Stances of a Scrum Master’. The role of a Scrum Master is one of many stances and great diversity. Depending on the situation and context, the scrum master will act as a servant leader, a coach, a facilitator, a teacher, a mentor, a manager, an impediment remover and a change agent.
Over the past few years, I’ve been working as scrum master with the same teams, with whom we’ve gone a long way. I’ve grown accustomed to working in the same environment day in day and day out. But there came a day when I had to leave this familiar setting and join a new organization with its own unique culture and people. And then I realized that I had no idea what I should do to establish trust with the new team to be their coach, facilitator, teacher, mentor and all those other stances Barry talks about in his paper.
● How do I present myself so that the team will see me as helpful?
● How do I become a true member of the team and earn their respect?
● How do I start helping the team with changes in a way that they truly see value in those changes?
● How do I know what to change and what not to change? Do I really have to change anything and everything that’s not in alignment with the Scrum Guide?
● What if I come on too hard with my suggestions and alienate them? What if circumstances are so different that my knowledge doesn’t even apply?
I needed a specific tool I could use from Day One to get me to a state where the team and the organization would trust me.
After some brainstorming, I came up with five areas I think a new Scrum Master should focus on:
Processes & Tools
For each area, I listed concrete actions you could try (you can also find them organized in a mindmap here).
● Learn about the organization mission, vision, strategy
● Learn about the organization values and observe if they are effectively lived by
● Learn about organizational structures, their key components, and interactions among them
● Learn about the current processes and the working style ─ how agile the organization actually is
● Learn if the Scrum values are promoted from the top of the organization
● Discover organization-wide problems that can be helped with Scrum
● Attend community of practice meetings, if available
● Attend organization-wide meetings and meetups, if available
● Visit organization pages on Facebook, Instagram, Twitter, etc. (be curious about what you read and see)
● See how far along the organization is in their agile adoption, based on Ron Eringa’s 5-Level Scrum Role Maturity Pattern
● Sit down with the product owner and ask him to tell you about the product, its vision, strategy, objectives, roadmap, metrics, hypotheses at work, etc.
● Experience the product as a customer, review customer feedback in app stores and in the media
● Ask the product owner to review the product backlog together, notice types of PBIs used, level of detail and product backlog size and scope
● Learn about the current PBR process and how much the development team is engaged in it
● Learn about the team’s ‘Definition of Ready’, if available
● Provide welcome treats. Bribery wins. Always.
● Go to lunches with the team
● Join team meetings apart from the Scrum events to listen and observe
● Attend the ongoing Scrum events to observe team and event dynamics
● Observe people interactions during work
● Review available team artifacts and metrics, e.g. of the past few sprints
● Check team’s profiles on social networks to learn more about their interests, hobbies and activities outside the office
● Learn about team conventions and agreements to understand their values and what’s important to them
● Ask the team to tell you about their sprint backlog
● Find an opportunity for a couple of get-to-know activities, e.g. at the coming retro, like ‘get to know you’ quiz, journey map and team canvas, ask the team about their expectations and share with them your ideas about the role
● Find small things to help the team with and ask the team where help will be appreciated
● Seek opportunities for one-on-ones at coffee or lunch, talk about what’s going on both inside and outside the office, share impressions and observations
● Have a trip to meet colleagues working from another office
● Learn about interactions and dependencies outside the team
● Learn about organization-wide policies, standards and guidelines the team needs to follow
● Learn about the team’s improvement backlog and what they are working on right now
● Notice deviations from the Scrum Guide and how they affect the team
● Notice problems that can be helped with Scrum
● Be curious, ask questions about what’s going on, offer observations for issues and draw the team’s attention to them where appropriate, find relevant moments to ask the team to ponder new ideas and concepts
● Notice what team is struggling with, suggest observations and stories from experience
● Start helping the team with the Scrum events where they seek help
● Learn about key stakeholders, visit their profiles on LinkedIn or Facebook
● Find opportunities to meet with key stakeholders and really understand their needs and expectations and where you can help
● Observe interactions between stakeholders and the team at sprint reviews and PBR sessions, listen to feedback received
Processes & Tools
● Learn about the team’s development process and what it takes a story to get from an idea to “Done”
● Learn about the team integration and deployment process
● Learn about tools used by the team
● Learn about engineering practices used by the team
● Learn about the team’s Definition of Done
When putting together the list, I thought what if I forget about the fact that it’s a team. What if it’s about just one person that I want to meet and be close to. Would it really be that different from becoming close with a team? I believe not. It would all be about growing trust first. One step at a time. By simply being with the person each day, spending time together, sharing meals and doing things together. I’d certainly want to learn more about the person’s interests and aspirations and share mine. I’d want to find out about what makes the person tick and what makes him or her happy or sad and why. I’d want to learn about where the person comes from and where he or she wants to be. Can I help and how? So, be it a person or a team, it all comes down to small steps first. Seeing, asking, listening, learning, sharing, being and doing things together…
What I’ve come to realize is that the first weeks and, maybe, even months are not about trying to change anything. They are about observing and observing again. What it all boils down to is finding opportunities to be of help where help is needed, securing a handful of small wins that can carry you through this initial learning period and building social capital so that you can influence things at a later date.
To me, a good indicator that I’m on the right track would be noticing how receptive the team is becoming to ideas I’m voicing for them to try.
I’ve found this whole concept in line with the Observe and Orient steps in the OODA loop (short for Observe, Orient, Decide, and Act), originally developed by military strategist and United States Air Force Colonel John Boyd, that I came across in Jeff Sutherland’s book ‘Scrum — The Art of Doing Twice the Work in Half the Time’. They prepare you well for decisions and actions that will come later, and will help you identify areas where you can make the biggest impact first to help your team succeed.
I’d like to extend words of thanks to Max Heiliger, who has helped me and supported me in writing this article. Without him, it would have never seen the light of day. Max, thank you so much.