Why have group meetings in software development?

Why have group meetings in software development? I think there are only three good reasons.

The first good reason is when several people need to come to a consensus. The outcome of these meetings are decisions. Ideally, everyone comes to the meeting prepared for the discussion. I like for a proposal to be written and distributed before the meeting. This means that at least one person has thought through the decision's context and ramifications, and that the meeting's participants have time to read and ponder it beforehand. Jeff Bezos has an interesting workaround to unprepared participants and that is to have meetings start with several minutes dedicated to reading the prepared materials. That Inc. article has several other good tips. I can't help myself and so must include a reference to Tufte's The Cognitive Style of PowerPoint. Thankfully, slide decks have been mostly absent from my last several years of professional work.

The second good meeting is the daily standup. It is too easy for a developer to not ask for help soon enough, and standups quickly stop that situation from worsening or the developer going dark. My manager at Cadre used a system of green, yellow, and red work status. If the work was going well then it was green. When there were complications the work was yellow. When it was red it was blocked. It is useful to use this system even in a standup. The first part of the standup has all participants give a brief status. The second part deals with yellow statuses with a brief description of problem and assignment of who is best able to help. Red statuses are dealt with outside of the standup. In all cases, however, don't solve problems in the standup. Giving solutions might not derail the standup the first few times, but has been my experience that by not maintaining the standup's principles it will soon devolve into a group chat and finally abandonment.

The third good meeting is for celebration. I am most interested in celebrating the group's achievement as a whole. Generally, everyone contributes as they are asked and as they are able, and so I see no need to single out individual contributions. The one exception is for someone who has shown marked growth. Pizza in the conference room can work, but you will have more success if you take everyone out to lunch.

Update: The TechCrunch article "Distributed teams are rewriting the rules of office(less) politics" had the link to Amazon's "narratively structured six-page memos."