Scrum Master Daily stand-ups
I have recently passed Scrum Master Certification. I have had queries on the role of Scrum Master when it comes to facilitating Daily stand-ups.
I have been a PM in traditional project where I have organised daily meeting with my offshore and onshore team. As a team I was responsible for running and organising logistics for the meeting. However I would like some clarification on the role Scrum Master would play in such scenario.
- I understand SM wont be running the meeting, Development team does: for experienced SMs does your role get taken seriously? I would assume you get from Development team as they might feel SMs are overheads and that they can resolve issues on their own?
- Scrum guide states SM would tell the development team on how to resolve meeting room logistic issues and not actually resolve it for the team. what are some the ways SM can assist in resolving such as issues? As a PM in traditional structure found that resolving logistic issues for my team added greater value where the team was able to focus on their actual work without worrying about admin stuff.
I'm looking forward to being a SM master in near future and this forum has great tips. Thank you in advance for your feedback with above.
The Daily Scrum is solely for the purpose of the Dev Team, and really the only responsibility of the Scrum Master is to ensure that the Dev Team is having the Daily Scrum, that they are conducting it properly (focused on sprint work), and that it is being done within the 15-minute time box.
I do like your approach in serving the team. As a practicing Scrum Master, I usually take the position of doing whatever I can to help the team focus on the work of the sprint. If that means facilitating meetings, so be it. However, I try to be constantly aware of silos and use of specialization within my team and the organization. I may be willing to set up and facilitate meetings, but I also take steps so that the team is not solely dependent on me for that (training, rotate facilitation among team members, etc.).
Just as most things with Agile/Scrum are counter-intuitive, the Scrum Master should strive to grow and mature the team to the point where they are self-managing and less reliant on the Scrum Master. You know you are doing a good job as a Scrum Master serving the team when they begin to look to you for help and guidance less and less.
Do you know the metaphor of the fish and the fishing rod ?
When you are "doing" the job for them, you are giving them some fish to eat.It's OK if they are starving, or if they are not able to learn how to fish.
When you coach your team, you give them a fishing rod in order to empower the team.
See which option best suites your actual context.
Thank you Olivier and Timothy for sharing your knowledge. From both I take that with my Scrum Master hat I'm assisting teams to solve problems on their own. Whereas with my traditional PM hat I'm telling individuals what to do and not how.
I noticed my first query was not clear. Basically I'm curious to know if Scrum Masters have experience any resistance from Development team and or product owner when trying to assist them in solving issues. i.e. often individuals have mindset that I don't need anyone telling me what to do, I know...
Mona,
A good part of the transition from PM to Scrum Master (myself included) involves a change in thinking from being a problem-solver to a solution-helper. Foremost in your approach to your Development Team and Product Owner should be a recognition that they are the value deliverers, and your role (and value) as a Scrum Master is to assist them in following Scrum, making good decisions, and improving how they work, communicate, and collaborate.
It took a while, but I have learned as a Scrum Master to never tell anyone what to do. Learn to make suggestions, provide observations, and give them as much information as possible. There is a world of "soft skills" that are invaluable for a Scrum Master to learn in order to support the team and Agile maturity.
Allow the team the freedom to find their own way, and resist the temptation to tell them what to do. I have yet to encounter a PO or Dev Team resistant to my input when I frame it in the context of helping and serving the team with the goal to make them better at what they do.
I like the analogy of a personal trainer working with athletes. I can make suggestions and recommendations that I believe will make them stronger, faster, and better at what they do, but it is up to them whether they want to follow. The retrospective is a powerful tool for reflection on what they tried (experiments) or didn't try, and the results experienced.
I'll leave you with one of my favorite quotes, from Lyssa Adkins: "The team’s bumbling is better than your perfect plan.”