During the Agile Mythbusters webcast on April 28th I was asked the following question via chat:

"Can a stand up meeting be executed via a sametime (or other message service) chats? (To help overcome language barriers for large distributed teams in various countries?)"

The quick answer is yes, but I thought I'd address the question a bit more generally with several thoughts:

1. I prefer the term coordination meeting.  It's a bit of a nit, but I prefer the term "coordination meeting" over "stand up" meeting and certainly over "Scrum meeting".  The term stand up meeting implies that you're co-located and standing, two things that don't always happen, and the term Scrum meeting is a primary example of branding within the agile community.  The real goal of the meeting is to coordinate the team efforts, so let's be open and honest about it.
2. Many agile teams find themselves in a geographically distributed situation.  Several of my IT surveys over the years, including one I ran the last week of April 2011, have found that only a minority of agile teams are co-located in the same room.  Granted, many are near located (meaning everyone is within driving distance) but a sizeable portion find themselves far located (meaning some people would have to take a flight to attend a physical meeting).  The implication is that the need to have distributed coordination meetings is a common one.
3. Communication risks increase with distance.  A significant challenge with geographic distribution is the need to overcome potential communication challenges associated with different time zones, different language, and even different cultures.  I've written a fair bit about the challenges surrounding agile and geographical distribution that you might find illuminating.
4. Pick the best communication strategies available to you.  There are a wide variety of ways that agile team members can communicate with one another even when they're geographically distributed, including online chat as the question indicates.  Each of these strategies has their strengths and weaknesses and some are more effective than others.  While online chat has the advantage that language/accent issues may be reduced, it has the disadvantage that some people are not effective writers or may not be comfortable writing, running the risk that they don't share as much information as they should. 
5. Geographic distribution is one of several scaling factors you should be concerned with.  When people think of agility@scale they think either large teams or geographically distributed teams.  Granted, these can be complicated issues to deal with but they're not the only ones.  Other scaling factors include regulatory compliance, domain complexity, technical complexity, organizational distribution, organizational complexity, and enterprise discipline.  As I point out in the Agile Scaling Model (ASM) you will need to tailor individual agile practices to reflect the situation you find yourself, and in that free whitepaper I even overview how to tailor coordination meetings based on the various scaling factors.  For example, large teams will need to have sub-team coordination meetings and then find a way to coordinate across the subteams (for very large teams you'll likely need a specific leadership subteam responsible for this).  Teams that are geographically distributed will need ways to electronically communicate, perhaps via chat or telephone calls and will likely need an electronic task board to visualize current status.  Team in regulatory environments may need to record the results of the coordination meetings, and so on.  The point is that the "Coordination Meeting" practice needs to be tailored to address the context your team faces.  This is true of many other agile practices as well.
6. Adopt tools which support geographically distributed teams.  It should come as no surprise that a geographically distributed agile team should consider adopting tools which are geared for geographically distributed agile development.  Rational Team Concert (RTC) is one such tool, with integrated chat, integrated work item (product backlog) management, electronic taskboards, and automatically populated project dashboards amongst many other features which geographically distributed teams will find useful.  Better yet, RTC is free for teams of up to 10 people with no time restrictions.

For more information about dealing with geographic distribution on agile teams, I recommend the book A Practical Guide to Distributed Scrum.  The book shares IBM's experiences developing world-class, mission critical systems applying agile strategies in scaling situations -- the book is about far more than just Scrum and just geographic distribution.

On April 28 2011 I gave a webcast entitled Agile.Everyware - Busting the Agile Myths Once and For All to the AgileJournal community (the recording and a PDF of the slides are available at that page).  During the webcast I overviewed the Disciplined Agile Delivery (DAD) process framework to provide a foundation for the overall discussion, and I then explored several myths about agile approaches which I then went on to bust using data from various IT surveys that I had run over the years. The myths were:

1. Agile doesn't work for large teams
2. Agile doesn't work for geographically distributed teams
3. Agile doesn't work fo regulatory environments
4. Agile doesn't work for my domain
5. Agile is undisciplined
6. You can't govern agile teams
7. Agile doesn't work for high-risk projects

I think you'll find the recording interesting.  Furthermore, because we ran out of time at the end to answer all the great questions people submitted over the next few weeks I'm going to answer the questions as blog postings here at the AJ site.