I enjoyed reading–> At Borland, the frequency and intensity of meetings was astounding. These meetings could go on for several hours and the majority of the team members’ time was spent in such meetings. The meetings were far from being ineffective; instead, they productively led to better communication and built a shared vision (Coplien, 2004). During those meetings the team kept on improving the architecture and the code, but they also kept improving the process itself. Gabriel (1996) described his surprise in finding that the QPW team had such meetings almost every day, and that they could last several hours. They were not light meetings; they were not about planning and good intentions, but about highly technical issues like architecture, interfaces, algorithms, data structures, and other technical topics. Unlike most meetings in other companies, these meetings were not counterproductive, and absolutely not about protecting turf and seeking credits for results. The more important effect of these frequent and long meetings was to give everyone an understanding of all changes that were happening or being contemplated. After the meeting, all engineers could go off and quickly take care of their part of implementation to support the decisions that had been made, which in turn led to quick validation or rejection of any new idea. Furthermore, this open process made architecture a first-class artifact of the whole development effort—effectively leading to its continuous improvement and extension. The interactions between all members ensued that everyone was aware of what all others were doing, and in particular anybody could understand how their own efforts were contributing to the larger picture. The intensity and depth of conversation gave rise to rich communication patterns between all components of the team.
Tendon, Steve; Muller, Wolfram. Hyper-Productive Knowledge Work Performance (The Tameflow Hyper-productivity) (pp. 22-23). J. Ross Publishing. Kindle Edition.
but I also remember that I like the section about how it was not necessary to hold “ritual” meetings, that teams should only hold meetings when it was necessary to improve the flow of a work item or deal with problems around the constraint (sorry, can’t find the exact quote)
This is probably related to how the idea of a MOVE or a work item is defined. The first quote clearly demonstrates that almost any work a team member is doing impacts or is impacted by the work that all the rest of the team members are doing. Which makes it clear to me that work items are not “tasks”. Kanban meetings I have been in have been all about “tasks”.
So I guess that “don’t hold ritual meetings” is an anti-pattern. And “meet whenever the team needs to deepen their mutual understanding of the project” would be the pattern." Most situations I’ve been in meetings were clearly seen as a “cost” and everyone wanted to avoid them as much as possible.
