As the number of good programmers in natural sciences is relatively low as compared to other programming projects, I think it is good to pick a model that suites the team. In these situations, I do not think coding style matters too much (write unit tests first or last, ...).
I am involved in two large chem- and bioinformatics projects: Bioclipse and the CDK. There is a bit of overlap in developers, but still both projects use different development models. Both development teams are scattered around the internet.
But what does matter very much is communication. This makes the following components important:
choose a version control system: I would recommend Git; it does require some training, but there is plenty of information, and we all have good education to start with.
choose a bug track system and make this your main development communication channel: it works independent of individual developers' time lines.
have mailing lists to discuss issues in more detail, ask for advice, etc
choose coding standards: these can be small and large, and are aimed at removing getting annoyed to much about others coding styles
put persons in charge and have them take responsibility over the code
The CDK even adds to this that code is reviewed before it gets into the main version. Git makes it very easy to developed in such a distributed way (not just in location, but also in time). The person in charge is the gate keeper and decides how and when code gets incorporated into the main version, and ensures everyone lives up to coding and project standards.
Wikis, blogs, waves, etc are useful for documenting things. More important is to add proper documentation to the source code.
Question 2: (if I've understood correctly the "how do you work together with your teammates?") Our team members have very different roles and it is mainly one person actually coding. So we don't need to share code etc. When it comes to the communication part, we rely on different tools:
We have lots of individual projects, but thematically close to each other. Individual means, there is a lab leader who brings the idea, a PhD student who brings them to life, and a postdoc for troubleshooting. Plus eventually one to few undergraduates who are supposed to work with the result.[?]
We are using a portfolio of Agile-inspired techniques to keep everything neat. In my opinion, using a version control system (SVN, GIT, Bazaar) is a must. For half of the projects we have unit tests and do TDD (these tend to be more successful - an observation not a causality). For implementation, we are doing Pair Programming and code reviews frequently. Sometimes we use Trac, iterations, and Kanban.
For communication, I couldn't do anything without a whiteboard and several pin boards in the lab.
We are using 37signals' Basecamp and Backpack to exchange data, results, ideas and other staff. It's not free, but not so expensive. As for codes, we usually have individual projects. All techniques as in Pierre's answer. :)
To put my answer in context: I work in industry. I've worked in both small biotechs and large pharmas. I am not the coder on the projects I work on- these days, I'm the project manager. Earlier in my career, I was the "translator" between the scientists and the programmers (that job has had many different titles, and was rarely my sole job function).
I have found various permutations of agile programming to be the most successful. The one exception to this has been when I've worked on projects in the more heavily regulated drug development (vs. drug discovery) arena. In those cases, the internal processes have often required a waterfall-like process. For awhile, I specialized a bit in fitting the agile-like development approach favored by my programmers into the waterfall process required by corporate policy.
Like Melanie, I've worked in industry as a programmer, as a product manager, etc. In my experience, an iterative, "agile" (without getting dogmatic about what agile means) works way better than the waterfall models. In a research driven environment with constant change, incomplete requirements and needs, I would argue it's the only good way.
The other key point, don't go for all the features you can, since chances are you will need to re-implement parts anyway.