Home/ Questions/Q 106157
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T01:33:09+00:00

My group is moving to Team Foundation Server soon. Actually, I’m heading up the

  • 0

My group is moving to Team Foundation Server soon. Actually, I’m heading up the effort.

One of the things you get to decide is which methodology you’re using – Agile, CMMI, etc.

Thing is – I have no idea what methodology we use. By which I mean, we’re not actively using one. And I’m not familiar enough with Agile or other methods to know which, if any, happen to apply to the way we’re doing.

Is there some default methodology? As in, if we go through some very blunt process (get requirements, code, test, push to QA, have QA test, push to production) is there even a name for it?

And as a bonus, with TFS, what is the penalty for picking the wrong one at the outset? How hard is it to switch gears later if we decide to go Agile or something?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. There’s no major penalty for switching methodoligies – you just pick a default one when you install, and you can choose the one you’ll use for any given project. In fact, it only has to do with how TFS configures the Sharepoint project page initially – you can add whatever you want to your page once it’s created, so if you decide to change a project’s methodology, it’s not difficult to do.

    For the two that TFS gives out of the box (Agile and SCCM/Waterfall), it really a question of your process – do you release ‘early and often’, with smaller packages releases as bugs come in, or do you run your projects in large iterations, with a release much more infrequently, but with obvious milestone releases?

    A question to ask (though not exactly accurate, but always helps me): Does the product have version numbers that will be meaningful to the end users? For example, many websites are Agile, as they’re constantly releasing improvements and patches, and don’t often have huge improvement/overhauls, whereas a product like MS Office has a meaningful version number (2003, 2007, etc), which is more likely SCCM.

    If you don’t have a stated methodology, it’s a great time to develop one – decide which release cycle makes sense to you, create a project in each and review what TFS sets up for you automatically – do the progress indicators and Sharepoint pages make sense? Is there anything obvious missing?

    • 0