Managing Working Directories for Team Foundation Builds

In the last month I have had two separate clients have issues with how their working directories were setup in their TFS builds. First a system drive was running out of space from a large amount of new projects being built, and second some builds were failing due to some file paths being over the OS enforced limit of 260 characters. These were caused partially because it is not immediately obvious where the working directory for the build server is located when you create them. This post is a quick review of how to manage the working directory and avoid the two issues above.


The working directory is the location where the server will place all the source code for a TFS project's build. It is logical to think that since you are asked to select a workspace during the creation of the build definition, that the build would use the local directory set in that workspace. That is not the case.



If you create a build with most of the defaults the working directory will be a temp folder under the Local Settings directory for the user that the service runs under (which is usually TFSSERVICE). You can see this is the buildlog.txt screen shot here.


So by default all the source code for all the builds will be on the system drive (most likely) and will start out in a directory path that can be 80 to 100+ characters deep already giving you not much room before you will hit the 260 character limit.


So you may initially go back to the build definition to point to another directory on another drive with a shorter path. But you will see that while you can set the drop location where the compiled output of the build will go, the working directory is not set in the build definition.



The working directory is actually set in the build agent in the Working Directory field (funny enough). By default this will be $(Temp)\$(BuildDefinitionPath). The $(Temp) is what points us to the user's temp directory under Document and Settings.



So we can change this to point to the directory and drive of our choice to prevent our system drive from being overloaded and hopefully avoid reaching the 260 character limit when the source code is pulled down.

Comfortably Scrum: Estimating and Forecasting Beyond the Sprint

After my presentation at the Nashville PMI IT Local Interest Group last night, several project managers stayed to talk about estimating and project forecasting with Scrum. One was skeptical about being able to reliably tell management where they would be 6 months or 1 year down the road. Another was in an experienced XP shop that only planned for the current iteration and was having trouble meeting long term goals. The coincided with a thread on the Lean/Agile Yahoo group about estimation and planning that includes contributions from many experienced Agile leaders.

One of the posts had a link to an older presentation by Mike Cohn at Google on estimating that is a fantastic introduction to how to estimate and forecast in an Agile project. Here is the PDF version and the YouTube part 1 and 2 are below. He has many of the examples I have seen and used in my presentations based on studies done at Simula Research Laboratories in Norway. It is good to have this research for the skeptics you will eventually encounter. I really like the "Zoo Points" exercise and plan to add it to my training. Mike (and others) have many more great presentations at the Mountain Goat Software site.







This is a great intro to estimating User Stories (i.e. Product Backlog Items) and performing release planning to have an idea of where your project might be far into the future.

PMI Scrum Presentation

Tonight I presented for the Nashville PMI Chapter at their IT local interest group. We had a great crowd and it was interesting to see how many traditionally trained project managers were interested in exploring their options with Agile/Scrum. The group was very engaged and there were tons of good questions and conversations after the presentation was over. I want to thank the organizers for a great event.

Radio TFS "Getting Agile With Team Foundation Server" Featuring Yours Truly

Mickey Gousset and Martin Woodward from Radio TFS were gracious enough to have me on their podcast this month. You can subscribe to the RSS for the podcast here. We talked about implementing Scrum and XP engineering practices using Team System. Here are some links to items we mentioned during the interview:

• My company Compuware


• My blog (which you are on now of course!)


• Conchango Scrum template for Team System


• Ken Schwaber's book on Scrum


• Scrum and XP From the Trenches by Henrik Kniberg


• Certified Scrum Master training


• Microsoft's eScrum TFS template


• TFS Light Weight Scrum template on Codeplex


• devLink Technical Conference


• People we mention: Ken Schwaber, Jeff Sutherland

Please Review my Session Proposal for Agile 2009

I have submitted an in-depth demo on implementing Scum/XP using Team System to the Agile 2009 conference coming up August 24th to 28th in Chicago. This conference has a great open mechanism for reviewing content.

Presenters post online abstracts of their sessions for anyone to review and comment on. The organizers can add reviewing comments, but anyone who cares to register on the site can look through all the proposals and leave a comment on why or why not they think it should be included in the conference.

I have done a smaller version of this presentation many times, but this demo will be longer and more in-depth where I walk a feature from first being captured on the Product Backlog all the way through to being pushed to production. Large ALM products like Team System are not very popular in the Agile community at large who tend to prefer open source solutions. I have already had a skeptical comment from J. B. Rainsberg who is a pretty heavy hitter in the Agile world. Two of the organizers have left comments suggesting it make the final cut so I am hopeful yet.

If you have the time, please take a look at the abstract and leave comments (good or bad) to help me make sure the session is as good as it can be.