The seating chart

What formation is your team in during the daily stand-up meeting? Hopefully it's close to a circle, where each team member can make eye contact with every other team member. Many studies have shown that a significant amount of the information conveyed in a conversation is non-verbal, so make sure everyone is getting the full story.

Is everyone facing the leader/scrum master? This could be a problem. The leader should be a facilitator for the meeting which is held primarily to share information among all the team members. It's not just a status report to the leader/facilitator.

For longer meetings such as iteration planning sessions, pay attention to the seating; the same principles apply. Arrange chairs in a circular or semi-circular fashion.

The 3 Scrum questions and the language impediment

"What is your name?"
"What is your quest?"
"What is the velocity of an unladen swallow?"

Wait, sorry - those 3 questions are for the bridge of death - they have nothing to do with agile software development.

One of the 3 questions each team member answers during the daily Scrum (daily stand-up meeting) is, "are there any impediments to your work?"

I am currently working in China with a team building a web app for a US-based client. One of our impediments is the language barrier. In fact, the word "impediment" itself isn't in the vocabulary of my Chinese colleagues. So how do you ask if there are any impediments?

I ask if they have any "problems or issues", but that's not quite the right. As the scrum master/agile coach, I've found that the following question hits the mark:

What can I do to help the team?

With those eight short words, I've found that I get much more insightful responses, and can root out some important impediments.

One developer per feature

When you're planning an iteration, you start with user stories, break them into tasks, make estimates, commit to the iteration scope, and then begin working (as a collaborative, sel-organizing team, of course).

My past 2 project teams have both concluded that it's better to have 1 person (or pair of programmers) develop an entire feature than to have different people working on different sub-tasks. Avoid the temptation to break a story into layered tasks such as "build the DB", "build the domain objects", and "build the UI" -- with each task worked by different people. You may have people who specialize in only one of these layers, but your team will be more productive and flexible in the long run if everyone has broader skills. Besides, having 3 different people working on 1 feature requires lots of coordination and presents lots of opportunities for miscommunication. Instead, have one person (or pair, for you pair-programming zealots) build the whole shebang.

In OO development, we aim to minimize coupling between components and maximize cohesion within components. This is the same concept. Each developer is a component of the team, and you want to minimize the amount of coupling required between developers; when coupling (communication) is required, you use the most effective means of communication possible - face to face conversation. At the same time, you want to maximize developer's internal cohesion - by letting him/her focus on a single feature.

Of course, to do this, you need to have stories/features which are small enough for 1 person to complete within a single iteration. But that's a worthy goal for many other reasons, too.