Microsoft does agile - sort of
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.
Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.