Test-driven Meeting development: meaningfulness in times of remote work

In times of smart working the number of meetings has increased. Therefore, to keep productivity high, it is important to identify good practices in order to avoid fragmentation of time slots (for instance by defining a meeting-free day left to actual work), as that would interrupt one's mental flow and creativity, and on the other hand identify guidelines to achieve efficient and effective meetings.

source: whyarentyoucoding.com 

In this post I want to reflect on the latter, i.e. achieving meaningful meetings. 

Motivation 1: increasing number of meetings

Possible solutions:

• for the proposer
• establish ownership of the meeting - there is no self-organized meeting - define a meeting chair in charge for content and outcome (can be the proposer or his manager)
• in bigger meetings define somebody to write down minutes (see example here)
• send out minute/follow-up to participants
• for the invited one
• learn to say NO - time is money - if meeting is useless actual work will have to be done in free time!
• make sure your presence is a contribution, i.e. provide constructive feedback to the presenter and rest of the audience

Motivation 2: lack of structure

Possible solutions:

• propose an agenda to define a focus (to stick to)
• define an expected outcome (to enclose with the agenda)
• define action items as a result, that is, who does what and by when

The starting point is the fact that although not all meetings seem to be alike, they all have inputs, outputs and functional requirements or goals. 

With this in mind, we can learn from test-driven development (TDD) practices:

• requirements converted into test cases before any actual implementation begins - 3 laws of TDD
• write tests which must fail initially - assertions based on actual requirements
• write and refactor the least code until test pass (and no more!) - See also this
• test cases
• can match 1:1 user stories and fit well the definition of done
• code inherently modular and prevent lazyness to write tests afterwards

Similarly, you want to make sure all participants have clear:

• why you are holding the meeting
• expected outcome - functionally speaking
• agenda - how you intend to achieve it
• who should participate and why - both mandatorily and optionally
• things that should be prepared and provided beforehand

As a final result this could be a possible meeting template, you may share: 

Invited	Required	Optional	Notes & Resources
Agenda	intro lorem ipsum
Expected  Meeting Outcome
To be provided or prepared beforehand	Description		Assigned to
	Access to service xxx		Max Mustermann
Selected Actions	Action Description	Due by	Assigned to
	Performance test service xxx	29/02/2021	Mario Rossi

Beside the agenda, you may also want to specify a reference to the task/story on your Jira/Trello/whateverelse board you are using, just to make sure participants (at least those within the team able to access the board) have the right context before participating.