'MSF for Agile' with MS VSTS - Worth a Look?

We've not heard much about Microsoft's 'MSF for Agile' for a while. In this InfoQ video, Building Better Apps, consultant Kevin Jones spoke at QCon from his experience using MSF for Agile with Visual Studio Team System (VSTS). Using examples from Agile teams, he walked through the layers and components of Microsoft's process and development toolsets, explaining how to make use of their flexible architecture to accommodate a team's specific process needs. This flexibility is a constant theme - is it enough to convince Agile teams to use it? Might be worth taking a look, but read on for some caveats.

MSF for Agile is a reworking of the original Microsoft Solution Framework methodology popularized in Microsoft certification exams of the late 90's.

Methodology is not hardwired into the toolset. For example, a team using Scrum could use the built-in MS "MSF for Agile" template, a third-party Conchango Scrum template, or create their own template for their specific flavour of Scrum.

Although the VSTS client has different Tester, Developer, and Architect editions, the Team Foundation server is designed to handle many project roles within the same process. And in MSF there is recognition that people may wear many hats on a team, and roles are not tightly coupled to activities within the templates.

Team Foundation server includes configurable workflow. The work items that flow through a process are flexible - teams can use the templated work item types, which for Agile are Bug, Task, Scenario, Risk and Quality of Service - or define their own. Teams can organize how work items flow through their process in a way that corresponds to their own philosophy. Functionally, work item handling is not rigid - it's possible for the person doing the work to create their own work item.

MSF's flexible process definition sounds similar in approach to Ivar Jacobsen's Essential Unified Process (EssUP) and IBM's Eclipse Process Framework (EPF). One concern, of course, is whether it's necessary to run a whole customization project to create a process before the real project work could begin.

When Jones gets specific, he generally uses examples from Agile projects. He admits that it's a V1 product, with known lacks, which he points out during the presentation. For example: out-of-the-box, it doesn't support continuous integration, which can be resolved with a plugin. It doesn't support scheduled builds, but there is a workaround. Version control is apparently weak - it supports branching and merging but handle tagging as VSS did, not in the powerful way that, for example, Subversion does. He mentioned the workaround necessary for code review: out of the box, it seems code must be checked into source control before it can be reviewed, but it must be reviewed before it can be checked into source control! A workaround using the code repository to hold a version of the code without merging it solved this for Jones' team.

Jones sounded optimistic about the possibilities for Agile teams using MS tools, and he anticipated resolution to some problems in subsequent versions.. However, this talk was recorded in March 2007, and whether those shortcomings noted have been corrected since then is unclear - Microsoft's Process Guidance page still indicates V1. In addition, subsequent events reported in June drew attention to developments whereby MS tools may be becoming less TDD-friendly. Reader feedback would be useful here - have you tried it? Would you recommend it?

The suite includes integration with a build server, source control, MS-Project, and MS Sharepoint portal, etc.

For teams considering or already committed to Microsoft products, this video provides an experienced view of how to use these tools and may be worth a look. View the InfoQ video Kevin Jones on Building Better Apps from QCon London 2007.