At this month’s NEW Agile users group meeting, I will be presenting on how to use Team Foundation Server 2010 (TFS) in an agile environment. My focus will be around the built in Agile 5.0 process template and the Microsoft released Scrum 1.0 process template. I will also be covering the use of the Telerik’s free Work Item Manager and Project Dashboard tools that work with TFS. What is great about Telerik’s tool is that it provides non-developers a great user experience to the same data. The tools works on the data in the TFS ecosystem and does not require additional servers, databases or configuration. My presentation is part of a larger goal of the users group to help attendees understand the tools available to them, including using post-it notes.
By default, a Team Foundation Server (TFS) Team Project will have multiple check-out enabled. This means that the same file can be checked-out by more than one individual at the same time. This is actually a good thing in that blocking changes does not occur when different people need to access a file and one or more people are unavailable to undo their check-out.
Some people then get concerned with merge complications (a.k.a. merge hell). At the surface, merging may seem complex, but when broken down it should be fairly straightforward. The built in tool with Visual Studio for compare/merge and third party tools, like KDiff3 and WinMerge, all provide a great way to automatically detect changes in a file. Most of the time those changes are not on the same line and the merge is automatically handled. In the case where two or more people are changing the same line, method or functional piece of code, I would consider that it really isn’t a problem with merging. The team members need to find out why two people are working on the same thing.
Sometimes it may be that two different people recognized the same bug and fixed it. They may both see convoluted code and refactor it to be cleaner. In these types of situations the second person checking in that then sees a merge conflict should be able to easily identify what happened and either throw away their changes or overwrite the previous check-in. In the strictest sense, one could argue that the developer should open a bug and add it to the backlog, but the case of refactoring smelly code doesn’t really fit that model. Often times I will see sprints with a refactoring bucket and task, which means tracking this type of change isn’t easily predictable. Either way, these aren’t major areas of merge complications.
There are times where merging is not that simple, but I would argue that it’s usually a project management issue or an architectural issue at that point. Two people shouldn’t be actively developing the same feature, because that would mean there is a communication breakdown. In an agile environment, the team members should be communicating at least once a day and be aware of what others are working on completing. If the file in question contains so much code that multiple people are inadvertently effecting each other, the code may need to be refactored on a larger scale to remove tight coupling. It should follow a separation of concerns approach.
I find allowing multiple check outs to be more beneficial than not. When Alice forgets to undo a check-out before she leaves for the day and Bob needs to update some other portion of the file, he inevitably ends up with a couple choices that all reduce his productiveness. He can move on to something else, forcing a context-switch in which he’ll have to return to when the file is available. He could find an administrator and have Alice’s check-out undone, which would leave Alice to handle a merge situation anyway with her local changes and whatever Bob checks in. Worst of all, Bob could have no other work to do and he ends up doing nothing productive.