Does Team Foundation Server is an “agile” tool?

I have received this question from my good friend Scott Bellware:

I'm listening to your latest podcast with Claude Remillard about application lifecycle management with TFS and the value propositions from the Manifesto for Agile Development keeps coming to mind: "Individuals and interactions over processes and tools". At some point in the un-defined future, I'd love to do a Visual Studio Talk Show episode where we talk about the differences between agile development projects and traditional development projects.

I have this nagging question... If it's so clear and understood that agile development values individuals and interactions over processes and tools, then it seems that Microsoft is contradicting itself by releasing an agile template for TFS that is intended to run in such a heavy-weight tool. I have yet to hear anyone in the community who presently specializes that in TFS adoption, deployment, and operation that TFS is applicable to agile teams and agile projects. I hear folks saying that TFS is applicable to "more agile teams" and "teams that are a bit more agile", but these are relative terms. I assume that this means that TFS is applicable to teams that are "more agile than waterfall, but not really agile in a way that reflects the values expressed in the agile manifesto." I don't hear TFS specialists saying things that suggest that they are questioning TFS's applicability to agile development rather than simply accepting Microsoft's assertion that TFS and agile go together.

It is a very relevant question “Does TFS is an agile tool”. My answer to this question is YES. Of course, you can also take TFS and apply waterfall process. It is allowed. The tool can support any processes. However, in this case, the default reports included with the product are not really relevant any more. In any event, the organizations following waterfall process do not care about these reports. They have other monitoring documents to produce to respect their process… Garbage in, garbage out. Microsoft wants to sell to everyones, the goods and especially the bad ones because it is there that there are more purchasers (unfortunately).

TFS is agile if you assert yourself a process with the 3 following attributes:

1. Fixed time-based iterations which do not exceed a month: There can be a vision of the functionalities with a timeframe longer than one month but it is not a detailed plan. The only detailed plan is the one for the iteration in progress.

2. A strong commitment to accept changes required by client: With this intention, one must apply development practices which protect against changes such as continuous integration and regression tests automation.

3. A design directed by testing (quality): At least, tests should be in first before the code. It is still better if the team applies development practices such as TDD.

These are the 3 pillars in my opinion that define an “agile” approach. TFS can enforce agility because it makes transparent the work of the developer in regard with work item tracking. It promotes the individuals and the interactions over processes and tools.The developer does not have anything special to do except is normal work (test-code-refactoring), the tool automatically track information at the time of check-in, tests, build, etc… Moreover, the fact that TFS recognize the whole set of roles to be filled to deliver quality (dev, tester, analyst, project manager, architect, user experience specialist, configuration manager, etc…), it is a very explicit way to promote the individuals and the interactions.

At all events, it is certain that me and the others “pragmatic agilists”, we will continue to promote TFS as an “agile” tool while others will continue to promote open source tooling as the “agile” approach. There is nothing new under the sun.