Optimizing meetings (and other processes)

There are many possible ways to conduct a meeting. Or to do hiring. Or to advertise your product or service. But which of all possible ways to do these would work well in your particular circumstances? Here we will look at an agile approach to figuring that out.

The question we want to answer is: How do we figure out what works and what doesn't in the most expedient way and with minimum waste of resources?

Quick overview

Start very quickly with any process at all. How the process looks like in the beginning does not really matter. The important thing is to:
1. Introduce a mechanism for continuous improvement.
2. Have quick iterations. Iteration = time between implementation of a change and determining how well the change has worked.

Example of this applied to a meeting process

We start with any meeting process. Let's say we start with a kind of a "free for all" meeting, meaning that we haven't established any rules, everyone can start speaking whenever they want, there is no agenda, meeting has no time limit, people get into arguments or offtopic discussions, etc. The meeting goes on like that for some time. Then someone makes the suggestion to appoint a meeting moderator who would have the following two functions:

- Facilitates the building of a meeting agenda 
- Cuts off offtopic talk

The suggestion is implemented. A moderator is appointed immediately and he or she starts moderating the meeting through the two abovementioned functions. When all agenda items have been covered, the meeting participants notice that the meeting has taken less time than other meetings with a similar number of agenda items. Acknowledging that, someone makes the suggestion to add another function to the moderator role: 

- Notes down the time when each agenda item was started and completed 

This third function will allow the meeting participants to measure how long each agenda item has taken them to cover. It will be implemented without delay, at the start of their next meeting, and can help them introduce additional improvements that would further optimize the meeting process.

The functions of the moderator role are, of course, written down. All of the meeting participants look at them during the meeting. So far, after just one meeting, the functions look like this:

Meeting moderator role:
- Facilitates the building of a meeting agenda 
- Cuts off offtopic talk
- Notes down the time when each agenda item was started and completed 

Generalizing it beyond just meetings

By having a way to easily implement many small changes to the process and test how well they have worked, the meeting participants can arrive at a highly effective meeting process that never stops to improve. Rather than proposing large, difficult to assess changes and arguing for or against them before getting any chance to see how they work, the approach is to quickly and easily implement small changes and check out how well they have worked.

This does not mean that all proposed changes have to be implemented. A proposed change may not be implemented if a meeting participant can identify a concrete reason why the change would cause harm. However, even in those cases the proposed change may be implemented if the potential harm can be minimized, for example by implementing the change on a very small scale.

This agile approach can be used for arriving at all sorts of processes (e.g. meetings, team workflows, educational courses, etc., etc.). It will likely vary depending on what kind of project you are dealing with. If, for example, you are building a product (a website, etc.), the approach may look differently. However, the basics will be very similar. 

What usually happens with many projects is that people try to figure out too much in advance by using logic and reason. Certainly, we want to encourage everyone to think about their projects. However, in the approach described here, a fundamental change is that you try something, see how it works and then act based on data, rather than on how you envision things would work. This can save countless hours. It certainly has saved me.

References/Recommended reading:
- Henrik Kniberg - Scrum and XP from the Trenches (See this for an introduction to Scrum. Note: the book and webpage are written for computer programmers, others will probably not understand the jargon, unfortunately.)

H2
H3
H4
3 columns
2 columns
1 column
1 Comment