As developers we spend a lot of time in meetings. Sometimes those meetings are short and productive. Sometimes they take ages and what is even worse, they don't bring any results.
We've all been there, sitting in the meeting, listening to clients/product owners, who are wondering about what they could do, instead of thinking about 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 spent time could be if opposite sides came to the meeting prepared. Presenting pros and cons of their solutions and then as a team you decided what to do. Sounds easy, right? Yeah, it is not because it requires preparation.
We cannot force people to be prepared for every single meeting. Usually people come to the meetings unprepared because they are busy, but sometimes they just had no idea what we want talk about. Regardless of the reason, we can make this whole process easier which eventually might result in more productive and effective meetings.
I saw this method for the first time when I was working on previous project. Once a week, our Business Analytics (BA) had a meeting with a client called
Alignment. For every meeting they (both BAs and client) would prepare a list of topics they wanted to discuss. During the meeting, they would talk only about the things from the list, nothing more nothing less. During the meeting, they would write 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.
Sample list of topics.
First of all, with the list, everyone knows what will be discussed during next meeting. This gives a chance and time for preparation. Clients/product owners might revisit their requirements. Designers can prepare mocks. Developers can assess technological solutions. Every single action taken before the meeting makes the meeting itself more effective.
If the list is available to the rest of a team, that increases overall awareness of the project. Every one knows what's happing right now and what is planned for the future.
This doesn't stop there. If a team member needs to discuss something with the client. 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.
Lets say you want to talk about user interface. Who is better to talk about UX than a designer or UX expert? If you create a list in advance, it will give you time to invite these people. Specialist are not only to help make a decision, by explaining and clarifying stuff. They are in the meeting to actually increase a chance of making some decisions or defining necessary actions.
Do you remember when I mentioned endless discussions? The list allows to eliminate them. You can add time constraint to every topic you want to discuss. You need to remember that you have finite amount of time for the meeting and you have to go trough every topic from the list.
You may ask how much time you should spend on a topic? It depends. Some topic will take more time to refine, some will take less.
If you just starting, you can divide the meeting time by number of topics. For example if you have 1 hour meeting and 5 topics to discuss, that gives you about 12 minutes per topic. After couple of meetings you will know how much time is required for each topic. So don't worry about this and just experiment.
Another question is what to do when we already exceeded allocated time? The best way would be to cut off the discussions, and determine next actions. For example, client will talk to stakeholders, or developer will prepare the list of viable solutions.
Even if you don't end up with a solution, actions will keep things going and allow you to tackle the problem again during next meeting.
Are there any actions?
Very often, during the meetings, it turns out that we need to take some additional actions. Split a user story, create a spike to investigate something, etc. Equally often we forget about those actions. Ok, maybe not all of them, but I'm sure every single one 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 you just write it down in that column.
It not only helps you remember, but also gives all of you the insight into what will happen next. That also ensures that there is full transparency between client/product owner and the rest of a team.
Actions adeed to the topics.
Where to store it?
Now you know how this list works. You might wondering where you should keep it. 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 are kept together with documentation. If you keep your documentation in some kind of
GitHub wiki you are ready to go. All you need to do is to create a section for your lists. Then for every meeting you create a new page where you keep your topic list and all the meeting notes.
List of the meeting notes.
If you don't have any fancy documentation systems available, you can use plain text files and shared folder. 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.
Let's face it. What I just wrote doesn't sound revolutionary. And it is not. That's the buauty 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 your meetings more effective.
Image credits: Brooke Cagle.