“Badger hates Society, and invitations, and dinner, and all that sort of thing.” - Kenneth Grahame, The Wind in the Willows
"Why are there so many meetings?" is a complaint a Scrum Master often hears, especially from team members who are new to agile practice. It's the refrain of those in an organization which is more likely to be doing agile rather than being agile. Unfortunately, the existing meetings and social constructs of a bureaucratic culture have a tendency to continue on regardless, and irrespective of how unproductive they are observed to be. Instead of embracing Scrum as an opportunity to rationalize and revise an entire way-of-working, the framework is more likely to be layered on top of a system already creaking under its own weight.
Of course, once the import and substance of Scrum and its events is understood properly, the supposed necessity of other "meetings" can be criticized and challenged. Gradually and by degrees they can be exposed and optimized away as waste, until a leaner and more agile process is all that remains. In fact a mature agile team will have little perception of any formal "meetings" taking place at all. Rather, there will simply be an appreciation of the opportunity to inspect and adapt. At some point during this long journey another refrain is commonly heard. "Who sends out the invites?"
The Scrum Guide is rightly silent on the issue of who sets up Scrum events in people's diaries, assuming they ought to be managed in such a way in the first place. It's a matter for a self-organizing team to take in hand. In practice though, teams do tend to operate in a context of provisioned services such as MS Outlook, Lotus Notes, and Google Calendar. Putting agile events in diaries can therefore be important, at least until such time as they become normed. A calendar entry sanctions these critical elements of the Scrum Framework, and gives them organizational visibility and weight.
Should it be the Scrum Master who sends out invitations? A good case can be made for this, on the grounds that it is likely to smooth and facilitate team progress, and allows team members to focus on the delivery of product value. Essentially the organization of events can be aligned to the Scrum Master role in terms of the servant-leadership function. Yet the devil is found in the details. A Scrum Master, whose skills are more aligned to the Scrum process than the development of a specific product, is perhaps somewhat more likely to "move on" than other team members. If you've ever contracted as a Scrum Master you may well have experienced the situation where events have been previously sent out from an account other than your own. Should any changes be needed, team members must then reject old meetings and accept the replacements emanating from your account instead.
What about a long-standing Development Team member? Sometimes people will default to having technical leads or senior developers send out meeting invitations, on the grounds that they are rather less likely to be moved out of the team. The problem is that this reinforces the notion that a particular developer, rather than being a peer, holds seniority and sway. Then again, it would be foolish to pretend that all developers are identically capable, and of equivalent value and experience. As the anchor and back-stop of a development effort, certain developers do tend to demonstrate greater longevity, since moving them on would indeed incur considerable risk. It's amazing how quickly a Product Owner can move when they suspect their "best" developer is about to be poached for somebody else's workstream. Hence there can be a temptation to be pragmatic and to make tactical use of such an individual's account.
What about the Product Owner though? Should that be the person who books Scrum events into diaries? Given that he or she ought to be in the Scrum Team for the entire lifecycle of the product, a strong case can also be made for this arrangement. The disadvantages however are clear. What if multiple teams are involved in the development of one product? What would the owner's calendar look like, where multiple and potentially overlapping events are in place for each contributing team? Moreover, is it really wise for the Product Owner to make arrangements for the Development Team's Daily Scrum?
In my experience, the best solution is to create an account for the whole Scrum Team and use that for sending out meeting invitations, as well as for wider enterprise-facing purposes. Remember that in an agile way-of-working each team ought have a clear and well-defined identity, and be a first-class organizational construct. Let each team self-organize who ought to have access to the team account at any given time. The problem with this approach is one of organizational gravity, since the idea will very likely fly against administrative convention and procedure. Hence there is additional value in the exercise, since it can tell you quite a bit about executive sponsorship for change.