The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. – Agile Principle #6
If this maxim was not already almost dead, 2020 would have killed it anyway. If you’re like me, you’ve spent many an hour on Zoom or your company’s equivalent, and much time in collaboration tools which have proliferated in the 20 years since this principle was written.
But that doesn’t mean the ideas behind the principle are obsolete.
When these principles were written, most companies had email — and many software developers, managers and support teams used it extensively to carry out communications which led to unvalidated assumptions and undocumented decisions.
I still see teams try to do this: email threads that are dozens of messages long, with no easy way to understand what the resolution was. That inherently leads to a lot of confusion, with arguments later about what was decided, when and with whom.
Engineers in general, and software developers in particular, hate meetings — they recognize that meetings interrupt the flow of their work, and that they lose a lot of productive time trying to get back to where they were when the meeting started. Of course, it seems easier to dash off a series of quick replies then step right back into flow. It’s tempting to try to eliminate as many meetings as possible.
The temptation is stronger today.
Today, most organizations also have Slack or some other messaging system, in addition to email. They may have discussion forums around their products; or their office collaboration tools or project management system may allow for commenting.
The temptation is even stronger to do as much discussion as possible “off-line” — which really means online, just not together. It doesn’t matter that the emails, comments and message histories get saved — they are saved someplace that is completely inaccessible as a source of knowledge. There is no value in writing things down in such systems.
No one likes a day spent with meetings, but a day spent with email or Slack is even more wasteful. It takes much more time to come to a resolution.
In person discussions can be more time efficient.
When teams meet in person, whether that’s in a conference room or over Zoom, they can cut through the noise to have a richer discussion, with free information flows that drive decisions to done.
In 2001, the best way to have that type of discussion was in a conference room with a whiteboard, fresh markers and pads of sticky notes, so that the team could collaborate on building good visual models that captured their thinking. agile
The authors of the Agile Manifesto emphasized face-to-face communication because 20 years ago, all remote meetings were phone conferences. Basic screen sharing technology was just starting to appear. People spent a lot of time on those phone conferences, and it wasn’t a good experience — especially if the sound quality wasn’t very good. There was no whiteboard, and almost no visuals at all, in a field where most people process information visually. It’s no wonder that they were inefficient at best.
Today, online meetings can be more efficient than face-to-face meetings.
With the technology we have today, and especially in the COVID era, most of us are on video calls where we can see each other and share screens. In fact, for some types of collaboration, these in-person but remote meetings are actually better because we can all see the presentations and collaborate using online tools in ways that are not possible with whiteboards and projectors.
You do need to know how to have an effective meeting and facilitate the discussion, but these are learnable skills. You can take personal responsibility for doing your part to make the discussions rich and valuable. There are a lot of resources for evaluating whether or not you need a meeting, how to run a good meeting and how to stop or end meetings that are not adding value.
Not all face-to-face meetings add value either. Meetings that are basically top-down pushes of information with little discussion are better off as email messages — that way, everyone has exactly the same information, and the online discussion captures the answers to the questions that arise.
Most standard project reviews are also inherently wasteful. They provide little visibility into the true state of the projects under review for the managers, and no real help or useful feedback for the teams. It’s better to engage managers at natural decision points for the program, when their feedback is most helpful, and provide other ways for the managers to learn about the status of their teams.
Often leaders, program managers and technical specialists find their calendars so full of meetings that they can’t get anything done. This is not surprising, as much of the work of leading teams, managing projects and providing technical advice gets done in meetings. But there are ways to reduce meeting burden and ensure that the meetings are adding value: regular cadence and short reports.
Regular meeting cadences reduce the meeting burden.
If you have too many meetings, you could have either too many ad hoc meetings set on short notice, too many standing meetings or both. The solution to all of this is to understand what meetings your team needs and put them all on a regular cadence — which is often not most teams’ default of a weekly meeting.
Some types of things like status updates, benefit from short and frequent meetings — as often as daily or more than once a day. During the pandemic, my staff and I meet three times per day, but the meetings are as short as five minutes — just long enough to provide a forum for problems and questions to surface. We plan around these meetings to avoid interrupting our flow.
Other things benefit from a longer cadence. A lot of teams don’t need to meet every week for an hour to share knowledge. They get much more value from a longer event every two or three weeks, especially if they also have short status meetings in between to stay coordinated.
As much as possible, replace ad hoc meetings with regular meetings to provide an ongoing flow of information. They don’t have to be every week and they don’t have to last for an hour. They do need to be often enough that people bring things to the meeting for discussion.
Short report templates improve meeting discussion.
If your meetings are boring and half the team is doing email on the side, then the quality of the discussion will suffer. People will miss important details because they are distracted.
Long slide sets are just as boring over Zoom as they are in person, and it’s even easier to do email instead of paying attention. Short reports, such as the Key Decision and Knowledge Gap reports from the Rapid Learning Cycles framework, convey much more information in a compact format.
These reports are based upon a single slide but read more like a report. The net effect is similar to the “A3 Report” so named because it prints out on one A3 sized sheet of paper (or its 11 x 17 US equivalent). These reports pack a lot of value into a small space, making them easier to write and read than either long reports or long slide sets.
These reports look great in a Zoom call, and yet there is enough detail to read that people get engaged and stay engaged with the content. They have to pay attention in order to read the report, and then they are more likely to stay engaged with the discussion. It’s even better if you open the report in Edit mode and get the team engaged in improving the report or capturing the final decision.
Team engagement leads to better decisions.
The authors of the Agile Manifesto knew that engaged teams participating in a rich discussion made much better decisions. While we are not able to gather around whiteboards with markers and sticky notes in one physical space, we have even better tools for engaging discussions when we are all together in virtual space.
The update to this week’s principle brings it up to modern standards:
The most efficient and effective method of conveying information to and within a development team is a conversation, whether in person or virtual, in a space with tools to support collaboration.