More Meetings, or fewer meetings?

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.

Simple heuristic: meetings must have a purpose and must focus. Focus on the purpose.

You keep on focusing until the purpose is achieved. Or a step significantly toward it.

There is no “time-boxing” in this way of thinking.

(Guess how thrilled I was when I saw Jeff Sutherland reducing those kind of meetings described in the Borland case to 15 minute “stand-ups”…)

Measuring the burden of meetings in terms of time consumed is a Cost Accounting mind frame. The objective is to advance the state of collective knowledge that the team develops; not a race against the clock.

If the situation requires staying in meeting-mode for 5 days straight - then be it. You will probably advance the state of knowledge by bounds (provided you keep the focus on the purpose); to a state that with all stand-ups and sprints might require weeks or months.

If the situation requires NO meetings, because the collective mind already knows what needs to be done, then we do not hold meetings at all; and we don’t pretend to be in the show business and entertain one another with rituals…

Simply… You stay in meeting-mode until everyone knows what to do next.

1 Like

You stay in meeting-mode until everyone knows what to do next.

My TameFlow pattern for the day.

1 Like

I like it that you qualify it as a pattern!

Compare that to some of the the industry standard [anti-]patterns:

  1. We will have a daily event if everyone already knows what to do!
  2. We will stop the standup after 15m, no matter what, even if nobody knows what to do!

No wonder why logical souls like programmers get distressed…

At this point I’m like a pig finding truffles :slight_smile:

1 Like