While driving yesterday, I was listening to a Podcast by Alistair Cockburn (pronounced, I learned, like Coburn, not like an uncomfortable genital condition).  He was discussing Agile development, something I'm very interested in.  One of the things he's learned over the years is that "People trump process".  Basically, if a process is too confining, restrictive or proscriptive, people will always find a way around the process.  In addition, if the process is too chaotic, people will spontaneously create something to add a light structure to their development process.

This has dramatic implications for Team System.  One of the onerous tasks in many process tools is reporting work.  Developers are forced to not only leave their tool (Visual Studio, Eclipse, etc), but also often forced to enter data that doesn't seem to relate directly to the task of creating good code.  In Visual Studio Team System, process is tightly integrated into the development process at the tool level.  Thus, it takes far less effort for developers to implement process.  In fact, process guidance can be automated into the way Team System behaves, not just in the form of must-read references and directives.  This means developers can be exposed to process in a way that often fits their personality.  Most developers I know aren't the type of folks who want to read corporate process guidance.  They want to solve problems.  When a process methodology intrudes in Team System development, forcing devs to write unit tests or run code analysis prior to a check-in, for example, the developer treats the problem differently.  Now, although they may moan about it, the problem becomes a challenge, a bug, and they figure out a way around it.  Thus, devs are exposed to process periodically, throughout their development lifecycle, as a series of challenges, not as an "all or nothing" read of hundreds of pages of corporate process, procedures and conventions in document form.

This, I believe is one of the strengths of Team System.