≡ Menu
Pawel Brodzinski on Software Project Management

MSF: Version 4.0 versus Version 3.1

I’ve worked with different concepts taken from Microsoft Solution Framework since year 2000, so I can say I know MSF rather well. Most of the time it was version 3.x (3.0 and 3.1) of course, but I’m also familiar with fourth version delivered with Visual Studio 2005 Team System. However, when I accidentally went to MSF website I was surprised a bit. A lot of marketing babbling why MSF is so fantastic, a lot “we’ve integrated it with Visual Studio” stuff, instead of plain old white papers. That made me thinking once again about the way MSF went lately.

Differences between 3.x and 4.0 versions of MSF

Well, I shouldn’t be surprised. When I consider it, Microsoft just follows their MSF roadmap. A main milestone in version 4.0 was (I believe) to provide implementation for a whole idea described in version 3.1 and add some improvements also. What a nice goal to achieve. And they made it. I just wonder if the direction was right.

MSF in its origins was a toolbox. You could take from the toolbox tools you needed and use them in a way you wanted to implement your software development process as you liked. Now, MSF 4.0 replaced well-known toolbox with an IKEA pack – bunch of tools and parts and a detailed instruction how to put it all together, all within a single box. No place for your own invention. Microsoft delivers you a scenario they think you should work with. Of course you can work on your own implementation of MSF 4.0 customizing MSF process, so at the end you can have it done different way. The same is with furniture bought in IKEA – you don’t need to follow the instruction, but because whole process was designed to follow it, every other scenario requires more effort.

If I had to summarize a difference between MSF versions in one single sentence it would go like “MSF 4.0 is implementation of MSF 3.x, a kind of hardening it.”

What’s in it for me?

A reason why I don’t really appreciate new MSF, yet still permanently praise its older version is entry level. Implementing most of the concepts packed into MSF was rather easy – it could be done step by step without rapid rearrangement of current development process. Daily builds? OK, let’s look how we can adjust our build process. Risk management? Sure, maybe one of our tools can be extended with that functionality or maybe it’ll be enough to have a dedicated Excel sheet. Roles? We have to think for a moment if a team suits well to MSF role model, probably we should change some task assignments. Development cycles? OK, that’s where a lot of work should be done, but it’ll pay of.

With MSF 4.0 the implementation process is whole different. You need to start with implementing Visual Studio Team System. No, you need to start with buying VSTS, which can hardly be called “cheap” (I’m very tactful here). OK, let’s leave VSTS overcharging, a lot has been written on that subject. Suppose you’ve already implemented Team System and chosen scenario (Agile or CMMI) you want to follow. Now, you have to do most of work with adjusting your development process at once. It’s all tightly integrated so it’s hard to choose a single piece, than another and so on. Hey, it’s specific implementation now, not the toolbox any more. So better spend time on intensive training, than supervising and correcting whole process. Forget step by step approach.

That’s the easier case. You can find that neither of two methodologies (Agile or CMMI) proposed by Microsoft suits you well. Then, you need to choose one and customize it into something you want to achieve. You can also think about developing of your own process within VSTS if you like (and have a lot of money to spend). That’s heckuva lot of work, but no one forbids you to go that way.

Target customers

I’m not sure if Microsoft did it intentionally (looking on VSTS price model I think they actually did), but MSF 4.0 is for big organizations. If you have a dozen or two of developers don’t even think about that. You most likely don’t need all the stuff new version brings and almost for sure you don’t want to spent as much money for implementing MSF 4.0. You aren’t the target customer for guys from Redmond. You should rather look on MSF 3.1 which is perfect for small companies. On the other hand if your company has hundreds of developers and mature development process MSF 4.0 is probably a wise choice.

Reasons of change

I haven’t changed my mind about MSF as a whole; I just don’t like the place where Microsoft took it. Why they did it? I can’t be sure, but I believe they had wide range of reasons. My guesses are:

