I'm working on a project having planning meetings at the start of every sprint. Three teams are involved on every planning meeting, reviewing pending/todo issues team by team (every issue is estimated).
Some members have requested to conduct separate meetings, one per team, to not lose much time.
Initially, it was proposed to make meetings together because sometimes there are dependencies between teams.
What would you advise me to conduct these meetings?
Thanks!
It is not recommended to have planning meetings with multiple teams together. With such a large number of people, team members won't be able to pay attention, as you are finding out. For coordinating cross-team dependencies, you can have separate scrum of scrum meetings. Please see more on this from Mike Cohn:
I was in a similar situation a couple of years ago. We had a large meeting, because we thought that it was the best way to solve dependencies. We observed that most of the participants weren't listening, because the discussion was irrelevant to them.
As a solution, we kept the meetings in the same time but at different places, near to each other. So when a dependency problem came up, we sent a message to the other team saying that we would go over in 5 minutes and discuss it. They had time to finish what they were doing, and be ready for the next discussion. It really worked. I'm not with those teams anymore, but as far as I know they still do the meetings in this fashion.
You may need to amend the scope of your meetings so that they are more efficient. One approach would be to have a series of smaller meetings:
Taking this approach has the advantage of reducing meeting time for lower-level team members (the doers), helps keep high-level and low-level discussions at the level they should be at, clearly delegates authority and responsibility to the key team leaders, and keeps the number of voices in a room to a level where they can all be heard.
I am currently looking after three projects; A, B, and C, which solutions are being developed by three different teams as follows:
Our sprints are 3/4 weeks long commencing at the same time for all projects.
Projects A and B have several dependencies of Project C. Likewise, Project C has dependencies of both Projects A and B.
At the beginning of the sprint I set up three sprint planning sessions, one per project/team. These sessions are shorter in time, never longer than a 1h, and are focused on what needs to be delivered in order to achieve the goals of the increment.
During the session, we identify and raise any dependencies that we have with the other projects which I collate in a Sprint RAID Log. In this document I highlight the dependency and team working in that area.
The same meeting process occurs for every other project/team.
At the end of that day, I have good visibility of the correlation and dependencies among these projects, so the following day I set up a 30 min RAID review session with the parties involved to run through these dependencies and agree a mitigation plan (some actions may be taken during the current sprint or may be considered for later phases of the project).
The key aspect here is that by the time we have the RAID review, the following day after individual sprint planning sessions, each team (solution developers, testers, Product Owners, and myself as PM) knows what they are working towards so we can discuss how to they are going to work to resolve these dependencies in a more efficient manner.
From my selfish point of view, running three separate sessions with the teams the same day is quite tiring however, from a practical perspective, shorter individual sessions (instead of 2-3 hour meeting) keeps the team focused preventing them from context switching which, at some point, exhausts them impacting their concentration and attention to the conversation. In the end this increases the risk of misunderstandings and the need for further meetings throughout the sprint (wasting more time).
If the goal is to reduce meeting planning time, then hold a single meeting and timebox it. A single one hour meeting fits the goal better than three one hour meetings.
However the question text hints that there may be more constraints on the goal. I think the answers provided by others are correct, but if I were in your shoes, I would hold three meetings and include three mandatory agenda items for each meeting:
I'd also schedule additional ad hoc meetings to reconcile any dependency that isn't reconciled immediately. (that is to say if Team X proposes to team Y that there X.1.3.4 is a dependency on Y.2.5, and Team Y doesn't resolve that dependency satisfactorily the first time it is considered then schedule an ad hoc meeting with all the players needed to resolve the problem.)
As with most questions, the answer is "it depends". So a couple of questions -
You need to look at each of the above questions in relation to YOUR situation and decide from there.
Have there been dependency/coordination issues in the past? Then they need to attend. And they need to understand why.
Is information reliably relayed by one or two people? then just have those people attend and leave the rest of the team to keep working.
And one more option would be tell the team you're changing, but ONLY on a trail basis. If issues appear then you're going back to the full team meetings.
It's always wise to prepare for hosting a meeting with a planned itinery list of the things that need to be discussed in order of priority. These can be ticked off once discussed but also recorded what was said. Having an assistant or work partner present to write down what was said helps, or if you don't have an assistant / work partner available then it may be a good idea to carry a digital voice recorder as an aid to memory to refer back to.
Having an intinery list of things to discuss means you keep to the topic and can speed through, but always remember you are in control of the meeting and can interject to stop topics from venturing away onto other tangents. This is good for time management to ensure meetings don't run into overyime or off topic.
