Working on a project with multiple developers can be challenging. It requires collaborate and organization in order to take advantage of tasks that can be done in parallel and keep everyone on the same page. If you’ve ever tried to do this on CRM project you’ll find that as you add more developers to the project you quickly reach a tipping point where it becomes very difficult for them to not step on each other’s toes.
Dancing on someone else’s toes

If you’ve ever heard anything like “Hey I made that form customization yesterday and now it’s gone!” then you know what it’s like trying to work with multiple developers on the same CRM solution. The additive nature of CRM solutions makes it very easy to overlay changes from one WIP (work in progress) solution on top of another developers work.
The typical environment setup is to have a master tenant solution organization and then each developer receive a working copy of that solution on their on VM. As each developer completes a task that work is imported into the master tenant. In some situations work is best done directly on the master tenant out of the risk of work being lost during a WIP solution import.

Task Based Division of Work

It makes sense that when working with multiple developers on a project that they ultimately end up taking on certain duties in the project in order to allow them to become more proficient and familiar with that area.
For example there may be a developer that is assigned with making all the ribbon changes, another dev in charge of upgrading JavaScript from a previous version to the current version, perhaps another developer working on custom web apps. By doing this you also provide for a mechanism to diminish the conflicts that can arise when something that one developer does overwrites something that another developer is working on.

Entity Based Division of Work
When multiple developers are working on the same entity there are a couple of ways to help prevent developers from overwriting each other’s changes. If the option is available with multiple lines of business then if multiple user forms are an option then each developer can focus their work on a particular form versus having a single form while showing and hiding tabs/sections based on the user’s role/business unit. The downside of this method is that most likely there will be common elements between each form which will have to be duplicated between the various forms available.
Technology Based Division of Work

Another way to segment the work on a CRM project is for specialized functionality to be encapsulated into Silverlight or ASP.NET components. These components can be worked on by developers independently while minimizing form customizations. This also can be useful if you have developer on your team that are not highly profecient at CRM. This allows them to focus on their core knowledge base which may be ASP.NET or Silverlight while being assisted by CRM knowledgable developers.

In my mind if there was a better way to specifically target a solution component and have that work be more closely tied to TFS then it would be easier for developers to work without fear of overwriting . someone else’s changes. The problem is of course that you can export an entity for example, but you can’t just say I want one of its forms , views, reports, etc. If this were possible then the work could be more granularly assigned. Maybe that day will come sometime in the future. For now we have to just be careful and developers need to make sure to stay out of each other’s way.