Skip to main content

Excitingly Well Run Meetings

The group of people huddled together in a room “until the job is done” is often used as a demonstration of virtues like “diligence” and “commitment.” And these scenes are often the stuff of dramatic moments in popular culture. We rarely, if ever, see any effusive praise for the well-run meeting that ends on time with a useful outcome. The former is more compelling. The latter is often more valuable and much harder to do. And while there are times that the former is the right thing to do, more often than not, it’s an indication of a problem. Well run meetings are useful meetings.
While it seems a bit pedantic to talk about meetings and schedules, and teams often present a ‘meeting-free culture’ as an ideal, the reality is that software development is a collaborative activity and we need to interact with (or “meet”) with people. When you need collaborate with more than a couple of people — perhaps from different teams — scheduling a meeting is inevitable. People have other commitments and time constraints, and respecting these commitments is good for the organization and the individuals.


There are many reasons for keeping a meeting on schedule. Starting late or ending late, wastes people’s time, which has a financial cost. But the primary reason keeping to schedule from perspective its it is respectful, and not honoring a schedule shows a lack of respect. By starting or arriving late you are disrespectful to the attendees who might be on time, by not ending on schedule you are being disrespectful to anyone the attendee was supposed to meet after a meeting and anyone who needs the room (or other resources) you are using. Of course, it is OK to you extend a discussion by mutual agreement, but you also need to agree on the basic ground rules.

Meeting Principles and Protocols

There is much written about good meeting structure and facilitation, and if you are in a role where you need to collaborate with people (as most of us are) it’s worth the effort to learn a bit about the subject. An effective meeting has, at minimum, two things: a reason, and a schedule.

A Reason

In general, a meeting worth having should have:
  • A reason, which attendees understand.
  • A goal, which you can decide if you have met or not.
  • An agenda, to help everyone understand if they are on track.
  • Attendees who understand why they are there.
  • A start and end time that is sufficient to have the discussion you need, and which allows for people to meet their next commitment.
All of these items can have more or less definition depending on the culture of the team, and the nature of a problem, and how close you are to having a common baseline of understanding. A Sprint Planning Meeting might have a more well defined reason, goal, and agenda, than an “explore design options” meeting. But it is important to be able to express these things.

Start Times and End Times

It’s easy to think of meetings as being (say) 1 hour long, starting and ending at hour boundaries. This makes no sense if you assume that anyone else has to be somewhere else after your meeting. It’s helpful to have a protocol where you allow for a buffer at the start and the end of the meeting to allow for transitions. There are many options. for a 1:00 - 2:00 meeting you could:
  • Start at 1:05 and end at 1:55
  • Start at 1:00 and end at 1:50
  • Start at 1:10 and end at 2:00
or any variant. Pick what works for your organization. In my experience the first option seemed to work best, as people tend to be more keyed to “round” boundaries. But as long as everyone is consistent, people will have time to regroup and move between meetings.
Be sure to plan the agenda to include time before the end of the meeting to review what you all decided, what followup is necessary, and to decide who will do that followup.

When “Until we are done” makes sense

The opposite side of watching the clock is the idea that you don’t want to cut short a productive exchange of ideas. Ideally you would have allocated enough time to allow for opportunistic conversation. If you do that, you will need to take care that a non-productive meeting doesn’t expand to fill the allocated time. In some cases you can’t do that, and “in the room until the problem is solved, regardless of schedule” is the right thing to do and makes sense but when certain things are true:
  • The issue under discussion needs to be resolved soon.
  • The issue is the top priority for everyone in the room who is asked to be there, and everyone understands this.
  • If you are using a shared resource, such as a conference room, the issue at hand is the top priority for the organization, and you have priority for using the resource.
All of these things are rarely true at the same time. Most people have other commitments, and in many organizations, meeting rooms are a scarce resource. It’s worth taking the time to solve the hard problem of how to get useful work done on a schedule (and to identify what problem fits in that schedule).

Next Steps

While “meetings” may always have a subtext of “something that distracts from work,” if you make the effort to be respectful of people’s time you’re likely to get more done. While having a company culture or guidelines that supports this approach is good, you can establish these guidelines are part or your working agreements at any level of scale.
Regardless or what guidelines you use, the most important thing is to be mindful of the goals of the meeting, and the reality the people may have other commitments.


Popular posts from this blog

Continuous Integration of Python Code with Unit Tests and Maven

My main development language is Java, but I also some work in Python for deployment and related tools. Being a big fan of unit testing I write unit tests in Python using PyUnit. Being a big fan of Maven and Continuous Integration, I really want the  Python unit tests to run as part of the build. I wanted to have a solution that met the following criteria:
Used commonly available pluginsKeep the maven structure of test and src files in the appropriate directories.Have the tests run in the test phase and fail the build when the tests fail.
The simplest approach I came up with to do this was to use the Exec Maven Plugin by adding the following configuration to your (python) project's POM.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <executions> <execution> <configuration> <executable>python</executable> <workingDirectory>src/test/python</workingDirect…

Displaying Build Numbers in Grails Apps

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example. In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:
To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
-Dbuild.number=${bamboo.buildNumber} warTo only change build artifacts and not any source files.To not misuse the app version, or change the names of any artifacts.To be simple and idiomatic.I realized that that Grails itself changes the application metadata (appl…

Motivation Visibility, and Unit Testing

I've always been interested in organizational patterns (such as those in Organizational Patterns of Agile Software Development). I've recently found myself thinking a lot about motivation. I'm now reading Drive: The Surprising Truth About What Motivates Us and just finished Rob Austin's book on performance measurement. Being the parent of a three year old, I'm finding more and more that "because I said so, and I'm right" isn't too effective at home. My interests in motivation are closely related to my interest in writing software effectively. Writing software is partially a technical problem about frameworks, coding, and the like, but the harder (and perhaps more interesting) problem is how to get a group of people working together towards a common goal. Agile practices, both technical and organizational, build a framework which makes having the right amount of collaboration and feedback possible. But there's a bootstrapping process: How do yo…