Anatomy of a failed meeting
Meetings are a fundamental part of any software development project. They seem to be even more important to people that are not directly involved in the software project itself.
If they are so important why are they so often boring, too long and unproductive?
I'll resist the temptation of trying to write here how a good meeting should be held, but I'll try to describe here a meeting I was in today that was a clear textbook example of a failed meeting.
First off, the people involved where 5 product managers (?!?!?) and 2 business owners. In total 7 people. In a meeting where you should try to reach an agreement to have 7 people is asking for trouble. Even though having 7 people in the meeting in itself is not a reason for failure it is an indication that the organizer of the meeting was not able to focus the problem he had (5 product managers?!?!?!).
Then the meeting started without any statement of context, at least half the people in the meeting were not told why they were called into the meeting, and at least I, heard about the meeting 20 minutes before it started, which left no time to prepare anything for the meeting.
Again, not being prepared for a meeting is not a sure failure, but you have to agree that it does help a lot...
Since no context was described and most participants did not have any time to prepare we started immediately "solving" the problem. When I asked why we were in that meeting I received no answer (to this point I don't know, for the life of me, why the meeting was called).
Trying to go for a problem solution without explaining the problem (or indeed listening to the different views on what the problem really is) is not a sure indication of failure, but it usually leads to that.
As the discussion went on several different problems were stated, none of them was defined clearly, and none of them was tackled. When this happens you know you have a bad meeting. No productive outcome can come of a meeting where no one agrees on what is the "single" problem that we are trying to solve.
Let's recap the anatomy of a failed meeting. If you want to have a failed meeting make sure that you:
1- Call as many people as possible to the meeting, to the point of calling in people that do not know or could not care about what you are about to talk about.
2- Don't explain the reason for the meeting (context), and especially notify attendants of the agenda only a few minutes before it starts.
3- If someone asks why they are in the meeting and what is it's purpose: ignore them
4- Raise as many unsolved problems as possible during the meeting so as to avoid concentrating in one problem.
5- If someone tries to state the problem in clear terms change the subject (at this point it is a good policy to use the technique described in point 4).
6- At the end of the meeting don't summarize the discussion, don't send meeting minutes to the participants and especially don't describe what will be the next steps to try to solve whatever problem you were supposed to solve.
If you follow these simple steps you are sure to have a long and happy life inside meeting rooms without ever having to reach any conclusion or solve any problem.
For even better effect complain to your boss about those other people that were in the meeting and tell her/him that they are utterly incompetent and that you could have reached a conclusion/solution a long time ago were it not for those morons.
These "rules" go a long way explaining why in the Agile software development model we try to avoid meetings. Most (maybe even 99%) of all problems or difficulties can be solved by having a few people (2 to 3) talk to each other over coffee and then go back to their workplaces and solve the problem together.
In Scrum there is one meeting that can have up to 11 people (10 + scrum master), that's the daily scrum. But don't worry! That meeting is carefully choreographed (the 3 questions) and is usually over in 10-15 minutes once you get the hang of it.
at
22:24
If they are so important why are they so often boring, too long and unproductive?
I'll resist the temptation of trying to write here how a good meeting should be held, but I'll try to describe here a meeting I was in today that was a clear textbook example of a failed meeting.
First off, the people involved where 5 product managers (?!?!?) and 2 business owners. In total 7 people. In a meeting where you should try to reach an agreement to have 7 people is asking for trouble. Even though having 7 people in the meeting in itself is not a reason for failure it is an indication that the organizer of the meeting was not able to focus the problem he had (5 product managers?!?!?!).
Then the meeting started without any statement of context, at least half the people in the meeting were not told why they were called into the meeting, and at least I, heard about the meeting 20 minutes before it started, which left no time to prepare anything for the meeting.
Again, not being prepared for a meeting is not a sure failure, but you have to agree that it does help a lot...
Since no context was described and most participants did not have any time to prepare we started immediately "solving" the problem. When I asked why we were in that meeting I received no answer (to this point I don't know, for the life of me, why the meeting was called).
Trying to go for a problem solution without explaining the problem (or indeed listening to the different views on what the problem really is) is not a sure indication of failure, but it usually leads to that.
As the discussion went on several different problems were stated, none of them was defined clearly, and none of them was tackled. When this happens you know you have a bad meeting. No productive outcome can come of a meeting where no one agrees on what is the "single" problem that we are trying to solve.
Let's recap the anatomy of a failed meeting. If you want to have a failed meeting make sure that you:
1- Call as many people as possible to the meeting, to the point of calling in people that do not know or could not care about what you are about to talk about.
2- Don't explain the reason for the meeting (context), and especially notify attendants of the agenda only a few minutes before it starts.
3- If someone asks why they are in the meeting and what is it's purpose: ignore them
4- Raise as many unsolved problems as possible during the meeting so as to avoid concentrating in one problem.
5- If someone tries to state the problem in clear terms change the subject (at this point it is a good policy to use the technique described in point 4).
6- At the end of the meeting don't summarize the discussion, don't send meeting minutes to the participants and especially don't describe what will be the next steps to try to solve whatever problem you were supposed to solve.
If you follow these simple steps you are sure to have a long and happy life inside meeting rooms without ever having to reach any conclusion or solve any problem.
For even better effect complain to your boss about those other people that were in the meeting and tell her/him that they are utterly incompetent and that you could have reached a conclusion/solution a long time ago were it not for those morons.
These "rules" go a long way explaining why in the Agile software development model we try to avoid meetings. Most (maybe even 99%) of all problems or difficulties can be solved by having a few people (2 to 3) talk to each other over coffee and then go back to their workplaces and solve the problem together.
In Scrum there is one meeting that can have up to 11 people (10 + scrum master), that's the daily scrum. But don't worry! That meeting is carefully choreographed (the 3 questions) and is usually over in 10-15 minutes once you get the hang of it.
RSS link
0 Comments:
Post a Comment
<< Home