+1  A: 

How often do you meet?

Daily (usually first thing in the morning), and whenever necessary to remove roadblocks. Pairing only when necessary to solve complex problems - or early in test development.

Have you tried different sprint lengths (one week, two week, longer) ?

Yes, but this always depends on customer-provided priorities and delivery schedules first. We respond to their requirements, not make up our own. Sometimes spikes play into this, as it is impossible to avert dependency loops.

Which tools do you use?

Pivotal Tracker and Rally. Have been forced to use TeamForge, which sucks. I really like Campfire and it seems to do the trick for my teams.

Which issue tracker do you use?

Depends on the project, but usually something that is web-based at a minimum.

What do you do about time zone differences?

Deal with it. Most of my projects are spread around the world, somebody is going to get screwed - it usually is me.

How does it work for you to integrate new people into the team?

Depends on the team, and the newbie. Some teams are more accepting than others, and some newbies are better at integrating. There should always be respect, period.

How many hours do you usually work per week?

40+ - the plus usually is due to multiple projects - pro and personal.

How does your management interact with the way you are working?

Hands-off. But, sometimes things get tense. Just takes good communication, and transparency is always better.

Do you get put on a waterfall with hard deadlines?

Sure...even within Agile projects. Customers are demanding.

What's your unit of work?

Depends on the project of course. But, usually time for me and my teams. Deliverables go with everything...but we usually have up-stream projects to support too.

What is your normal velocity? (units of work done per week)

There is no normal. Complexity, team, customer all play in as rough variables. The biggest problem is usually team maturity.

Kit Plummer
A: 

@Carl: I can't answer all your questions, but I can put in my two cents WRT a few issues.

  • Usage of Skype is essential. Putting faces to internet aliases makes for a more friendly (therefore, productive) work environment. When I worked with a offsite team, there was a lot of offline complaining about the offsite team.
  • Daily meetings, even for 15 minutes, are very helpful. Devote five-ten minutes to people just talking about whatever they want to talk, whether it's their weekend, kids, etc. People will talk about this kind of stuff anyway, and being able to do it in a public forum allows for greater team cohesion, which means less complaining about the other team members (see above). (NOTE: This isn't my idea. I got it from Giuliani's book Leadership).
  • About pair programming: if the team members like it, then perfect! Sometimes people don't like it but don't speak up because of fear of team retribution or offending somebody. Silently disgruntled team members are awful for morale.

P.S. Great work on db4o!

The Alchemist
+1  A: 

Our Agile project management tool is Greenhopper on top of Jira. For desktop sharing we use Shared View, but for show & tell purposes, rather than pair programming. Skype is the main communication tool, but with gtalk for IM. Skype's a bit flaky when it comes to sending IM messages. I wrote a post about all the tools we use for distributed development in our company

Our sprints are week long, we used to have larger sprints, but this works well. On mondays we look back at what's been achieved in the previous sprint and carry over any outstanding work. We then add backlog stories (with estimates) to pad out about a weeks worth of work for the current sprint. There's a backlog for the current minor version and a general 'catchall' backlog.

The stories are quite minimalist, and the estimates are quick and dirty (although fairly accurate typically). They progress through 'Todo' -> 'In progress' -> 'Resolved' -> 'Done'. Stories are moved into a 'Done' state when discussed in the weekly monday meetings.

FrederikB
A: 

I was also once involved in project and we practised XP. I found Pivotal Tracker very good for planning and user stories. I would also advise you to look an BitBucket. We found is useful when used it together with mercurial distributed version control as I believe it's very suitable for distributed team.

I have also noticed that XP does not work well in an academic environment(students). Practices such as 40 hours per week and pair programming didn't work well. I was a project assessor on teams that were using XP methodology.

Overall, Agile development is good and I think is much suitable for small projects. Can work for big projects too, but will need to use the divide-and-conquer using small teams.

Integrating new people is fair easy so long as they start with an iteration or get paired with someone who has a fair idea on the already developed features.

Other things like TDD proved helpful.

walters