I would like to adapt my development team from a very singular development team (one large development per developer), to distributed workload (on the same projects).
Has anyone else undergone this change? What is the best way to implement seperation of work, team-spirit, documentation etc?
Communication is the key. Make you speak to your peers often. Its quite easy for people who think they are working in harmony to go dark and do completely seperate thing.
Try Pairing. Come up with some coding standards and stick to them. Constantly communicate to see if you are all on track.
Make your projects work-unit based. Break big tasks up into smaller tasks. Then, assign each of the smaller tasks to your team members.
Make sure you have collaboration tools in place (Wiki, notes, source control, etc.).
This is what tools like Redmine, Jira, FogBugz, etc. are designed to help with.
Concurrent version control also is very important. Being locked out of a file is not acceptable in this day and age. Generally you still will want to separate developers to areas (files) in an application but there will be overlap. A good diff and good processed for merging files helps in these situations.
Other than that most of it is people skills, keep communication open, try not to play the blame game, team spirit and all that.
Are you sure that you get more productivity out this way? Developers tend to be loners and don't like much this constant communication and "team-spirit". Of course there are exceptions, but if they have so far worked independently then maybe that's the way they like it and forcing them to talk to other people will freak them out :)
The greatest challenge here is to move from a focus on individuals to a focus on the team. Your guys have to associate themselves with the output of the team rather than just their own personal contributions and this process can't happen overnight. In fact the transitional stage is likely to lead to drop in productivity while people get up to speed.
After that point though your the benefits are significant, not least in being better placed to respond to change and generally disseminating good practice across the team as a whole.
Firstly daily stand ups really help drive interest in projects at a team level, the guys started to actively suggests ideas and approaches to one another that could then be followed up on outside of the stand up.
It's been mentioned elsewhere on this thread but I would also recommend pairing as a great way to transfer knowledge between developers.
Having a team chat room, irc or similar is useful for asking the team questions asynchronously in a public/team arena without continually interrupting individuals.
In terms of documentation, well I guess it depends on what you're after. For internal docs wikis actively encourage collaboration and are easy to maintain. As for external docs well you'll have a team that better understands the project who are then better placed to make sure that the docs are clear and accurate, though you may have tech writers to help here as well.
Finally it's really important to make sure you contextualise priorities in the broader scope of the team so even if you are holding back on one project it is clear why this makes sense on a team view. To this end it may be that a time boxed approach such as Scrum will help here though if you're not doing this already I suggest the previous suggestions as a low impact set of first steps.