Sometime in a previous (professional) life, I worked for a company that used Microsoft Solutions Framework. This was a very long time ago and I don’t even remember the company. As a development framework, MSF didn’t really impress me much at the time, but there was one key element of MSF that did impress me and has stayed with me all of these years.
It may be that I wasn’t that impressed with MSF because the
company that was using it wasn’t the best candidate for it. MSF is ideally suited for software
development for distribution (i.e., to consumers). My client (employer?) was using it to develop
software for internal use. Further, they
weren’t set up with the appropriate infrastructure and architecture for daily
builds. It was good they were using a
development framework, but other choices would most likely have been more
appropriate to their organization.
(This paragraph is an attempt at sarcastic humor.) I have never used MSF in, what I would consider,
an appropriate context for MSF. However,
Microsoft has years of success using it to deliver reliable, user friendly,
quality software on schedule. Therefore,
I will accept their experience as its endorsement.
Nonetheless, I got training on MSF at my client. As a framework and not a methodology, MSF is
(intentionally and appropriately) light on the “how” of software
development. One area of the framework,
however, is fleshed out in particularly specific detail: the MSF Team Model. The MSF Team Model has several favorable
attributes: it is specific about the
roles (and responsibilities of those roles) that must be represented on the
project team; it is specific about the relationship
of the team members to each other; and
it intentionally creates conflict between roles to establish natural “checks
and balances.”
Prior to my training on MSF, my experience with building
project teams was to have the “right” people.
But that is unabashedly vague.
Further, we may know that the team members we have are the right people,
but how do we know what right people we might be missing? The MSF Team Model resolved this weakness in
my experience and practice. Further, I
know of no other framework or methodology that puts such emphasis on composing
the team.
Therefore, as a Best Practice, I want to pass on the
benefits of the MSF Team Model and strongly recommend that you consider the MSF
Team Model on your projects. More
information on MSF and the Team Model is available in Microsoft Solutions Framework Essentials
by Michael S. V. Turner (Microsoft Press, 2006). Chapter 4 discusses building an MSF Team.
Have you had experience with MSF? What is your opinion of the Team Model?
© 2013 Chuck
Morton. All Rights Reserved.
