Mark Needham

Thoughts on Software Development

Agile: The curse of meetings

with 7 comments

Something which can often happen with agile software development teams is that in the desire to take everyone’s opinion into account for every decision we end up having a lot of meetings.

Toni wrote about this a while ago and described a situation where he’d managed to get rid of a meeting and just have a discussion after the stand up with the necessary people.

While this is a good idea I still think there are occasions where it’s not necessary to discuss every problem down to the minute details with the whole team.

For example, this week we needed to make changes to some migration files to deal with the fact that we’d removed a gem which a migration previously relied on.

3 solutions were suggested and each had good and bad parts to it so any discussion amongst a group of people was likely to result in a split opinion on what the best approach to take was.

In that situation I think it makes much more sense for one pair to take the problem, work out what they think is the best solution and then just do it.

If it turns out that wasn’t the best solution then we can change it in the future.

It can be quite difficult to persuade people that it’s not necessary to have meetings because the meetings are usually are about things which affect the team so it seems to make sense to involve everyone.

On the other hand I like to think of what people could be doing instead of attending that meeting.

If what they could be doing would be more valuable then perhaps they shouldn’t be in that meeting.

Be Sociable, Share!

Written by Mark Needham

October 9th, 2010 at 3:39 am

Posted in Agile

Tagged with

  • Patrick

    Sports that don’t have timeouts require that players communicate on the field, while still playing. Working to and acting on a shared understanding doesn’t require formal meetings – sure they’re supposed to facilitate it but frequently they don’t.

  • Pingback: Tweets that mention Agile: The curse of meetings at Mark Needham --

  • Another aspect of the example is worth highlighting. In order to get more information, some coding needs to be done. It would be different if people had already separately coded the different approaches and now it was time to decide between them. I think this is another mistake we often make. Opinions matter, but informed opinions do matter more.

  • @Dave – so that would seem to be the idea of the ‘last responsible moment’ in that we can delay making the decision until we’ve done that coding and seen which approach will work out better.

    Hadn’t thought of that – neat observation.

  • Venkatesh Sampath

    Recently, happened to get a chance to watch a presentation from Dan North in InfoQ where he mentioned using a tool called, Six Thinking Hats. Seems it worth trying it out in meetings.
    I really hate meetings, but only those, which are unfocused and unproductive.
    Sometimes, more Dev Huddles might suffice, which worked out really well in atleast cut shorting the meeting durations for a I worked when I was back in Thoughtworks.

  • Pingback: Wouldn’t It Be Nice | Joe Homs()

  • Pingback: 高效敏捷会议 | chainding()