Get away from status meeting
Hello Community,
I would like some feedback and some tactical ways to approach this situation.
We have a regular status meeting which includes senior product managers and scrum masters. Scrum masters help the organization with roadmapping so the organization is dependent on them providing statuses. We provide the "how" while the product owners are stating what needs to be worked on.
"Everything related to the direction, SCHEDULE and budget of the product falls into the product owner's job because the product owner makes the business decisions that impact these aspects of the products" is not exactly true here. The whole organization is open to learning and doing things under a new light. My manager who is the director of delivery has asked me to come up with ideas that they can keep a track of what's going on. There are features and projects which have a very high stake. It is difficult for me as I relay on a lot of what the product owner tells me to the senior product management team.
All in all, we are looking for a way to report any risks that are coming up. We want to understand how it is impacting the product. We want to know if we are going to be delivering on time etc. As a scrum master, I am not a project manager so I am not able to provide project manager details. How should I approach this situation?
The most effective way to inspect and adapt in lean and agile practice is as closely as possible to the time and place of work being carried out. In other words, those who make the decisions and act upon them are the ones who do the work.
The role of management is to facilitate organizational agility and to remove obstacles to it. I'd suggest that if senior leadership were pro-actively doing that, they'd receive the bottom-up intelligence they need for their own decision making. They'd be using evidence based management and would not expect to be fed with reports that are subject to filtering and delay.
It seems that management are in such a rarified and stratified atmosphere that they look to others to report "status". They have contextualized you, falsely, as another reporting agent within the established hierarchy. That's why you're in the quandary you're in, and I'd suggest that's the problem which a Scrum Master really ought to challenge.
When you say "regular status meeting", is this one of the Scrum events? If so, which one? Generally, I've found that the Scrum events can replace a lot of other types of meetings and activities. For example, a well-ordered and refined Product Backlog by itself can serve as a very useful roadmap and the Sprint Review is a good place and time for the Scrum Team(s) and key stakeholders to update the Product Backlog and understand what's coming next, along with sharing updates that will affect schedule and budget or to share potential risks and mitigations.
It's also not clear what you mean by the Scrum Masters "providing the 'how'". That makes it seem like at least some aspects of project management are shifted to the same people who are fulfilling the Scrum Master role. That's not necessarily a bad thing, but that aspect is beyond the standard role of Scrum Master.
What types of risks are you most interested in identifying and sharing? Iterative and incremental development methodologies inherently mitigate some classes of risk, while others still need to be identified and managed independently. The Scrum framework also has specific characteristics that mitigate other classes of risks. I've found that talking about risks, in the most general sense, isn't very useful. It's more useful to talk about specific risks, or at least specific classes of risks, and getting into how the development methodology either mitigates or supports the mitigation of those risks.