Teams raised frequent organizational events as impediment

One suggestion based on a similar situation I've worked through, is to create a measurement of the impact to influence meaningful change to the organization.

For example, we created a mechanism within the team for them to log time spent attending non-team events and separately a yes/no field if they contributed as well as a yes/no field if this broke productivity. It's not to identify if they were required or not, but if their attendance made contributions to support other teams, and if there was potential of scheduling things better.

We emphasized the amount of trust required from everyone to provide real data and not just put no for contribution and yes for productivity impact just to get out of going.

When we were done, each Sprint was able to add to the trending measurement about the impact as a whole and separately as productivity impacts. We learned that 1-2 people most often contributed, and as most meetings didn't need full team participation, certain meetings were scheduled in morning half of the day and with fewer folks from the team acting as delegates only supporting the PO as requested by the PO. 

It created awareness of the responsibility to meeting holders that other people's time is precious and to treat them as people not resources. Hope that helps!

Why is an impediment? To be solved by the SM? If they do not think it is relevant for them, is it not possible for the team to bring this to the organization by, for example, talk to higher management?

Maybe it is a vital opportunity for the organization to learn from the team what they deem relevant and valueable, and for the team to learn why the organization is keen on them joining.

What are these events and how often are they? I've had teams where they complain that there are too many events (such as your teams are saying) and label them the culprit for not delivering work but in reality it was just an excuse. 

Say that the teams are working in 2 week sprints and the organization schedules a big company event for 4 hours on a Thursday of the sprint; I'd just encourage my team to take on less work in Sprint Planning. I'd be surprised if the organization has mandatory events on a daily or even weekly cadence that is taking the team's focus away.

As for the Photo-Ops, why are they feeling that they must go along? Do they not feel empowered to say "thanks but I need to focus on this and I really don't want to participate in being photographed."

Is it possible that others see value in developers attending such events?

If there is genuine business value in having the whole organization attend the events, maybe this needs to be communicated better to the developers.

If it's wasteful, perhaps colleagues will appreciate the feedback from developers who genuinely want to deliver more value for the organization.

Rephrased, I've been in situations where Development Team members have expressed frustration with having to attend too many meetings where their input wasn't needed and where they weren't sure how to add value. I like to keep business simple. Which is why I like Scrum. In such situations, I have gone to the executive I am advising and have honestly stated my opinion that it is far more valuable to have Development Team members working on "delivering a potentially releasable Increment of "Done" product at the end of each Sprint" (Scrum Guide) rather than attending pointless meetings. Personally, I get more done over adhoc phone calls, drop-ins and hallway conversations than I do in hour-long meetings. Beware of the "look busy" professionals.

Every client is different. Every situation is different. I believe in open, honest and constant in-person communication. And I always value, and encourage, real, tangible product development work over theorizing, strategizing, designing and writing. But that's just my opinion.

rather than attending pointless meetings.

Useful work is more valuable than pointless work. Everyone already agrees on that.

How do you find out which is a better use of the team's time, and how do you do so in a way that aligns everyone on those insights?

I look at this almost like attending a big family event that you don't reeeeeally want to go to but you know others will appreciate it if you attend. 

Not everyone wants to be recognized in photo-ops, luncheons, or team building events. I've seen developers who didn't want to be a part of those type of things and was labeled as not a team player, however, the opposite was true. When working on the actual Scrum Team they were always helping out junior members, stepping up when needed, and helping to lead the team. 

It's important for organizational leadership to understand the type of praise each individual prefers and help to mitigate the amount of 'non work related' work events that employees may have to attend. Forcing moral building activities down someone's throat when they don't have a moral problem could well...hurt moral. 

"Frequent non-functional events mandated by the organization are impacting the work".

Do those in the organization who are "mandating" these events understand which of their interactions with the Scrum Team are helpful and which aren’t?

Thank you all for your valuable inputs. I appreciate all the comments which made me think on a different note. 

