One of the questions that I received during my Agile Journal webcast in April was “Can you address how to create firm fixed price quotes in response to commercial RFPs?”  The good news is that I’ve written a fair bit about funding strategies for agile projects and have been really clear about my disdain for “fixed price” projects. To make my position clear, when it comes to doing a “fixed bid” development project where the customer requests that the scope, price, and schedule be defined up front, I personally believe:

1. It is unethical for teams to do fixed bid projects.
2. It is questionable at best for customers to request this, and grossly incompetent if they’re a “repeat offender”.

Having said that, I want to make several important points:

1. I want to make it clear that this is my personal opinion and not that of the organization that I currently work for, IBM. 
2. This opinion is based on the overwhelming evidence which exists showing that “fixed bid” development projects are spectacularly bad ideas.  I summarize this evidence in The Dire Consequences of Fixed-Price IT Projects and summarize data from a recent survey in Survey Shows Unethical Behavior Inside IT Development Teams.  Note that the second article doesn’t directly address fixed-bid projects but instead explores some of the behaviors which fixed-bid projects motivate amongst IT teams.
3. Yes, it is possible to do fixed bid agile projects, as I describe in Agile on a Fixed Budget, and such an approach will increase your chance of success, but it’s still an incredibly bad idea.
4. The reason why we still have IT procurement people inflicting fixed bids upon us is because they don’t understand the implications of what they’re asking for and this in turn is because we don’t take the time to educate them as to their folly.  So, if you’re in such a situation feel free to share this blog posting with them.

If your organization would like to understand the implications more thoroughly I’m happy to discuss it with them.  Feel free to email me and we’ll set something up.

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.