Meetings outside Scrum ceremonies

There are going to be meetings outside of the defined Scrum events, you can't get around that. The key is to maximize the value of these meetings for the people who attend. Determine if meetings are the right way to convey the information and make sure that the right people are attending at the right time. I do find that considering the Sprint cadence is useful when considering outside meetings to make sure that they happen at times that are conducive for the team, even if they don't happen every single Sprint.

Without knowing the full list of meetings and what the purpose of each one is, I really can't provide much advice. One thing that does stand out is the bug triage meeting. This sounds like something that can fit into the Product Backlog Refinement activities, but I would need a much better understanding of how the team currently does Product Backlog Refinement.

 Are meetings outside the Scrum events a symptom of other issues (e.g. poor communication, a "meeting culture" in a workplace")?

In my experience the answer to that is "yes" to both of your "e.g" options.

One of the first thing that our Development Organization asked for as we started our Agile Transition was to reduce the number of meetings that they had to attend.  And even after starting some of them complained about having to attend the events.  One of the biggest reason was that past history was we had a lot of ineffective meetings because people didn't know how to communicate or facilitate meetings. We had meetings because no one knew any other way of talking.  Emails were ignored, Instant Messaging only included 1-2 other people. It was very much problems with knowing how to communicate.

For the rest of my comments I will use the word "meeting" to mean anything that isn't a prescribed Scrum Event. Here are a few things we did.

Look at the purpose of all the meetings.  You will probably find that many of them are now covered by events. 

For example, the bug triage meetings are now the domain of the Product Owner as it is to identify items that need to be in the Product Backlog and ordered appropriately.  So while the meeting may continue the PO should be the one attending and not the Development Team.

I am going to assume that the Team Meetings are actually meetings with the Manager responsible for the HR oversight so that they can communicate global company "things" easier.  Those meetings will probably still occur.  But as Scrum Masters, we all volunteered to attend some of the earlier meetings so that we could suggest ways to make the meetings more effective.  If I am wrong about the assumption and these are meetings of the Development Team per Scrum Team, then that meeting is now covered by the Daily Scrum, Review and Retrospective.  No real reason to keep having that one.We found that some of the "status" meetings we had could be replaced with widely distributed emails or spaces created on our Confluence server. We moved from a culture of 1 person deciding who needed to know the information to widely sharing and let the individuals decide what was relevant and applicable.  Take the Empirical pillar of Transparency to the extreme and overshare information in a way that people can go to it on their own time instead of trying to force-feed it on one person's schedule. 

We are still struggling with this 12 months after starting our transformation.  We still have areas outside of Development (i.e. Marketing, Sales, Operations) that continue to schedule meetings.  Our Scrum Master group has gotten pretty good at approaching the meeting organizers to help them understand if the meeting is needed or to offer assistance in facilitating them to be more effective. 

You have work ahead of you and it won't be fast.  Good luck.

I have asked the team and they feel they are in too many meetings but unsure what to do about it

Why are they unsure? Who is organizing these meetings, if it isn’t them or the Product Owner?

Thanks for the feedback Thomas, Daniel, Ian!

I also feel the bug triage meeting can be improved/eliminatated. Currently it's run by the test lead (outside the scrum team) and the development team attend and each bug is assessed and allocated. I feel this is against how Scrum works but that's a separate issue to address with the team.

Daniel - yes that is how the Team Meetings are currently run. I would prefer that we use a combination of emails and the existing Scrum events, but of course that's not my call. Glad to hear it has worked for you.

Ian - Perhaps they are unsure because they are so used to it, or are not comfortable speaking up and asking "why is this meeting needed?". But I can find out. I think the meetings are organised by a range of people - the development team leader, test lead, other developers, even myself.

These responses have been very helpful! I'll bring this up at the next retro and see how it goes.

Currently it's run by the test lead (outside the scrum team) and the development team attend and each bug is assessed and allocated.

Allocated to whom? Developers / teams / Product Owners?

Each of these could be a sign of an underlying problem. For instance, in my company we only recently managed to get rid of bug triage. The underlying problem that we believe we had was a lack of clear product definitions, despite having two teams, each with their own Product Owner and Product Backlog.

We had been using bug triage as a way to work out which backlog a bug should be on, because otherwise they would be assigned arbitrarily.

Allocated to whom? Developers / teams / Product Owners?

In short, the developers. The current "Bug Triage" meeting involves the Test Lead bringing up all of the outstanding bugs, asking the developers where it's at and what has been done on it, allocating bugs to developers to work on.

I understand this is not an ideal way to work for several reasons (no PO involvement, adding more work to the sprint, assigning work to developers rather than them self-organising). It's something I'll be bringing up with the team during one of the upcoming retrospectives, but I feel it may take some convincing as it's something they have done for a while.

Simon - glad to hear you eliminated your bug triage meetings and found the underlying problem.

Apologies if my understanding is incorrect, but are additional sprint items (bugs) being pushed to the Development Team mid-sprint through these bug triage meeting?

If so, there are a couple of issues with this from a Scrum standpoint.

• Work should never be "pushed" to a Development Team mid-sprint.   From the Scrum Guide:

"Only the Development Team can assess what it can accomplish over the upcoming Sprint... Only the Development Team can change its Sprint Backlog during a Sprint"

• How can the Development Team reliably meet their Sprint Goal and forecast, if others outside the team are allowed to add to that forecast, basically asking the Development Team to hit a moving target?