Home > Agile > Was it a successful meeting?

Was it a successful meeting?

Why did you feel that a certain meeting was "successful"? Did you leave the meeting without long debates or did you finally win over the team from The Other Guy, that bastard who always gets his way? Or did you feel confident that the right decision was taken, even if you really thought that another solution is better from your point of view?

In most leadership courses, time is spent on getting the participants to understand who they are. Myers-Briggs is a scale many of you are most certain familiar with. Dave Nicolette writes on his blog about a simpler classification which can be used when describing meeting strategies among team members. In a very interesting blog post, he sees three strategies:

  1. The ones who’s highest priority is "To win"
  2. The ones who’s highest priority is "To find the best solution"
  3. The ones who’s highest priority is "To avoid conflict"

Be sure to read the example in the blog post. We’ve all been there. Heard the discussion. Met the types.

And as Nicolette writes, you need all these traits in a team and a discussion! What if no one cares enough to win the discussion? What if no one cares if the best solution is selected? What if everyone is so involved in the discussion that they don’t care if the time spent and the risen conflict is really worth the trouble?

But it is also interesting to see which traits are dominant in a person in a specific context. A person can feel very strongly about an area and even if he’s the guy who always avoid a conflict in other cases suddenly becomes the guy who have to win since the area of discussion is a treasured and soft spot. And if there is a personal strain between two individuals, two who in other instances are the ones who try to find the best solution turns has to win the debate since the other guy is presenting another suggestion.

How can you use this classification? Well, I really hate classification of individuals into one, single package. What I like about Nicolette’s classification is that it’s context based: you don’t classify a person. Instead you classify how a person works in a specific discussion, where the context is a function of area of discussion, other team members and situation. You can therefore use the classification to analyze the discussion as such: if we spent 12 man hours on a discussion and the end result was still poor, could it have something to do with how the discussion worked?

So, what do you do if your discussions are not productive? Nicolette points at the possibility to remove a team member. Since this changes the context, everything can become better. I believe this can be a good solution if there are personal strains between people, turning them into must-wins or avoid-conflicts or if someone is incompetent without realizing or caring about it and still use the must-win strategy. Both these scenarios are sad and leads to a spiral of death to the team. Either you handle the personal conflicts, increase the competence (the problem here is if the incompetent person does not want to admit to lacking competence) or you make changes to the team structure. But one should not fall into the pointing of fingers: it’s HIS fault that the system is built this way. That is truly unproductive.

Agile teams are self organizing but that does not make them free of unproductive discussions and here I think we need great leaders and involved leadership. A great leader handles a personal conflict before it gets out of hand. A true leader handles a team member with lacking competence, whether or not that person admits to it or not. An agile leader evaluate meetings and make sure that they are productive, and that does not mean that "a solution was decided on" but also evaluates the long term effects. You cannot place this burden on individual team members. It’s great if the teams can solve these problems themselves but we all know that handling personal conflicts, consistent flow of bad decisions and lacking competence is a harder apple to bite.

Advertisements
Categories: Agile Tags: ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: