Microsoft recently released their Microsoft Solutions Framework Version 4.0. Part of the MSF is a process framework that presumably the tools will help facilitate and/or enforce. They are calling this process "MSF Agile." Based on some recent discussions on the XPSoCal and Agile Project Management mailing lists, following are some thoughts on whether MSF Agile is really an "agile" process.

The MSF Version 4.0 Beta site and a link to download the MSF Agile process definition can be found at http://workspaces.gotdotnet.com/msfv4 (which is pretty sparse, so perhaps I'm missing some key details).

What concerns me the most is that there is little that emphasizes core agile strategies. Similar to RUP, it sure looks possible to be agile with the MSF Agile process. But unlike processes such as XP, Scrum and Crystal, there is little that drives me towards being agile. My concern is that many will implement a non-agile version of MSF Agile, and think what they have is agile and call it that and blame agile when it has the same old problems.

For example, the core principles of Agile boil down to getting a cross-functional team collaborating together, driven by a shared vision of their goals and outcomes, to progressively ship their product in (small) steps, gathering feedback from each step and adapting their approach along the way as needed.

MSF Agile shows us five key roles in the process. These roles are mapped to the work streams they are to perform. I find no mention that these folks collaborate on tasks at all. It looks like the process suggests that the scenarios are passed off from one role to another. The Architect seems to be the one that produces architectural definition, subsystem division and even breaks down the work into tasks, while the Developer seems to only crank out code and fix bugs. There's nothing that stops the team from taking a team of developers, and assigning them all a combined Architect/Developer role just like XP. But I feel the process definition leads us in another direction.

A shared vision is supported with a specific vision statement, and a list of scenarios is maintained, so there is some notion of the artifacts that support a shared common vision. But there is nothing in the planning, analysis or development activities that suggests how the team rallies around that vision, ala the Daily Scrum in Scrum or the Planning Game in XP.

MSF Agile does seem to be iterative. It's not clear to me if the process encourages each iteration to produce a "potentially shippable increment of product." Certainly the team could act as if the "Release a Product" work stream needs to happen each iteration, but as written the key activities needed to finalize a release are only done in that work stream, and that work stream is only shown in the last iteration.

Also, as shown, each iteration has planning activities that occur in the prior iteration as well as testing activities that occur in the next iteration. As described, this looks more like a mini-waterfall that stretches analysis/planning, design/programming and testing across three consecutive iterations. A pure agile approach would limit the leakage out of an iteration, although in most projects in which I've participated some does occur (this is called a "Type B Scrum" in the Scrum world). But it shouldn't be an entire class of activities always assigned to a prior/next iteration like this.

The planning activities are scoped to occur each iteration, which seems incremental, and there is a small mention of selecting scenarios based on priority. Agilie processes emphasize primary prioritization on business value, but I'm not clear what MSF Agile recommends as the priority criteria. Although nothing states that the planning should adapt to the results of the previous iteration, the fact that planning reoccurs each iteration seems to suggest that.

There is nothing I can find about how the team locally adapts the process, for example, a retrospective step ala Scrum. Given that the process is fairly defined and prescriptive to the level of the order of activities, required activities and how to perform the activities (e.g., see any of the work stream details), I would be concerned that it would be interpreted that local adaptation of the work streams is discouraged. There seems to be no meta work streams that focus on the team or process.

OK, that's enough. My point is that I can see how I could coach a team to be agile and probably still work inside the MSF Agile process definition, the same way I could coach a team to be agile within RUP. But I have doubts a non-agile team could take the MSF Agile process definition, and become agile using it. I'm not as concerned with the lack of specific practices and tactics like refactoring or unit testing as I am with the apparent lack of emphasis of Agile principles and strategies.