Well Met: the Software Engineering Meetings You Actually Need
Nobody likes poorly run meetings OR too many meetings. A well-crafted set of well-defined meetings, though, can make a software engineering team more efficient by ensuring that they build the right thing at the right time.
You don't need all of these all the time. You do need some of them all the time. Trying to deploy them all at once into an existing team is going to hurt; try adding them in over weeks or months to get the benefit without the risk of open revolt.
The regular team retrospective is how your team gets better; therefore, it's the most important regular meeting your team has. There are lots of retrospective processes; we've had success with one inspired by the UK Digital Service that is very structured and takes 90 minutes. To start, schedule these every two weeks (Thursday afternoons are a pretty good time) until the retrospective gets boring and empty. Usually a team just starting to do retrospectives has a lot of ideas for improvement, so this can take a while. This is Totally OK™; you're investing 90 minutes every two weeks to improve your team.
Regardless of the process, the output of the retrospective are a set of actions that are to be completed by the next retrospective with the goal of improving the team on any axis. Any improvement here is good; even a small thing like "Mark will ask facilities if we can have the lights not turn off at 5 PM" starts to teach the team that they can make useful changes.
Once you're up and running and things are going smoothly, you'll end up with a retro every four to eight weeks, depending on how much change is happening around your team.
Everyone on the team should attend the retrospective regardless of the nature of their role.
Interval planning (also called sprint planning) is how your team decides what it's going to do on a week-by-week basis. This is where the team accepts work from the inbox, points and schedules work on their backlog, gets business context from their lead and/or manager, and sets up their goals for the interval. There are a lot of ways to run interval planning; I like to start with a general overview/news for the week, followed by a run-through of any work in progress, followed by inbox processing until it's empty or the hour is up.
Truss believes strongly in a one-week interval and generally finds that higher-performing teams operate on a one or two-week interval.
Interval planning should happen once per week for one hour; 1 PM on Monday is an excellent time for it, as it gives you the morning to react to anything that's happened over the weekend.
Everyone on the team should attend interval planning.
This is a 15 minute meeting that happens once per working day, designed to raise blocking issues and allow for tactical planning (Person A: "I'm going to work on Redshift today." Person B: "Cool, I can help you with that because I'm going to be blocked on Redshift tomorrow.").
This meeting isn't required. It's extremely useful with new teams (so folks get used to how to report progress and catch missed expectations early) and with crisis scenarios (when the lay of the land is constantly changing, so a weekly check-in cadence isn't viable). If your team is formed up and running well, you can drop this meeting and reclaim about an hour per week per person of engineering time.
11:45 AM for 15 minutes is ideal; butting it up against lunch means that it's unlikely to run long, and having it at midday means that folks who might have been up late dealing with a crisis are more able to make it.
Everyone on the team should attend the daily standup.
1:1 between staff and manager
Every person on the team should have a scheduled, one-hour meeting with their manager that happens at least every two weeks. 10 AM is a good time for this. This is not a status meeting; this is for staff to have time with their manager to discuss problems, planning, career progress, and other issues. The staff owns the meeting and runs the agenda.
Only the manager and the staff member should attend.
Sometimes you find that you have too much work in your inbox and you run out of time in your interval planning meeting. In this case, it can be useful to have a couple of team members spend a little time going through the inbox in advance of the interval meeting and make sure that the stories are understandable, that the stories have any hope of being accepted by the team, and that they are applicable to the team.
When starting, the scrub should be handled by the team lead or manager and one of the senior members of the team. Once the team has matured, having a rotation of senior and junior folks in pairs is a great way to train up junior folks and spread the load out more evenly. In some cases, it can be useful to have the team manager, a senior engineer, and a junior engineer in the room, and that's as large as it should get. Most of the stories should still be accepted or rejected by the team as a whole.
Monday mornings are a good time for this meeting. If you find yourself finishing your interval planning with nothing left in your inbox, you don't need this meeting. If you find yourself with stories in the inbox even with this meeting, you need to reject more work or hire more staff.
This can be a useful adjunct to the interval planning meeting. In it, you take the longer term priorities of the project/team and make sure that the next interval lines up with them, and, if not, make adjustments. This needs to be the team manager and some senior staff; junior folks can audit the meeting for training.
If you have very clear team goals that don't change very often, you may not need this meeting.
One hour, scheduled near the end of your interval.
Brainstorm / design doc / decision trio
When the next task on the team's list is "figure out what the hell we're going to do to solve this problem", this is a good tool.
Call a brainstorm meeting: anybody on the team who's "involved" should attend with the goal of getting as many options on the table as possible. The person who's "committed" collects the results and generates a design document. Design docs do not need to be formal; a quick Google Doc that says "We thought about problem X, we decided solution Y makes sense for these reasons. We considered Z, Z', Z'' solutions and found them wanting for these reasons, so we're going to do Y. Here's how we will do Y." is fine.
Once the design doc is finished, it should be sent to the team (at the very least — some orgs have a design doc review group of senior staff as well) and a deadline provided for feedback.
Once feedback has been collected, the author of the design doc should integrate it into their design and re-send the final doc to the team and schedule a decision meeting with the team as soon as possible (ideally the following day).
In the decision meeting, the design doc is assumed to have already been read by the team members, and the team chooses to either accept the proposed design, accept one of the alternatives, or reject the design and start over.