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

Posted by Deborah Hartmann Preuss on Dec 14, 2007

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Visual Studio Team System ,

Visual Studio ,

Continuous Integration ,

Artifacts & Tools ,

Application Lifecycle Management ,

Agile Techniques ,

Tools ,

TDD ,

Methodologies ,

ALM ,

.NET ,

Microsoft ,

IDE ,

Roles ,

Programming ,

Testing ,

MSF for Agile ,

Enterprise Architecture ,

EssUP ,

Agile ,

Companies ,

AUP

Share |

RELATED Research

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.

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   How Would This Work?

   by Greg Helton

   Paragraph 3 refers to the "MSF for Agile template" for Scrum. Given that this is Microsft's interpretation of Agile, this is, no doubt, an MS-Word template?

   Reply

2. Back to top

   Re: How Would This Work?

   by Deborah Hartmann

   I believe the MSF for Agile "templates" are a set of work items, roles and processes allowing a team to use MS's version of an Agile process. I don't know how closely their Scrum template approximates what's taught in the CSM, though.

   Reply

3. Back to top

   Re: How Would This Work?

   by Jeff Hunsaker

   Deborah is accurate with her description of how process templates are implemented within Team System. Process templates FAQ. It's expected that an enterprise will take the OOtB template and assuage it to accommodate the local process.
   
   Also, Conchango produces an independent, free SCRUM for Team System process template. This is the only Team System SCRUM template I'm aware of.

   Reply

4. Back to top

   Re: How Would This Work?

   by Deborah Hartmann

   Thanks Jeff.
   
   Are you familiar with both the Conchango plug-in and the CSM course? Can you tell us how closely they match?

   Reply