Here are a few clarifications that I feel I must provide. 

1) The events that I mentioned are not meetings with any agreed agenda. I prefer to call them social events. Certain events I cannot even mention on this forum since it is politically incorrect to do so. The frequency of such events at least once every week lasting for up to 3-4 hours. However, we have had open, respectful discussions within our teams regarding the value of such events. It is the reality of the current workplace hence teams are trying to find a solution without getting chastised for their refusal in participation in some of these events. As a Scrum Master I sincerely feel that I should assume a facilitator role or even a leadership role if required to address their concerns. 

2) The organization operates in a market with significantly high regulations. Sign-offs are a common practice of this industry. This tendency has trickled down to all departments, portfolios, and work-functions. Fortunately, software development has eliminated this practice over the period and is quite independent with respect to its work. However, HR still sends memos every now and then, mandating that we follow the signoffs and attend the "mandated" events. Other divisions of the organization already discussed this "lack of sign-off" structure/practice and there is a sentiment in them that software development has "superiority complex".   

Keeping in mind, the nature of the issue, I feel that I must prepare the ground the right way to break the impasse that we have had in the past. As @ Curtis suggested, the team has done exceptionally well to adjust the workflow on their own in situations where they could not "get out" of these events. However, the focus is lost at least in parts when these adjustments are made.

@John Varela II, I agree that in order to effectively visualize and address the underlying issue it will be great to have measurement and benchmark for impact analysis. We as a team have taken that up the day you mentioned it here on the forum. Our biggest challenge remains to understand the impact or value our participation brings in the team and in the organization overall. The PO, I and our integration team will be exploring this aspect. Development teams have principally agreed to join in on later stages. 

@ Xander, I agree that the next sensible steps to do would be to talk to higher management. Though we have support within the software dev. division, it is unsure whether we will get complete cooperation from others. The PO has started the discussion with VP to explore level of acceptance and willingness of other depts. to understand our practices. 

@Simon, we have had discussions/ rounds of discussions to understand the value our teams bring to these events. However, the general sense is that the value we bring by working with the product currently outweighs the value we get out of these events. It is a mismatched trade-off according to the teams. The teams have escalated this as an impediment when this acquired quite a significant rating on their individual risk-management metrics (The issue related to this appeared multiple times with individual team within last few sprints, though it was not discussed/or raised in the part one of the Nexus Retrospective). Now, that it has been raised, we have initiated complete discovery to this issue.  

@Tony, Bang on analogy. Some events are exactly those morale-building activities. 

@ Ian, Perhaps this is where even we (software dev.) have less visibility. With the current information that we have gathered, it is possible that they think that we follow the same work-flow and practices and see nothing unusual in mandating such things.

There is a sense in software division that perhaps this is the right opportunity for us to showcase our development practices that have removed the signoff culture and assumes collective responsibility. 

Here is what we are doing, the PO is exploring whether if we can find a right sponsor who can communicate this situation horizontally across the organization and measure the sentiment. Meanwhile, I am also exploring whether I can conduct seminars with other SMs for those who volunteer, to communicate Scrum values and demonstrate how Dev. teams have evolved with those values.

Any other suggestions are still welcome!    

With the current information that we have gathered, it is possible that they think that we follow the same work-flow and practices and see nothing unusual in mandating such things.

As Scrum Master, what can you do to improve on this particular situation?

The Scrum Guide says:

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

@Ian, Definitely. I am exploring this aspect in much more detail.

Previously, the dev. teams requested to handle this situation on case by case basis own their own. It was helpful for them to understand organization in more detail. Many team members are relatively new to the organization. 

As I mentioned in the previous update, I have started escalating this on higher levels.     I intend to engage with them by introducing them to Scrum and the values and more importantly identifying specific interactions that are helpful and in line with our product and vision to those which are not. I admit, that previously I had less direct interaction with them specifically in this regard. I am sure, I have some more things to learn and widen the scope.