<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: More on daily meetings</title>
	<atom:link href="http://refactr.com/blog/2007/04/more-on-daily-meetings/feed/" rel="self" type="application/rss+xml" />
	<link>http://refactr.com/blog/2007/04/more-on-daily-meetings/</link>
	<description>informs on and evangelizes best practices of using  &#60;a href="http://refactr.com/the-agile-manifesto/"&#62;agile methods&#60;/a&#62; when designing and developing what are currently being called “Web 2.0” products and applications.</description>
	<pubDate>Fri, 21 Nov 2008 11:17:15 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Casey</title>
		<link>http://refactr.com/blog/2007/04/more-on-daily-meetings/#comment-1344</link>
		<dc:creator>Casey</dc:creator>
		<pubDate>Wed, 11 Apr 2007 15:43:49 +0000</pubDate>
		<guid isPermaLink="false">http://refactr.com/blog/2007/04/09/more-on-daily-meetings/#comment-1344</guid>
		<description>I stand by my comment about the smaller 'contained' team not needing a stand-up.  Consider, the team with outside testers, designers and management actually have more than two members (2 developers, 1 tester, 1 designer, and 1+ management) and anytime there are external actors involved the stand-up becomes much more valuable.

On larger teams, obviously the scrum of scrums is one technique but another option is one big stand-up with all 30 people in the room (standing up) but the questions are changed -- in this meeting you don't answer the standard three questions, rather, the scrum master goes around the room and gives each team member the opportunity to enlighten the group on anything that they feel is important.  It could be what they did yesterday, it could be what is happening upstream, it could be some new library that was added to the code base.  The key is not everyone shares something which keeps the meeting moving.</description>
		<content:encoded><![CDATA[<p>I stand by my comment about the smaller &#8216;contained&#8217; team not needing a stand-up.  Consider, the team with outside testers, designers and management actually have more than two members (2 developers, 1 tester, 1 designer, and 1+ management) and anytime there are external actors involved the stand-up becomes much more valuable.</p>
<p>On larger teams, obviously the scrum of scrums is one technique but another option is one big stand-up with all 30 people in the room (standing up) but the questions are changed &#8212; in this meeting you don&#8217;t answer the standard three questions, rather, the scrum master goes around the room and gives each team member the opportunity to enlighten the group on anything that they feel is important.  It could be what they did yesterday, it could be what is happening upstream, it could be some new library that was added to the code base.  The key is not everyone shares something which keeps the meeting moving.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Vlaminck</title>
		<link>http://refactr.com/blog/2007/04/more-on-daily-meetings/#comment-1341</link>
		<dc:creator>Scott Vlaminck</dc:creator>
		<pubDate>Wed, 11 Apr 2007 13:25:49 +0000</pubDate>
		<guid isPermaLink="false">http://refactr.com/blog/2007/04/09/more-on-daily-meetings/#comment-1341</guid>
		<description>That's an interesting thought. With a smaller team (down to 2 developers), a daily meeting might still be helpful for any outside people (testers, designers, mgmt). In that case, I would hope you could keep the meeting to 3 minutes or so - the challenge being still to keep the discussion at the right level. 

Scaling up to larger teams, I would imagine that you would want to break the application into components to keep the meeting size smaller - but then be much more vigilant about swapping pairs, etc.

Casey, you've had more experience than I have on larger teams. How have you handled larger teams in the past? And what are your thoughts on how that worked for the team?</description>
		<content:encoded><![CDATA[<p>That&#8217;s an interesting thought. With a smaller team (down to 2 developers), a daily meeting might still be helpful for any outside people (testers, designers, mgmt). In that case, I would hope you could keep the meeting to 3 minutes or so - the challenge being still to keep the discussion at the right level. </p>
<p>Scaling up to larger teams, I would imagine that you would want to break the application into components to keep the meeting size smaller - but then be much more vigilant about swapping pairs, etc.</p>
<p>Casey, you&#8217;ve had more experience than I have on larger teams. How have you handled larger teams in the past? And what are your thoughts on how that worked for the team?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Casey Helbling</title>
		<link>http://refactr.com/blog/2007/04/more-on-daily-meetings/#comment-1334</link>
		<dc:creator>Casey Helbling</dc:creator>
		<pubDate>Wed, 11 Apr 2007 01:09:28 +0000</pubDate>
		<guid isPermaLink="false">http://refactr.com/blog/2007/04/09/more-on-daily-meetings/#comment-1334</guid>
		<description>I also wonder if there is a point of diminishing returns based on team size.  For example, when the team consists of three or four people, two of which are pairing all day long, it is very hard to justify a stand-up when you are effectively collaborating all day long.</description>
		<content:encoded><![CDATA[<p>I also wonder if there is a point of diminishing returns based on team size.  For example, when the team consists of three or four people, two of which are pairing all day long, it is very hard to justify a stand-up when you are effectively collaborating all day long.</p>
]]></content:encoded>
	</item>
</channel>
</rss>


