« Changes for 2007 | Main | Stand-Up Visual Aid Examples »

Monday, January 29, 2007

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83452ee9169e200d83463e6d169e2

Listed below are links to weblogs that reference Stand-up Meetings and Visual Aids:

» Agile Chronicles: Stand-up Meetings and Visual Aids from pligg.poddrzewem.pl
Excellent article explaining the need for visual aids during stand-up meetings. As stand-up is the most important communication enabler it's crucial for all the team members to be on the same page. [Read More]

Comments

Ron Jeffries

In an article about visual aids, examples of the kind of visual aids you're talking about would be great to see. I urge you to update to include samples!

Thanks!

Andy Powell

Ron, good idea. I'll add some examples this week.

obie

I've had success using a projector in the daily scrum to chart tasks, time remaining, and burndown all at once. The team does the roundtable of what they worked on, and are working on today, and as they are talking, are asked how much time is left and the driver updates the task - that way you get a realtime view and you know everyone has entered their data - nothing kills a burndown chart faster than a process where the data that backs it is out of date. At the end of the meeting, the focus flips to the burndown. The key is to have a tool that seemlessly lets you modify tasks on the fly, very very quickly.

Jack VanDenHeerik

It would also be prudent to ensure that everyone present for the stand-up presentation is given a hand-out of the visual aids (slides). The benefit is that the context of the presentation is taken with them and can be refered to later.

Peter P.

Interesting points but adding this level of complexity, though relatively minimal, seems to make the stand-up far more complex than it is intended to be. Visuals are excellent tools but as soon as you introduce them you take the focus from the team to the screen and you add a host of other needs to support the meeting. I would suggest that this is best suited for a iteration review meeting that identifies weaknesses in team practices, such as updating status.

Moreover, the following line struck me as highly antithetical to Agile ideals: For example, when a team is considerably above the ideal burn down line and half way through the iteration, the burn down chart can help start a discussion about how much Rockstar needs to be ordered.

One of the great things about Agile approaches is the idea that it allows future planning with some degree of expected accuracy based on previous performance. If that performance is based on Rockstar-driven hours, you've blown your ability to estimate accurately and cannot trust that your previous results will be repeatable. You have also then set a precedence that quickly leads down the path to team burn-out. Now that the team is driven by deadlines, what was the point of prioritizing features at the beginning of the iteration?

Maybe I'm reading more into this line than is there but it indicates to me that you have over-looked a fundamental point of Agile development, and that clouds my view of the rest of your ideas.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.

Subscribe