• Leveraging VSTS premiere. MSF 4.0 and VSTS are tightly coupled. New MSF can hardly live without Team System.

• Addressing MSF to large companies. MSF wasn’t considered as methodology appropriate for big software companies. Microsoft struggles to change this opinion.

• Limits in old MSF scalability. That’s just a speculation, but probably Microsoft faced some scalability issues with MSF within the company. I see some weaknesses of version 3.x in the area of arranging information – with version 4.0 a newbie in the team has a lot easier to find out what she has to do.

• Monetizing MSF success. MSF became quite popular, but it wasn’t something Microsoft made money from. Pulling MSF to higher shelf and adding tools (VSTS) is a method to gather some cash from this channel.

Nevertheless, changes affected basis MSF was built on. I don’t treat version 4.0 as upgrade, but rather as another branch that has risen from the same tree. And in many cases I’ll stay with the old version.

in: project management, software development

6 comments… add one

  • Anonymous September 24, 2008, 7:05 am

    It’s been years since I’ve worked with MSF and I’ve just popped back in to see what’s up. From just poking around the resources available I entirely agree with your assessment. Thanks for the post. I’ll be passing on 4.0 and going back to 3.1 and grabbing those whitepapers.


  • Pawel Brodzinski September 24, 2008, 9:59 am

    From the perspective of time one more thing became visible. Microsoft tries hard with keeping MSF “trendy.” With agile becoming mainstream software development methodology guys from Redmond struggles to catch that train. They abandoned “common sense methodology” which for me was MSF 3 and moved to delivering tools for “your own lightweight methodology” which has only one advantage over other tools: it is much better integrated with MS development tools than anything else.

    To be honest I can’t say I like where Microsoft is heading with that part of their business.

  • Anonymous March 10, 2009, 3:00 am

    Just a question or request on your opinion: Could MSF (despite its version) work in teams to which people are not 100% dedicated? I mean, several people are nominated as members of some team which is to develope something “under MSF”, but there is a risk these people can be (for an unpredictable period) reassigned to another project – just to extinguish a fire somewhere else. Can we think about MSF at all?

  • Pawel Brodzinski March 10, 2009, 4:16 am

    Actually each methodology can work in a team when not everyone is fully dedicated although it always brings some risks. MSF is no different here.

    Personally I’d try either to limit influence on the project from not dedicated people or (better) try to convince them it brings some worth not only for the project but also for them personally as they learn new techniques.

  • Hector Souzza March 21, 2013, 10:07 am

    I’m new at these methodologies, but I took the chance to dig something on agile methodologies and ended with this solution (MSF), althoug I have seen some difficulties to understand if theres i’s a step by step guidence or some documents to explain how to start the implementation of this methodology, also found that the variant of MSF agile is just the same as scrum in concepts: sprint, backlog, daily scrum also ando so on, now; ¿shall I start with ver 3.X of MSF?, I work with a team of 5 members which will be taking part of the rolles.

  • Pawel Brodzinski March 22, 2013, 2:45 am

    @Hector – As for today I would definitely discourage you to start with MSF 3.X as there are more flexible methods available now. You’re right that modern MSF versions evolved toward Scrum-like approaches, and it’s not without a reason.

    Old versions of MSF, like 3.x, were spiral approaches but they put little focus on cycle length, so you might have ended up with long cycles. With typical agile approaches you will hear about value of short time boxes. Typical iteration length for Scrum these days is two weeks.

    Personally, I would try to go even further and try to pursue release-per-feature approach, which means that you don’t have iterations at all and you deploy as soon as you have something ready, which may mean a few times a week. In extreme cases, like e.g. Amazon, it may mean a few thousands releases per day. Of course they’re small but it also means that the chance of breaking something big time is tiny as well.

    If you want to go toward continuous integration I would say to use elements of Scrum plus Kanban to manage flow of work (and as change management method).

Leave a Comment