Ticketing and Neverending Meetings

Have you ever participated in a conversation with a manager/stakeholder, who really liked to hear his voice and could talk forever? Did you check your colleague's face during the meeting? Were they bored?

The manager thinks he (or she) is the hero of the day because he knows the customer. The customer told the manager all their requests which the manager surely understand (evil smiley). From the managers point of view it is compulsory to involve the developers into any kind of meetings which are even slightly related to the development of the product because they were told in MBA that the more they share information with developers the better for the product (=> for the manager).

The developer on the other hand is usually looking for something to work on. Depending on how much of a geek somebody is there levels to which a developer is interested in the projects management. Obviously there are some information that you simply have to have in order to actively develop an application. I believe maximum 10 % of all the tasks related to a project can be worked on without having a hint on what the project is all about. Security issues, connectivity issues etc. But do we really need to have developers spending half of the day banging their heads to the desk (while skype is muted...)???

So how is this connected to ticketing? Ever since I started out as software engineer I can say roughly 75 % of all the meetings i participated in were a complete waste of time. Please note I don't count tipical daily standups here.

Why? Developers are generally smart people. They like to start on something on their own and ask when they are lost. They are also very pragrammatic. Get the ticket, read the spec, ask for details which are not clear, implement, return for testing. Done.

My biggest problems with neverending conference calls and meetings is that very often there is no takeaway (maybe a coffee). The things we said or heard are never transformed to paper (spec, ticket). So you have to start working on something out of what you remember. That was one of the things (i don't say there were many) I hated in my previous job.

It is acceptable if the specification changes to some extent. But it is highly unacceptable to try to account a developer for something that was (maybe) mentioned in a meeting. I believe it is everybody's best interest to spend that few minutes to write down what has to be done.

As always we at IT Blame are very curious to see what you think about the subject so please leave a comment. 

How do you cope with spread by the word tasks?

Happy coding!