The Agony of Silent Agile Meetings

Photo by Alexander Mils on Unsplash

Ever sat in a Sprint Retro where your Scrum Master didn’t show up? I just did. 

The resulting silence haunts me at night. It lasted for ten minutes and nobody said or did anything.

We sat in silence. I stared at the wall.

What’s Going On?

I know that I’m a developer (no friends, like ramen, and drink coffee) but I’m not completely socially inept.

So, I’ve been asking myself what went wrong, and what I can do better next time (and what the team can do better).

It’s like I’m doing a retro of the retro.

Social Pressure

The technical staff at our place never tend to talk in these meetings. That means there is social pressure not to. Want to be part of the in-group with us developers? 

Wear a hoodie, and keep your mouth shut. That’s the message I took during that particular retro and I think that I’m not the only one.

Forced Fun

This particular retro had a picture of an elephant and some prompts like “What will you never forget about this sprint”. 

I could contribute to one of my stories for the retro but it all feels like forced fun to me, and that’s not something I enjoy. The image of the elephant (with a smile on its face) wouldn’t make me enjoy or want to participate in a retro.

Even when they are calling our names in the retro they sometimes run through us in alphabetical order and sometimes in reverse alphabetical order. Neither of the options makes the process fun, and I’m shocked anyone would ever think it is.

This led to my silence, and when the meeting got going I just wrote no blockers on my post-it and was done with it.

Not Running the Meeting is Not Taking Part

This is about control. In the teams I work (and have worked in) the Scrum Master and Product Owner take control and run the meetings.

This naturally means that everyone (myself included) sits back in the meeting and lets it run. As we are referred to as resources this is perhaps a natural reaction to the dehumanization of being a software developer in 2024.

There is a model of performance where we work together and the team self-directs the meeting. This isn’t my experience of being a software developer and this certainly contributed to my silence in this particular meeting. I don’t think I’m the only one.

The Secret Developer’s Improvements

I’ve realized that my silence isn’t just a product of the meeting’s format or the social dynamics at play. I have a role in this, too. 

What can I do better next time? I know, I’ll make a list for use all and we can learn from it

Speak Up

Sometimes, just breaking the silence can help shift the dynamic. Even if it’s just a comment or question, it might encourage others to speak up, too. Anything other than the clack of a keyboard (and I’m usually writing blog posts in these meetings, remember I WFH).

Prepare Ahead of Time

Going into the meeting with a few points in mind can make it easier to contribute. Reflect on what went well, what didn’t, and what could be improved. Preparation can help overcome the inertia of silence. In the specific case above, I could have kicked off the meetings with some of my musings and started the discussion.

Challenge the Status Quo

If the meeting format isn’t working, I could have suggested alternatives. Maybe propose rotating who runs the meeting or introducing new, more engaging formats.

It’s a risk, but it could pay off. What if the other software developers boosted their engagement too? What if they saw me through a different lens?

I think I had nothing to lose with this one other than my own misery.

Find Allies to Change Things

I could talk to colleagues one-on-one to see if they feel the same way. If there are others who are also frustrated with the silence, we could band together to bring about change. 

There’s strength in numbers and making things better should be in the interest of everybody at the company.

What the Team Can Do Better Next Time

It’s not just on me. 

The team can do better too.

Here are a set of suggestions for my Scrum Master to look into. I’m not sure a public blog is the correct forum, but here are my ideas:

Create a Safe Environment

Make it clear that all contributions are valued and that there’s no such thing as a stupid question or comment. This can reduce the social pressure to stay silent.

Encourage Participation

The Scrum Master and Product Owner can actively encourage quieter team members to share their thoughts. This doesn’t mean putting them on the spot but rather creating openings for everyone to contribute.

Mix Up the Format

The same old meeting formats get stale. Try new approaches, like breaking into smaller groups for discussions or using different facilitation techniques. Anything that can break the monotony and make the meeting feel fresh.

Address the Elephant in the Room

If people aren’t participating, talk about it. Find out why and work together to find solutions. Ignoring the issue won’t make it go away.

Empower the Team

Shift from a top-down approach to a more collaborative one. Allow the team to take ownership of the meetings. When people feel they have a stake in the process, they’re more likely to engage.

Conclusion

This article should have been about why we have meetings when the most important attendees don’t want to be there and are not participating. 

If I could answer that I guess I wouldn’t be a software developer anymore, I’d be a manager. I can’t and I am not, so OK.