The only problem is that most developers already work in a team: a team of one. The nature of programming is such that there are some tasks where you can not divide the work down any further. For example, if you are working on a data-entry form with code behind to do some sanity-checks on the data entered (phone numbers, credit cards, etc.) you probably couldn't have more than one developer working on it at any given time.
Most developers are used to this type of discrete task, so even when they teamed with other developers they are used to working alone. And therein lies part of the problem with introducing a team-based development environment. While you can teach developers who to use the environment and toolset it provides, there is no training on the market to teach developers how to actually work as a team.
A lot of that training comes on the job, or through good management of development resources. And good management can sometimes be non-existent, especially with contract projects where a number of developers are hired to just cut code, under the supervision of a project manager who is not a developer themselves.
So my theory is this: if you want to move to Team System, invest the time and effort into creating a cohesive team first. Spend the time getting to know each developer's work style and current workload and determine if you need to put a development manager in place to manage the internal or external resources. Then when you have the goals, roles and responsibilities within your development team settled, you can start looking at training them to use the tools to make it all happen. You'll get much better results from the team and they will be able to use the tools in Team System to their full extent.