First he butters me up: “As one of my best managers, I thought I’d get some advice…”
Then he makes a genuine request for help: “… on how perhaps my company should structure one of their processes… in particular, team meetings”
I offer a snarky response: “Meetings suck. Avoid them.”
And then I get interrupted and can’t finish the IM conversation, so he thinks I’m a jerk.
This is what I would have said if I had thought it through.
The only meetings you need are the ones that help you meet your business goals. Your only true business goal is to make money. Your software engineering team is a constraint on your ability to meet your business goals; you need to do things to make your team efficient. The only meetings you need are the ones that address your software engineering team as a constraint on your organization’s ability to make money, the meetings that make your team more efficient.
Here are the specific meetings you need:
Daily greeting
This isn’t formal meeting, but it might be the most important meeting of the day. Be friendly! Make sure you talk to people when you don’t have a problem or complaint, so they won’t mind talking to you when you do bring trouble. If you train people that you talk to them only when you have a complaint or there’s a problem, then they’ll avoid you. Everyone should offer a friendly daily greeting to everyone they work work, every day, for at least a few minutes each.
Initial project planning meeting
At the beginning of your project, hold a project planning meeting. Discuss project goals and non-goals. Understand the known requirements. Prioritize the product backlog. Outline a plan with timeboxed milestones (sprints) marking a path to the end. Attendees include all the project’s stakeholders: the customer or a proxy, the product owner, the business team, the project manager or scrum master, and the project team members. Hold this meeting once, at the beginning of each project, for 2 to 8 hours, depending on your organization’s norms.
Sprint review and planning meeting
At the beginning of each sprint, plan the sprint. At the end of each sprint, review the sprint. What did you get done? What did you deliver to your customer? Demo your delivery to the stakeholders and to each other. Discuss what worked well and didn’t work well during the sprint. Review and amend your product backlog, and reprioritize it according to your business goals. Let the project team select and commit to completing a subset of the prioritized product backlog for the sprint backlog. Depending on your organization, sprint review and sprint planning can be two distinct meetings, each 2 to 8 hours long, or one combined meeting, 2 to 8 hours long.
Daily stand-up
You must talk to each other every day. The least efficient team members are the ones that never communicate with each other; the next least efficient team members are the ones that only send email to each other. Hold a regular meeting, at the same time, in the same place, every day, for 15 minutes or less. Call it a daily stand-up, a scrum, or whatever you want–my team currently calls it the Super Mega Stand Up. Review what you did since last time and what you plan to do until the next time. Talk about impediments to getting stuff done. Pay attention, and after the meeting, help each other remove the impediments. Don’t solve problems here–save that for a follow-up ad hoc problem solving meeting. If this meetings lasts more than 15 minutes, you are wasting people’s time, and your team isn’t getting stuff done.
Ad hoc problem solving
Got a problem? Talk to each other and solve it now. That’s right, talk to each other. Now. Don’t send email, wait, and complain about not getting a response. Talk, together, in real time, now, face to face if you can. You made a commitment to your team to get stuff done. Remove the impediment now so you can keep your commitment.
Scrum of scrums
I have internal customers–my boss, his boss, the board of directors–and external customers–the people paying us to build app’s for them. I hold regular scrums-of-scrums with them. I act as the scrum master for my teams, reporting what we did since last time, what we plan to do through next time, and our current impediments and plans for removing them. With my internal customers, this is a weekly one hour meeting. With my external customers, this is usually weekly, although it can be twice a week or daily, depending on the project. With external customers, the customer’s project manager attends, and he sometimes brings his boss or his team members with him. External scrums-of-scrums usually last up to 30 minutes.
One-on-one meet-up
You need to speak privately with your team members to see how they feel, make sure they are motivated, and make sure they understand the team’s short term and long term goals. How’s the family? How’s the dog? How is the project going? Is anything blocking you from getting stuff done? Are there any conflicts with other team members or stakeholders? Are you planning any vacation time? I hold a one-on-one meet-up with each team member for about 15 minutes, twice a month. Talk to each other in good times and in bad–if you only talk when something is going wrong, you’re the bad guy.
