application blocks. These practices must be applied to distributed teams more strictly than to local teams.
For example, consider continuous integration. It can be extremely frustrating to come to work and get a broken build from the source control server, while the person responsible for this is several thousand miles away and might be asleep at the moment. What might be not as big an issue, if it were done by the guy sitting at the next table, might become a major problem in a distributed scenario. This impacts productivity and communications. Sticking to continuous integration practices and installing the corresponding server team-wide (such as Microsoft Team Foundation Server, CruiseControl.NET, CruiseControl) minimizes such risks.
At Murano Software we have internal project called "Project Portals" devoted to enhancing the communication between distributed team members and easing the access to high-level project information for project stakeholders. At first this was a pure Microsoft .NET solution. Then, Windows Sharepoint Services (WSS) came into the market and we utilized its base engine. We advise other software development companies to take a look at hosted or in-house WSS solutions.
Wikis naturally fit and help agile development in distributed teams, so we developed our own wiki for our Project Portals and integrated it into the WSS solution. The next version of Windows Sharepoint Services is planned to have wiki among its standard features, so you have a chance to get it as a perk.
Teams working on the Microsoft .NET platform are in a great position with the features provided by Visual Studio Team System (VSTS) right out of the box. These features help you to maintain a lot of best practices mentioned in the beginning of this section. Consider the VSTS source control system. To say that it is a leap ahead SourceSafe will not be sufficient. Besides the common source control features, which you usually get from the market leading software packages, with Team System you also get an opportunity to set up check-in policies. Have you ever had the frustration of checking out a build in the morning that does not compile? Now you can set up a policy which will force developers to test build the project before checking in. You can also force them to run unit tests.
Both build routines and tests merit attention. If you are familiar with NAnt or another modern build engine, you will understand the usability and flexibility of VSTS builds. What may intrigue you is the fact that VSTS has build management capabilities and reporting with the power of one integrated platform. Similarly, if you are familiar with NUnit or another modern unit testing tool, you understand the basic unit testing features of VSTS. But VSTS is also full of goodies for us. Besides basic unit testing, it includes web and load testing, test coverage, static code analysis, bug-tracking, test cases management and tracking. And once again, we get additional benefit of having one integrated platform. Add project management features, Dynamic System Initiative (DSI) diagramming tools, reporting, customizability, integration with MSF for Agile Development, available books, support, documentation and education and you will get an idea why there is a buzz around VSTS. WSS is also tightly integrated with Visual Studio Team System and you can use these features right out of the box without the need for custom development.
On our Java projects we use de facto standard open source products like Subversion, Ant, CruiseControl and JUnit combined with the same communications infrastructure we use in our .NET teams.
From an IT infrastructure point of view, our teams use a VPN to provide equal