As developers we spend a lot of time in meetings. Sometimes those meetings are short and productive. Sometimes they take ages, and what's even worse, they don't bring any results.
We've all been there, sitting in a meeting, listening to clients/product owners, who are wondering what they could do, instead of thinking what they really need. Those meetings usually turns into endless discussion panels, where people are arguing about the features, competitors, etc. They talk about everything but solutions.
Don't get me wrong, it's good to have different opinions, but imagine how well time could be spent if attendees came to the meeting prepared. Focusing on pros and cons of the solutions/ideas; and then - as a team - decided what to do. Sounds easy, right? Well, it's not. Simply because it requires preparation.

We cannot force people to be prepared for every single meeting. Usually people are unprepared because they're busy. Although, sometimes they just have no idea what we want talk about. Regardless of the reason, we can make this process easier, which eventually might result in more productive and effective meetings.

The List

I saw this method for the first time when I was working on a complex project.

Once a week, our Business Analytics (BA) had a meeting with a client called Alignment.  Every time, both BAs and client, prepared a list of topics they wanted to discuss. During the meeting, they talked only about topics from the list. Nothing more, nothing less. As a result, they wrote down the notes and - if necessary - required actions.
It sounds quite formal and tedious. My thoughts were the same, but I started appreciate this method when I realized how many benefits it brought to the project.

General awareness

First of all, with the list, everyone knows what will be discussed during next meeting. This gives a chance for preparation. Clients/product owners might revisit their requirements. Designers can prepare mocks. Developers can assess technological solutions. Every single action taken in advance makes the meeting more effective.
Also, list available to the rest of a team increases overall awareness of the project. Everyone knows what's happing and what is planned for the future.
This doesn't stop there. If a team member needs to discuss something, he/she just needs to add the topic to the list. It is that simple, bring the topic and attend the meeting.

Right people at right time

How many times a decision was postponed because someone was not in the meeting? And I'm not talking about product owners, business analytics or project leaders. I'm talking about people with specialized knowledge.
Let's say there is a discussion about user interface. Who is better to talk about UI than a designer or UX expert? If the meeting list was created in advance, it would give time to invite those people. Remember, right people increase a chance of making decisions or defining necessary actions.

Time guardian

In the introduction I mentioned endless discussions. Yet, there is finite amount of time for the meeting and usually every topic needs to be discussed. Fortunately time constraints, assigned to every topic, keep meetings organized.
How much time spend on a topic? At the beginning a good way would be to divide meeting's time by number of topics. For example,  in a 1 hour meeting there can be five 12 minutes topics. Of course, the time doesn't have to be evenly distributed, and after couple of meetings it will be easier to assign time constrains.
Another question is what to do when time is exceeded? The best way is to cut off the discussions, and determine next actions. For example, product owner will talk with stakeholders, or developer will prepare the list of viable solutions.
Even if  a solution is not yet determined, actions will keep things going and allow to tackle the problem again during next meeting.

Are there any actions?

Very often it turns out that some additional actions are necessary. A user story is too big and needs to be split, developer needs to investigate something, etc. Equally often people forget about those actions. Maybe not all of them, but I'm sure each of us forgot to do something after the meeting.
To solve this issue, the list has a column dedicated to actions. If a topic requires an action it is noted in that column.
It not only helps to remember, but also gives the insight into what will happen next. Furthermore, it ensures there is full transparency between client/product owner and the rest of a team.

Where to store it?

Now, you know how this list works, but you might be wondering how to keep it. First of all, it should be accessible to anyone in a team. It also must be editable. Usually such lists are part of project's documentation, so they both should be kept together. If  a documentation is already written in some kind of wiki, like Confluence or GitHub wiki  then it is perfect place to store the meeting notes. For every meeting a new page is created, and used for storing meeting's agenda and notes.

If a fancy documentation system is not available, the oldie but a goodie plain text files and shared folder will suffice. In such case, each meeting notes will be stored in separate files. Of course this won't be as convenient as dedicated systems, but it will serve its purpose.

Conclusion

Let's face it. What I just wrote doesn't sound revolutionary. And it is not. That's the beauty of this method. It's easy to introduce, but it requires discipline and patience to master it. Hopefully you can see the advantages. I also hope that I convince you to try it. You have nothing to loose. And who knows, maybe it will make even yours meetings more effective.

Image credits: You X Ventures.