TFS - My Work or Branch

Question

My team has recently upgraded from VSS to TFS 2013. In the past, there was a hard and fast "no checking in until the Item is complete," rule, but this is being challenging by a couple of newer team members, who have experience with Agile.

At the moment, I am working on a rather large change. In the past, per our existing rule, I would not check in until it was fully complete (about two months' worth of work). With TFS, we have some other options available, however, and we strive to get to an Agile process. When talking about this with the team the other day, the two newer members were adamant that I just check in my changes (to the trunk, which is our dev branch). My problem with this is that many of the files I changed are commonly modified in each release cycle. If I check in before the feature is ready for release, and they then merge their changes with my changes, we can now not release either change until mine is ready.

The current solutions on the table for this problem are:

1. Create a branch specifically for this feature. This does not mesh with our chosen branching strategy (code promotion), but is considered a special case.
2. Use a shelveset. This way, at least my code is backed up on the server, and I can merge it all later when I am done.
3. Use My Work (honestly, I just found out about this feature a couple hours ago). Same basic principle as a shelveset, though it seems to be "better practice."

Which of these (or perhaps #4?) is the best solution to our current problem? We are aware that in general our processes have issues, and we are working on them, but it will take time to implement an actual Agile process in which the work is broken down such that checking in early and often is easy and causes zero issues.

Answer 1

You may ask yourself why is it impossible to make a release until your changes are done.

In Agile projects, it is not uncommon to release several times per day, and still, some features may take days, weeks or months to be done. The usual approach is to have switches that enable or disable the pre-release feature during runtime, so that you, a developer, can run the feature, but ordinary users cannot.

In more complex systems, a similar switch has an additional benefit: it permits to test a feature with some users before enabling it for everyone. Those may be either users who are actively interested in features which are not yet available for general public (and accept the risk of bugs, information loss, etc.), or just a bunch of random users (miserably failing with a few thousand users is still better than with hundreds of thousands of users).

Of course, this forces you to commit code which compiles, and better be passing all the tests. This is not necessarily a drawback: as practice showed in the past, using nightly builds (which may happen more frequently than once per day, by the way) as a heartbeat of the project and trying to avoid getting a project into a state where it doesn't compile for weeks is beneficial for both the project and the team.

---

If it looks too difficult to work this way in your context, I would chose your first suggestion: a branch per feature with a merge to the trunk once the feature is finished, and maybe some merges between the branch and the trunk in the meantime.

Shelvesets have a different purpose. They are there to be able to store the current state of the project in order to work on a completely different stuff. For instance, you were implementing a two-hours feature when a critical bug was discovered in production and you should fix it right now. Shelvesets are second-class citizens. The major problem is that they integrate badly, if at all, with all the visualization and data mining tools for TFS. If somebody wants to know the progression of the team based on the information available in TFS, he may not be able to use shelvesets for that. Similarly, two-month commits would be too huge to be useful: how, for instance, would you diff a commit which changed half of the files of the code base, given that many files don't even look like their previous revisions?

As for My Work, unfortunately I'm unaware of this feature.