We have been using scrum very successfully too, using 2 week sprints. we do the stand-up meeting, then we also do a code review of all code commited to our svn trunk the day before. We meet every 2 weeks for a planning session for the next sprint and prioritize our backlog of issues for that sprint. then we self- assign tasks, determining requirements along the way.

The biggest advantage I see to an agile approach is that rather than make all the decisions at the beginning(when we know the least-in the traditional waterfall approach), we make decisions as we need too, sometimes waiting until the last “smart” moment to decide.

another important aspect is to approach the ‘must’ items first. if there is a piece that will cause the whole project to fail if it is not achieved, we want to know at the beginning, so the plan can adjust. In traditional approaches, you lay out all that needs to be done, and often start at the beginning (for example with user log on) rather than the core functionality that will determine if the project fails or succeeds. if this means that we spend 5 minutes now simulating login with a hardcoded password, rather than a day to really implement a solution. its ok.
no one wants a project to fail, but why waste time on incidentals if a ‘must’ item can not be completed.
If the project is going to fail, its better to fail as early as possible.

@doug Now does everyone you work for in your same office? Any remote people?