You're asking a general question with a specific example. I'll try to respond to both.
I see several relevant points here:
- you are a scrum master
- you are new to the org
- you think this report is a waste of time
- the consumers of this report are...? (whether it's the team or the stakeholders might affect how you proceed)
The fact that you are an SM, rather than a member of a dev team, is the most significant circumstance with respect to "driving change on a peer-to-peer level". There are plenty of ways for a team member to drive change on a team: for instance, a senior dev could lean heavily on their experience; a highly opinionated and assertive dev could dominate the conversation; a data-oriented dev could dazzle with statistics; and there are more. But a scrum master has a different role, and therefore a different approach.
A scrum master's role is to coach the team towards improvement. As the saying goes, "I'm not here to answer your questions; I'm here to question your answers."
In fact, I would move away from the paradigm of "driving change": that sounds as if the devs are horses pulling a wagon, and you're holding the reins, driving in a different direction. I suggest instead "encouraging change", "motivating change", "wondering about change."
Now let me pause for a moment and take up point two: you're new to the org.
How are your team dynamics going? I would strongly suggest teambuilding and team formation as your first priority: because until you are at least somewhat accepted and trusted by your team as one of them, they are not going to be open to any change suggestions from you. Take a look at the Scrum values, and see how you're all doing with those.
Encouraging change as an SM takes patience, respect, collegiality, and more listening than talking.
Okay, now back to how you, as a scrum master that is well integrated with your team, can encourage change in an area in which you believe there is room for improved agility.
First, try to let go of the conviction that you are Right about this, and if your team would just Listen To You, they would understand and be persuaded. This is not a productive attitude to bring into a conversation that is exploratory, curious, or encouraging. (Believe me that I know how hard this is to do! ;) )
The retrospective is the canonical place to inspect the team's processes and procedures and identify actionable areas for improvement. As SM, you can design the retro to encourage reflection about the broad areas that you think this report falls into. For example:
make a chart with Effort on one axis and Value on the other. Have the team spend some time in silent writing on all the common activities they can think of, then place them roughly on the chart. Have a conversation if there is disagreement about where an item should go. Then look at the (high effort, low value) area of the board, and see if you can identify some things that could be moved in the direction of (low effort, high value) or even dropped altogether.
have a discussion about metrics and reporting, and identify what goes into each and what is driven by each. Have the team collaboratively draw charts to show this: some of them will likely be the standard scrum charts of inspect-adapt cycles, and some will be more locally specific things.
have a conversation about the past, present, and future of communicating with stakeholders -- involve your PO heavily in this. For every communication pattern or artifact in common use, tell the story of how we got here, and imagine where we might go in future to be more agile and provide more value.
Be open to whatever insights, questions, and changes might come out of these. Don't try to drive the conversation specifically to the outcome or even the specific topic that you want. If the team is especially engaged by one of these, repeat it a few times, either every sprint or interspersed with other approaches. I would let the team have a few of these before I brought up the specific report I was worried about, if they still hadn't.
One last thought: one approach that might be helpful in defusing this kind of pushback:
I know, that if you ask "Why do you need this report?", then the others will find a lot of reasons why they think the report is needed. The more I ask into the direction like "stop it", the more the others will think they need to defend what they did in the past.
is to try the "Five Whys" (https://en.wikipedia.org/wiki/5_Whys). I always introduce this with something like "I am not being deliberately obnoxious, this is a real technique." And instead of asking "why do you need this report", I would start with "why do we produce this report". (Always use "we" language!)
I hope this helps. Good luck!