How can I figure out which programming methodology (if any) that we're using?

Question

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?

Answer 1

The most basic method tends to be your iterative or "waterfall method" because you just go from step to step to step. It doesn't seem to be very popular anymore, though.

Answer 2

If you can't discern a methodology, then you are using an ad-hoc methodology. It may be similar to an existing methodology (by accident). Note however that following a methodology is not the same as being successful. I have seen plenty of methodology heavy projects that failed, and plenty of "seat of the pants" projects be resounding successes (if perhaps in need of a bit of refactoring when the dust settled).

Changing methodologies depends on your culture more than anything. Institutions tend to resist change, and do some individuals. However, it is again situation dependent: if the existing situation is obviously broken, an institution can sometimes make snap changes that surprise everyone.

Some methodologies are "heavier" than others: those are harder to change to or from. Even Test Driven Development is "heavy" in that adopting it after the fact will mean adding a lot of tests to old code. Most real world transitions simply add the testing as files are edited for other reasons. Likewise, moving from TDD to some waterfall style would require a lot of code to be documented in large disused binders.

Answer 3

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?