Developing software in teams is not easy. Often you have to use components implemented by other developers, and a lot of time is wasted and nerves frayed in figuring out interface issues, and isolating defects. Over the years, I have used parts of the following techniques to mitigate these risks. These, like most software practices, are not new.
Step 1. Define component interfaces. This typically should be a part of the design process.
Step 2. Write mocks for the components.
Step 3. Write the glue code that ties the components together and build your complete application. At the end of this process, you should have a fully functioning system. True, one that does nothing useful in particular, but one that works end to end.
Step 4. Write tests- unit as well as feature - that exercise this system.
Step 5. This would also be a good time to add a (continuous) build framework, say built using Ant/Maven and CruiseControl that fires off nightly builds and tests.
Step 6. Now hand off these components to individual developers for the actual development.
At any point in time, the whole system should build *and* run. The tests (defined earlier, and refined with time) act as regression. At the end of the process, there should be far less integration issues, and faults would be easy to isolate to individual components by replacing a component by its mock (say using a factory, or a Avalon type component framework)
This approach is similar to a children's coloring book in which the outline of the picture is drawn first, and then the child (or different children) can color in each part independently- hence the name.