Microsoft does agile - sort of

• By Mike Gunderloy
• February 17, 2005

For quite a while there's been a big split in the universe of methodologies for developing software. On the one side, you have heavyweight methodologies that specify a lot of process: one thinks of the classic waterfall methodology as well-documented by NASA, or the work of the SEI in coming up with the CMM here. On the other side of the split are the newer "agile" methodologies, of which eXtreme Programming (XP) is the best-known (or perhaps that should be "most notorious") example, though there are plenty of others.

Microsoft, too, has a methodology: the Microsoft Solutions Framework. Originally promoted through the company's consulting arm, it's become a more general offering, a Microsoft-endorsed way to create software. It's also clearly a heavyweight, emphasizing process and plenty of distinctive roles and documentation. But now Microsoft says its changing somewhat. With the coming release of Visual Studio Team System, Microsoft recognizes that quite a few developers find agile methodologies productive and useful. So: they're releasing their own. They just made Microsoft Solutions Framework (MSF) for Agile Software Development, Beta for download. I grabbed a copy for a quick look.

Microsoft's quick description of the new process is "MSF for Agile Software Development is a scenario-driven, context-based, agile software development process that utilizes many of the ideas embodied in Team System." What the tail end of that description appears to mean is that the major concepts (such as bugs and risks) are explained in terms of the fields that need to be entered into the Team System database. While that's necessary low-level information, I would have preferred a bit more high-level discussion on things like the granularity of bugs and the identification and nature of risks.

As far as the delivery of software itself, those looking for a self-organizing process resembling XP or Scrum are going to be disappointed. I don't see any sign of stand-up meetings, stories (though they do emphasize small deliverables and shipping usable software, without discussion of what an appropriate increment of functionality is), pair programming, "you ain't gonna need it," or continuous integration. There is a formal structure of well-defined roles (business analyst, project manager, architect, developer, release manager, tester). Notably absent is the actual customer, who is central to many other agile methodologies. Refactoring does come into play as one of the core activities for developers

Most of the emphasis here seems to be on defining the work items that each role performs and how they fit together into work streams. To my mind, this seems a very rigid process, especially contrasted with the self-organizing nature of most other agile methodologies. There doesn't seem to be a notion of getting out of the way and letting the team build good software.

Finally, let me mention that it's a bit tough to be sure I've adequately covered what Microsoft is delivering here because of the form they chose. Rather than use a Word document, what we've got here is HTML with some sort of fancy-schmancy active content that doesn't work worth a darn in any browser other than Internet Explorer. Even in IE it's tough to be sure you've seen everything because of tabs and menus nested three levels deep. Someone needs to rethink the information presentation in terms of making it easy to follow from start to finish, rather than making the gradient fills look pretty.

Overall, I think all-Microsoft shops that are already experienced with "full" MSF will likely see MSF Agile as an interesting alternative for less-structured projects. But those experienced with other agile methodologies are not likely to be too impressed.