I'm a team leader of a team of 8 programmers in a company of about 20 technical people. They're working on a range of projects, these projects also involve people from other teams that are outside of my control. My organisation is not doing proper agile development, and they're somewhat resistant to change, but I've been holding daily stand up meetings within my team and we've all been finding them useful and everyone is engaged and we're done within 10-15 minutes. I also have weekly individual catch ups with every team member where we discuss various general topics (both technical and non-technical) in more detail, as well as various ad-hoc topical meetings.
What I've been struggling with, however, is my weekly team meeting. It is losing steam and I have not been able to keep people interested.
I still want to hold a longer meeting, even if it has to be fortnightly or monthly. The purpose was to discuss various topics that cannot be done during a stand up meeting because they require more time. Updates from me include a summary on every current project that they're working on (whether it is on schedule, various delays, etc), any changes in direction, future projects, changes to development process, etc. However, it ends up being a lecture from me, and at least 2 people are obviously zoned out and the rest are at most mildly interested.
I tried getting people to be more engaged by getting them to talk about their week, but with 8 people it takes a long time and (partly because a lot of their work does not cross over all that much), most of the rest team does not care what their co-workers have been working on in more detail (they get a high level overview during stand ups).
So, during these meetings, at least some people are very bored, and it is almost embarrassing for me to keep holding these. It is a stark contrast to our energised morning stand up meetings.
Any advice on what I can do to keep people more engaged and more interested? And how can I get them to present things on their or start discussions that involve everyone instead of it being a monologue from me?
Best Answer
You said that the meetings feel like you are lecturing them. If it feels that way to you, and the team doesn't seem interested in what you have to say, then why still have the meeting? If you're just throwing information at them, and it isn't holding their attention, why not just summarize everything in a weekly email instead?
If you want to make use of that hour you have with the whole team, you may want to consider running a retrospective. You can introduce the retrospective with simple honesty on your part: tell them that you don't feel the previous meetings have been productive and that you want to try something different to help everyone to benefit from the hour they have together.
In retros where I work, we will have three columns on a whiteboard, usually putting a smiley, meh, and sad face at the top, e.g.
:),:|, and:(. Then the team members get to put anything on the board that they would like to talk about with the whole group.In the happy column, you can celebrate successes (like congratulating Alice and Bob on the release of a project they worked on together), and you can declare victory with new processes you're trying (like the new bug tracker is much better than the old one).
In the meh column, you put things that aren't exactly happy or sad for the week. Maybe you purchased licenses for the new version of your IDE, and somebody hasn't seen any advantages of the new IDE -- they could put that on the board to figure out if everyone else feels like the upgrade was worthless or if other people have found ways that it is actually superior to the previous version.
In the sad column, you put things that haven't gone well for the week. Identifying the pain points for the week is probably the biggest benefit of a retrospective in my opinion. The whole team gets to discuss solutions to a real problem. On teams that all work on a single codebase for instance, someone might say that the FooBar class is unmaintainable and has been the cause of hours of debugging. Suddenly you find out that everyone else on the team has also lost multiple hours this week to FooBar, but nobody spent any time to clean it up. In that case, the team may collectively decide it makes sense for someone to spend time refactoring that code next week.
After everyone writes their proposed topics on the board, I like to briefly go over each topic and have its author give a 10-30 second explanation of the topic. This section of the meeting is easy to derail, so you'll have to be careful to keep people on topic -- e.g. someone will say that X has been a problem, and someone else starts talking about a solution to the problem; solutions shouldn't be discussed until after voting. In introducing the topics, you may find ways to group together multiple, closely related topics.
After the introductions, everyone gets three votes that they can distribute among the topics however they see fit. Finally, the votes are tallied, and whichever topics have the greatest number of votes is what the team discusses. For each topic, determine if there is an action that needs to be taken. Celebrating a success usually doesn't have an action item, but refactoring specific code can be assigned to one person. The action items should usually be completable by one person, but sometimes they are "whole-team" action items such as being mindful of having good commit messages.
Most retros tend to focus on topics in the sad column, and virtually no retros discuss everything that's written on the board. The meeting tends to finish whenever time is up. Immediately after the meeting, see that the action items are assigned to specific people; do this in whichever way makes sense for your organization.
I've had great success with retrospectives. They are a great way to build cohesion in a team, and they're a great way to reflect on the previous week and to refine your process. I think that if you try these out with your team, they will be much more engaged for your meetings.