Roy had a fun idea of having a q&a session in which he asked what the audience wanted to talk about and then we voted on the topics.

1. Agile Estimation
-"lead says 2 weeks. PM says 4 weeks. Marketing says 2 months. Client says I am going to go have it fai in india"
-Do a first round estimation and then do a second round of estimates that will give you a good estimate. Do this around the table with the people who are actually going to write it. That way you will get a more balanced opinion.
-"or there is the XP guy who likes whiteboards and everything is going to be perfect and everyone hates him"
-It is important to find the pace of the team (i.e. the first iteration) in order to establish pace of the team.
-It is really important for the developer to do their own estimates. It is the only way they will get better at estimation.
-"Its like the group hug... but no one is hugging... they are estimating"
-During an iteration requirements do not change. That is why itterations are shorter to allow you to estimate changes
-Mike Cohen: Agile Estimation and Planning (or something like that) is a good book on this topic.
-At this point I think this topic is going to consume the whole hour (its 10:00 now)
-Roy pulls up Scott and JP to pitch in comments on this topic
-When people disagree on estimates then another round should be done until a consensus has been reached.
-It is important that devs give accurate (i.e. non-padded estimates). This is the only way to get accurate estimates in the future.
-Tasks should usually be maybe 3-4 days at most. Depending on itteration length (i.e. in a 1 week itteration anything over 1 day is probably too long).

2. Agile in Distributed Teams
-Timezone issues (i.e. working with someone who is 7 hours off)
-Communication is very important to agile but by distributing development it really cuts into that.
-A person should be available in every time zone to answer questions at any time
-If you do paired programming then there are collaboration programs
-Roy pulls up Troy (did not know him before) to talk about his experience.
-Roy pulls up Ben to talk about his experience with working with distributed teams. He felt that VNC/Rdesktop is too slow to make it viable. What they do is have one programmer open his code and show it to another developer. Almost a paired code reveiw I would say.
-Roy pulls up Wendy to talk about someones scrum question (I did not hear the question though)
-Most people said that Ken Shwaber: Project management using scrum (or something like it) is a good book

3. Adopting Agile In Organization
-"apart from saving on hardware how does paired programming help us?"
-The best/only way to introduce it is via training in a closed environment so that people get out of their current project bubble
-A maanger will usually make a lot of mistakes by forcing a huge change to an organization. Start small with a practice here and there.
-Do everything we do now but in shorter itterations is one small change that is easy
-JP put it well "adopting agile is an itterative approach" i.e. implementing small wins (he does not introduce TDD until a month in usually when training a team)
-JP said ask a manager "where do you want to spend the time? 3 days debugging a pain point after a bug appears or 3 hours writing tests to find it before hand)?"
-"even more important than trainining is mentoring" -JP

we ran out of time for:
-Introducing agile to a Team
-Team Structure
-How To Measure Results

Song
Roy always finishes things off with a song. Sorry the audio sucks.