Frank Carver's Punch Barrel

Jason Yip from Thoughtworks has a nice summary of points to remember when organising or managing stand-up meetings.

You’d think with all my video game experience that I’d be more prepared for this: A quick summary of how I like do stand-ups

For a variety of reasons, this morning’s stand-up meeting was a bit of a lifeless affair. I can recall times in the (relatively recent) past when such meetings were an invigorating start to the day.

Sarah Taraporewalla has some suggestions for adding a bit of energy to morning stand-up meetings.

Sarah Taraporewalla’s Technical Ramblings » Improvements to the usual stand up meetings

Good solid tips for getting the best out a retrospective (and they are also useful for meetings in general).

Column info : Five Tips for Retrospective Leaders and Meeting Moderators

I have noticed this phenomenon during our “planning poker” estimation meetings, and to some extent in retrospectives and other meetings about iterations, planning and progress. Each time a meeting is held, the number of attendees increases slightly, and the meeting (sometimes imperceptibly, but the cumulative effect is there) slows down. This slowdown leads to a perceived idea that if only we had more stakeholders in the room, we could get more answers more quickly, so more people are invited. And so it gets worse.

Chris Johnston » Of kickoffs and walk throughs

Is this a general curse of agile processes, or is it a particular anti-pattern or failure mode which can be avoided?

Just back to my desk after this mornings stand-up meeting to find an article about how to address lateness and loss of respect at such meetings. Thoughtful.

Focus on the Right Point | Agile Software Development

A short (and pretty old in internet terms) but solid article which, among other things, contains the key phrase:

The purpose is not to meet…it is to improve.

Learning about Lean

Mike Cohn raises an interesting and topical issue about how to indicate what you are working on at a daily stand-up meeting.

In our project we are currently working on an iteration where all the stories overlap and interact. Our usual approach is that each developer grabs a story and works on it until its done, then repeats until either the iteration ends or we run out of scheduled stories. In this case we need something a little smarter – some way of grouping the tasks for the iteration, regardless of which stories they “belong” to, so that developers can work on a chunk of related functionality rather than a story as such.

This is potentially risky, as some of the commenters on the above post point out, but at the moment I can’t see a way around the problem.

Should the Daily Standup Be Person-by-Person or Story-by-Story? | Mike Cohn’s Blog – Succeeding With Agile™

As an agile practitioner and consultant I have been participating in daily stand-up meetings for years now, with generally good results. Occasionally such meetings hit some speed-bumps (for example, one problem seems to be that the group of participants can become a bit too large, but splitting the group does not seem useful either). Such meetings are obviously personal and vary between teams and situations, but it was good to read an article (and comments) about effective stand-up meetings.

InfoQ: What Makes a Good Stand Up Meeting?