On Advocacy
Scrum needs a champion in order for an org and the scrum team(s) to adopt the values, artifacts and practices.
On paper, the Scrum Master fills this role. The Scrum Master can be empowered to facilitate advocacy, education, and process review sessions to both the Scrum Team as well as those outside the scrum team - stakeholders, C-Suite folks, other teams, etc. In the scrum framework, these sessions might fit easily into the sprint retrospective.
Advocacy for the Scrum Team
The Developers don't need to focus on details of Scrum. Developers focus is to develop. Scrum is the framework to enable the work of the Develops to be done incrementally and to produce smaller low-risk bits of value in exchange for longer-waited-for riskier releases.
Scrum as the empowerment tool for devs
For developers, scrum is an empowering process framework for devs to do what they do best. In a SaaS org, this means build software.
Artifacts that Empower
The Sprint Goal keeps a "bigger goal" in mind. Devs can come up with all kinds of hopeful improvements, re-writes, and enhancements, and the sprint goal can be the "north star" that the devs refer to when debating about when & how to implement code changes in regards to the business-friendly goals of the sprint.
The Sprint Backlog keeps the work in focus. Devs can use this list to protect their efforts from over-work, misguided expectations.
The Scrum Guide is readily available for folks in the team who might be curious about the process.
The Definition of Done is an agreed-upon set of expectations that the team can lean together. This can be used to be a guide for agreeing on work for a sprint - "will this be able to meet the definition of done by the end of sprint?". This can be used to be a guide for timeline estimations - "How long will it take us to take this business goal and make it meet our definition of done?".
The Increment is a tangible "done" part of work that devs should be proud of.
Events that Empower
Some of the goals of these meetings might happen outside of the prescribed scheduling of the meetings.
Making these events scheduled ensures that the goals of each event have a place in the ongoing rhythm of the team.
The Sprint identifies scope-creep, a complication that devs are familiar with. The Sprint is a process reminder that the whole world does not beed to be fixed, or updated, or or built within a few weeks.
Sprint Planning carves out some specific space to translate business needs & priorities to the devs. This reserves non-dev efforts to a small part of the devs work, making the super majority of dev time directed toward developing software.
Sprint Review is the feedback loop where the dev efforts are shown back to others. Sprint Review reminds devs that their after putting their heads down and updating code logic, that their work matters to the broader org and to the consumer(s) of the product(s).
The Daily Scrum is for the devs to have a formal touch-point to communicate where everyone is at in regards to the Goal of the Sprint. The daily meeting can be a place where extroverts shine. The daily meeting can be the place where introverts are sharing pre-planned communication points to the team.
The Sprint Retrospective is the team-reflection where devs can figure out how they can work as team better and also celebrate jobs well done. Having this space reserved can keep the whole team involved.