Azure DevOps, Scrum, & .NET Software Leadership and Consulting Services

Free course! Predicting the Future, Estimating, and Running Your Projects with Flow Metrics

Some misconceptions about Team Foundation Server & Team System

I’ve gotten a bunch of ‘feedback’ lately from the community about Visual Studio Team System (VSTS) and Team Foundation Server (TFS).  Out of these ‘discussions’ it seems like there might be some misconceptions about VSTS & TFS. 

Misconception #1: “TFS is just a source control repository” or “TFS is an expensive source control solution”

Since I’ve got the word “misconception” next to “TFS is just a source control repository”, you can probably guess what I’m going to say next.  Yah.  You nailed it.  It isn’t just a source control repository.  Where Visual Studio is an IDE or Integrated Development Environment, TFS is something of an Integrated Process Environment.  It’s trying to give you one place to store and manage all the artifacts regarding your development initiatives – project planning, task status tracking, defect tracking, automated builds, status data analysis, and source control.  So, if you’re using TFS for just source control then – well – yah – you might see it as kind of expensive…but then again, you’re not using everything that you paid for. 

Misconception #2: VSTS & TFS is hard to adopt

The other misconception is that TFS & VSTS is hard to adopt.  Ok.  Well, I can kind of see this one but it’s not really about Team System.  It’s more about process.  For lots (if not most) organizations, introducing VSTS & TFS in less about tooling and more about process improvement.  Improving your software development process does sometimes involve a fair amount of pain and definitely a decent amount of effort but this doesn’t really have that much to do with VSTS/TFS. VSTS/TFS is the framework that you’re using to help you to improve your process and (ideally) make it easier to follow (and stick to) best practices.  If you aren’t currently following best practices — no test driven development, no automated builds, no continuous build environment, no trend information about your project plan tasks, not traceability of how your project plan and defects relate to your check-ins and builds — then making the investment to get to that point is going to take some effort and is going to be – well – an investment. The idea though is that once you’ve made the investment, it’s made and you’ll (hopefully) be able to reap the rewards.

Adopting TFS source control is usually pretty straightforward as long as your team is familiar with and are able to apply the concepts of branching and merging.  If you’re migrating from a source control repository that doesn’t have or doesn’t do branching and merging well such as Visual SourceSafe, then you and your team might encounter some pain while you get up to speed.  Thinking some more about Visual SourceSafe (VSS) migrations, 99% of the time it’s painless but if you’re one of the companies that made heavy use of SourceSafe’s Pinning and Sharing (P&S) features then – well – buckle up, Grandma.  This could be a bumpy ride. 

In order to get to TFS from VSS, you’ll need to eliminate Pinning and Sharing and replace it with branching and merging.  This is going to make your source control repository *look* more complicated but it probably isn’t *actually* more complicated.  Whether or not you realized it, all that Pinning & Sharing was adding a lot of complexity to your source repository and was probably causing you a fair amount of pain.  You probably didn’t realize it because you were used to your constantly broken builds and never really knowing what version of your code you had in any given build.  Replacing Pinning & Sharing with branching and merging formalizes how code gets moved around and integrated within and between your projects.  Integrating new versions of classes and DLLs into in to and between projects will now be an positive and unambiguous action that your team takes in contrast to the abrupt integration that is unpredictably forced on your team when someone modifies a shared or pinned file. 


It’s not just a source control repository!



Looking for help adopting Visual Studio Team System 2008 or Visual Studio Team System 2010?  Need training?  Want someone to coach your Team System project?  Need help installing TFS?  Want to customize your Team System development process?  Contact us via


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.