Why did Microsoft create Team System?
It's sort of an open industry secret that Microsoft created Team System to address the shortcomings of their existing internal tools* and processes. There's an excellent new whitepaper on Microsoft's site, Deploying Visual Studio 2005 Team Foundation Server as an Enterprise-Wide Service Technical Case Study, that explains:
Microsoft has tens of thousands of software developers, usually working on over a thousand development projects. Project teams can consist of project managers, business analysts, application architects, software developers, and software testers.
In the past, the project teams found it difficult and time-consuming to coordinate their efforts because their tools were not well integrated with each other. The project teams closely coordinated their products (output) to help ensure compatibility and interoperability, but, in the past, did not coordinate or integrate their project planning or reporting to a high degree. All the project teams used similar methodologies and tools, but these were usually somewhat different and generally not integrated.
Each project team developed and executed its own project plan, sometimes using nonstandard methodologies. Within the projects' separate project plans, there were often variations in the work items being tracked or different definitions of the same tracked work items. For example, the definition of how to calculate "percent of work completed" would vary significantly between projects. Some projects tracked "bugs," whereas others tracked "defects"; some scheduled according to an 8-hour day, and others scheduled according to a 10-hour day. Work items were tracked separately within each project.
The smaller development teams used commercially available products, such as Microsoft Visual SourceSafe, for source control and version tracking. Larger teams used a set of internally developed tools for work item tracking, source control, version tracking, and bug tracking. These tools were all operated separately, on separate servers, and were difficult to manage. The IT groups planned infrastructure for each project's tools separately. The architecture and infrastructure made integration very difficult.
Each project team had to deal with separate support teams for each tool. Each tool-centered support team had to deal with hundreds of project teams. There was some confusion about which support team was responsible for which problem.
Each project team had to arrange separately for production and management of its Microsoft Windows SharePoint Services collaboration site. The team had to work with a separate SharePoint Services group to build and host the project's SharePoint portal. This portal was not integrated into the source control or bug tracking systems. Information had to be manually transferred to the SharePoint site, or some custom automated integration had to be built.
Each project team also had to construct and manage its own build machines and test rigs. The test rigs were not standardized or stored, so they were different for each project team. The build system used custom scripts and tools constructed around the internal source control system. Each team had to manually manage the build process. The results from the separate projects were not coordinated.
It was impossible to report across projects. For project tracking at higher levels of the organization, the individual project summaries had to be collected and manually compiled into reports, or customized automation had to be built. There was much duplication of reporting efforts. Because there was so much variation in information between projects, including the item definitions, it was difficult to relate items—work items, processes, artifacts—or confidently compile summary information. Much of the important communication within and between projects was not captured, because it was performed on the telephone or in face-to-face communications.
The cross-project reporting problems made it difficult for upper management to make informed decisions about the various projects individually or development projects as a whole. There was no operational transparency into a project's details. Also, the reporting problems made it difficult and expensive to comply with statutory requirements, such as Sarbanes-Oxley, which requires proof of "an adequate internal control structure."
The good news is that Microsoft is "dogfooding" Team System right alongside its customers. They're using it heavily; more and more Microsoft internal projects are transitioned to Team System each day. And many of the improvements-- like those cited in the latest Brian Harry dogfooding stats-- will trickle down to customers in the form of service pack 1.
The bad news is that your organization may not have "tens thousands of software developers" like Microsoft. Microsoft's problems may not be your problems. But if you develop a lot of software, it's highly likely you're struggling with many of the same issues-- and Team System can help.
* Including Source Depot, Product Studio, etc