Scrum Master and knowing statuses
Hello Community,
I need some advice on a unique situation I am going through. My organization is asking scrum master to provide weekly status of features. They want me to present how features are going and if things are according to the timeline. I could definitely pass that along after having communicated with the product owner and the architectural lead. However, they are asking me questions like "How does pushing a certain functionality to production affect the end clients?" AND "What is being done about UAT testing? Were the end clients provided with a test script for usability testing? What is being done when they don't have access to log in?".
Additionally, I m being asked if end clients are able to use the product or what value they are getting if the team completes certain user stories. We have the VP of product, director of delivery and product managers in the call.
When I spoke with my manager who is the IT developers director, she is telling me that the organization has always had scrum masters know the status and timeline. They are the ones who know the "how". And the product owners provide the "what" and "why". How am I provide these statuses when I am being asked all these architecture/ product heavy related questions? Thank you!
the organization has always had scrum masters know the status and timeline. They are the ones who know the "how".
I'd suggest that isn't good enough. The organization should be more ambitious and have Scrum Masters focus on improving its understanding of Scrum, and how it can better leverage empiricism under conditions of high uncertainty.
For example
- Never mind status reports. Establish transparency so those doing the work can inspect and adapt based on what they see.
- Respect the Developers as the technical experts who know how their own work is being Done
- Respect the Product Owner as the accountable authority who understands the progress of incremental value delivery over a given timeline
Perhaps management are thinking of a Scrum Master as being yet another manager in their own mold: someone who co-ordinates, orchestrates, and directs. If so, that's one of the very assumptions which may need challenging.
It sounds like your organization doesn't understand the role of the Scrum Master. Instead of considering the Scrum Master to be a coach and a facilitator, they are looking at the role as something closer to a project or program manager.
From a purely coaching perspective, if key stakeholders are asking about the status and progress of development work, I would be looking toward the information they need and the information radiators that the team is providing. I'd approach it from two fronts. Toward the stakeholders, I'd want to make sure that they understand agility and iterative and incremental development and how to best interact with teams working in this way, including what measures and metrics make sense to address their concerns. Toward the team, I'd look for ways to make the work and state of work highly visible and reduce the manual burden of updating information, trying to integrate it as seamlessly as possible into the team's way of working.
The questions that your organization are asking you are things that others should be able to answer, either the Product Owner or one or more of the Developers. Having the Scrum Master serve as a funnel for communication is not only missing the purpose of the role, but will only add a bottleneck to the process.
"How does pushing a certain functionality to production affect the end clients?"
Can you ask them why they ask you this question insteaf of the product owner?