jampick's WebLog

Using productivity factor effectively to build achievable iteration plans

2011-03-15T04:49:48Z

Folks at Microsoft have great integrity. That is, they do what they say they are going to do and let you know early if they can’t follow through with their commitment. I hope you have the same experience at your company. Maybe we are just lucky at Microsoft to have so may people with this characteristic. However, when I’ve worked on custom application development projects there seems to be a strange “group integrity paradox” where individuals have great integrity but as a group they make commitments that can’t be delivered on. This lack of group integrity is no more obvious than in iteration planning.

Taking a page from any flavor of agile my team uses a productivity factor to build an iteration plan that is achievable based on the historical productivity of the team. What I'm going to outline below is not new to any agile practitioner. However, anyone can benefit from this thinking not mater what your project management style.

Most project managers will assume some amount of productivity, say 75%. That is fine to build the initial iteration plan. However, we assert that teams must update their iteration plans based on the last iterations productivity. This means after the initial iteration plan is developed some work will get pulled in or pushed out based on real team productivity.

What is productivity?

It’s easy to get snarled in this discussion so from our team perspective we keep it purposely simple. Productivity is how many hours a developer work on tasks and bugs (output) per hour they bill to the project (input).

Consider this next example layering in a few tools we know. A developer bills 40 hours on a project for a week. During that week 30 hours are spent completing work on tasks and bugs from TFS. Why the delta between billed time and time spent on development tasks and fixing bugs? Consider some of my favorite below:

Last night's build broke. - Lose a day debugging build break, rolling back changes for dev who is not here!
Today is a bank holiday for Customer team in Ireland. - Lose a day if you have dependencies on that team.
Customer/EM needs you to justify the time you logged in the time system last week. - Lose 1 hour.
Project PjM has been pulled into a customer meeting and needs your support in that meeting. – Lose 2 hours (and your mind).
Sales team needs your expertise to frame to propose engagement extension – Lose 4 hours.
Customer architect who you work with is a sports fan and wants to talk about last night's game. - Lose 1 hour.
Project sponsor has asked for a status update on the project. - Lose 1 hour.
Customer catches you in the hallway and asks you questions for which you need to answer immediately. – Lose 1 hour.

By know you should understand that there is a delta between time spent on the project and time at your keyboard writing code. What does this have to do with iteration planning?

Iteration planning

The starting point for an iteration plan is capacity. Capacity is usually in terms of developer hours. For an iteration consider 10 people, 3 weeks, 40 hours a week we get 1200 developer hours. The most common scenario is to apply an arbitrary productivity factor of 75% and fill this iteration with 900 hours (1200 * .75) of development work. On projects led by my team we assert that the team must use historical productivity instead.

Team productivity is not just specific to the solution. It also is an indirect measure of experience, training, talent and motivation. Also, some environments are less productive than others: technology, environment, morale, team culture all contribute to this.

On most projects we see initial iteration productivity start around 50-60%. Some teams stay at this level others have ramped up to 75%. We do not plan iterations with more than 75% productivity since there will always be meetings to wick away your time working on development tasks.

How to I calculate the productivity of my iteration?

Again, focus on simplicity so you don’t waste time debating a complex formula.

For your completed iteration get the start and end dates for the iterations
If you are using Team Foundation Server export tasks and bugs assigned to that iteration to Excel
Sum completed work for each developer
Divide completed work by hours billed in to the project between the start and end dates for your iteration
Average the productivity for each developer

Use this number as the starting point to adjust future iterations. Incremental increases to productivity are fine but limit increases to 5% unless there is some change to the project the indicates more productivity. Ideally during your iteration retrospectives the team can identify what management can do to make them more productive. My favorite is have certain days flagged as no meeting days. If implemented the team should commit to increased productivity and the iteration plan should reflect that.

What if you get productivity wrong?

Don’t panic. If the team is more productive than you expect, great(!), pull in work from future iterations. Ideally work is decomposed into capabilities that are portable and have visible dependencies. If the team is less productive don’t adjust too soon as the team may need some time to ramp up. If the team continues to under produce then it may be best to take a page from the agile playbook and revisit priorities with the customer about what can be pushed out to a later iteration. The change here is that in the next iteration you will need to use that lower productivity number so you don’t repeat the same mistake again!

Building iterations based on team productivity is not a license for folks to slack. It’s the starting point to building group integrity and trust with the customer. Early in the project there may be some adjustments to the iteration plan but the team should quickly begin a cycle of delivering what the promised to deliver instead of committing to iteration plans that are known to be a failure from the first day.

One final thought on this. Productivity is an indirect measure of the teams skills and morale. If you put too much emphasis on hitting a “number” then the team can easily game the system if incented to do so. Do this and productivity can’t reliably be used to for iteration planning.

Checklists… not just for weekend chores.

2010-07-17T05:04:15Z

I wanted to pass on a book that I’ll be wrapping up shortly. I’m getting some good ideas that may support creating repeatable processes to around delivering complex software projects. Here is part of the introduction as a teaser…

Here, then, is our situation at the start of the twenty-first century: We have accumulated stupendous know-how. We have put it in the hands of some of the most highly trained, highly skilled, and hardworking people in our society. And, with it, they have indeed accomplished extraordinary things. Nonetheless, that know-how is often unmanageable. Avoidable failures are common and persistent, not to mention demoralizing and frustrating, across many fields—from medicine to finance, business to government. And the reason is increasingly evident: the volume and complexity of what we know has exceeded our individual ability to deliver its benefits correctly, safely, or reliably. Knowledge has both saved us and burdened us.

That means we need a different strategy for overcoming failure, one that builds on experience and takes advantage of the knowledge people have but somehow also makes up for our inevitable human inadequacies. And there is such a strategy—though it will seem almost ridiculous in its simplicity, maybe even crazy to those of us who have spent years carefully developing ever more advanced skills and technologies.

It is a checklist.

From the The Checklist Manifesto: How to Get Things Right (Kindle Edition)

by Atul Gawande (Author)

http://www.amazon.com/checklist-manifesto-things-right-ebook/dp/B0030V0PEW?tag=t0e7-20

Great to be reminded not to overlook the simple solutions even for managing complex work!

TFS 2010 Code Churn Report – Getting Additional Detail

2010-07-06T06:21:30Z

It’s great to see more TFS users use a tool they know, Excel, in conjunction with a tool they may not know so well, Analysis Services to answer questions about their software project. The default TFS reports provide a great first level of detail but you will frequently need to get to the next (and next-next) levels of detail to answer questions about your project. No matter what your role in the project the more you can visit the “self serve business intelligence counter” via Excel connected to the TFS data warehouse the more productive conversations you can have with your team.

Turning “hmmm… we had a bunch of code churn yesterday” to “I see most of the code churn yesterday were added class files in our queuing component… is that related to the bug fix we approved yesterday? I wouldn’t expect new files to be added for a bug fix” Now that is real world and just one example how data can turn a conversation productive!

I’ll use the code churn as an example on how the default TFS reports are a great starting point for project information and how you will need to get some additional detail.

On a project I’m involved with they use the TFS 2010 Build Quality Indicators Report, a default report in the Agile process template, to make sure most tests are passing and increasing in number, code coverage is at the target level and code churn is trending down as we close an iteration.

They hit a couple builds with high code coverage (see to the right, circled) and wanted to confirm if this was expected or not. Here is how you can get more detail on code churn.

You can modify the existing default code churn report that comes in the Agile process template. The example below I start with a new Excel workbook.

1. Follow the excellent instructions here, http://www.woodwardweb.com/vsts/getting_started.html, to connect Excel to your TFS Warehouse.

2. Add filters – Since the question I’m trying to answer is related to a particular build I’m going to drag the following dimensions from the pivot table field list to the report filter

Team Project Hierarchy
Build Definition Name
Build Platform
Build Flavor
Build Name

3. Add Rows – I’m interested in what files have changes so I’m going to drag the Version Control File.File Hierarchy dimension from the pivot table filed list to the row label. If I wanted to know who was churning code I could drag the “Version Control change set checked in by” dimension in to the row label instead. Bonus – have both the checked in and File Hierarchy dimensions in your row label!

4. Add values – This is the “show me the money” moment! Drag in the following calculated fields from the pivot table filed list into the values area.

Code Churn Count
Total Churn
Lines Modified
Lines Deleted
Lines Added

Below is what your finished product should look like. This will give you the “next” level of detail on what code churned and what type of change it was. Since we are working with a pivot table connected to the Version control file file hierarchy dimension you can drill down to see churn down to the file level.

My preference is to have these more detailed reports answer 1-2 questions really well instead of trying to create a “shock and awe” report that is flashy but difficult to take action on. I save these in the TFS project SharePoint for other folks to use.

Once you have this basic report down you can begin spelunking into the other dimensions available to you in the data warehouse.

Data can be used for good and for evil so be sure to supplement this information with your own experience and expertise. Enjoy!

Automation to relate TFS work items

2009-09-21T08:30:51Z

If you are using TFS 2008 for work item tracking be sure to get most out of the tool by relating work items. Depending on the process template you are using the work item types may be different. In general terms consider linking your requirement/scenario/use cases with tasks.

If you are using the MSF for Agile template this would translate to linking scenario work item with one or more tasks required to implement than scenario.

While there is no actual work item parent/child relationship in TFS 2008 you can still construct meaningful work progress reports from a peer scenario and task work item relationship. I’ll go into more detail on how to get this project status info in a later post.

Here I want to focus on how to link work items in bulk. TFS 2008 does not have a way to bulk link work items; not through Team Explorer, not through Excel and not through Project. Darn, darn, darn.

This means if you have imported scores of work items, say via Excel, you would have to open each scenario work item in Team Explorer and manually link the associated tasks with that scenario (instructions to do this manually are here).

For most folks all this manual work would be a reasonable barrier to entry and they would just abandon linking work items and the associated project reporting benefits.

Bulk linking of work items may be better in TFS 2010. Until then I offer you the code below for a command line utility that will link a work item with one or more other work items.

Example syntax looks like this:

linkWorkItems.exe http://tfsrtm08:8080 sandbox 659 "660,661,662,663”

This would link work item 659 to work items 660, 661, 662 and 663.

One great reference I used was this link below to Shai Raiten’s blog.

Reference Link

http://blogs.microsoft.co.il/blogs/shair/archive/2008/10/06/more-about-creating-work-item-using-tfs-api.aspx

Code

using System;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.WorkItemTracking.Client;

namespace linkWorkItems
{
    class Program
    {
        static int Main(string[] args)
        {
            //show syntax if no arguments are passed in or user asks for help
            if (args.Length < 4 ||
                args[0].ToLower() == "/h" ||
                args[0].ToLower() == "-h" ||
                args[0].ToLower() == "/?" ||
                args[0].ToLower() == "-?"
                )
            {
                showSyntax();
                return 1;
            }
            string serverName = args[0].ToString();
            string projectName = args[1].ToString();
            string parentWorkItemID = args[2].ToString();
            string [] childWorkItemIDs = args[3].Split(',');

            //connect to TFS
            TeamFoundationServer tfs = null;
            WorkItemStore store = null ;
            Project project = null ;
            try
            {
                tfs = new TeamFoundationServer(serverName);
                store = (WorkItemStore)tfs.GetService(typeof(WorkItemStore));
                project = store.Projects[projectName];
            }
            catch (Exception e)
            {
                Console.WriteLine("Error:" + e.Message);
                return 2;
            }

            //get parent work item
            WorkItem parentWorkItem = null;
            try
            {
                parentWorkItem = project.Store.GetWorkItem(int.Parse(parentWorkItemID));
            }
            catch (Exception e) 
            {
                Console.WriteLine("Error:" + e.Message );
                return 3;
            }

            //iterate through child work items that we want to link to parent work item
            foreach (string childWorkItemID in childWorkItemIDs)
            {
                //create related work item link
                RelatedLink rl = new RelatedLink(int.Parse(childWorkItemID));
                Console.WriteLine("Linking work item ID " + childWorkItemID + " to " + parentWorkItemID) ; 
                try
                {
                    parentWorkItem.Links.Add(rl);
                }
                catch (Exception e)
                {
                    Console.WriteLine("Warning:" + e.Message);
                }

            }
            //save new links to parent work item
            try
            {
                parentWorkItem.Save();
            }
            catch (Exception e)
            {
                Console.WriteLine("Error:" + e.Message) ;
                return 4;
            }
            //complete
            return 0;
        }
        private static void showSyntax()
        {
            string thisFileName = System.Reflection.Assembly.GetExecutingAssembly().GetName().Name;
            Console.WriteLine("Utility to link one or more work items to another work item.");
            Console.WriteLine();
            Console.WriteLine("Usage: " + thisFileName + " [Team Server] [Project] [parent work item ID] [\"child ID1,ID2,ID3\"]");
            Console.WriteLine();
            Console.WriteLine("Example: " + thisFileName + " http://MYTFS:8080 sandbox 559 \"560,561,562\" ");

        }
        
    }
}

If you have other ways bulk link work items let me know in the comments. Be sure to leave a comment and link to other tools that solve this same problem too.

New Team Foundation Server case study is available

2009-07-02T07:41:45Z

I was lucky enough to have some I’d been a part of captured in a case study. The engagement was focused on Application Lifecycle Management improvements focused on people, process and tools (TFS).

The study is available at http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000004473

When I work with a customer I’m most successful when I embed myself in their org. This helps me understand the nuances of the problem but also craft a solution that is appropriate to the organization. With a deep understanding of the organization an engineering solution can be developed that persist people and organizational changes.

Source Access by Branch and Role using Team Foundation Server

2009-06-20T05:47:53Z

It’s great to see the latest version of Team Foundation Server branching guide just passed 30,000 downloads. Even if you are using another source control system I think you will find plenty of the information in the guide is version control system agnostic and hopefully useful to you.

We are planning to update the guide to align the with the release Team System 2010. The revised guide will have the same content plus focus on some of the new features around branching and merging.

One area I’ve been wanting to expand on is how to secure the basic, standard and advanced branch plans presented in the guide. I’m not sure if this will make it into the revised doc so I thought I would post it here just in case.

Regardless of which branch pattern you are using from the branching guide you should have some form of dev/main/release. Below some tips you can use to secure these branches that balance security and developer productivity and also cover vendor access scenarios too. Feel free to adjust as needed depending on your needs.

Source Level Access Type by Group

Unless otherwise specified TFS Application groups should have the access type listed below. Note, FOO (how unoriginal of me) represents your TFS project.

TFS Application Group	Access Type
[FOO]\Readers [SERVER]\Team Foundation valid users	Read
[FOO]\Build Services [FOO]\Contributors [FOO]\Core_Contributors [FOO]\Release_[xxx]_Contributors [FOO]\Vendor_[xxx]_Contributors	Read, PendChange, Checkin, Label, Lock
[FOO]\SCM Admin [FOO]\Project Administrators [SERVER]\Service Accounts [SERVER]\Team Foundation Administrators	Read, PendChange, Checkin, Label, Lock, ReviseOther,UnlockOther, UndoOther, LabelOther, AdminProjectRights,CheckinOther

Start at the TFS project level

In Source Control Explorer start at the root TFS project level (e.g. $/FOO). Check in policy and check-in notes are stored as version control annotations at the TFS project level (I just found this out too so don’t feel bad). If users are granted access to the sources further down the source tree but not, at least read access, to the project level, then they will get errors when trying to check in. Note, users granted access to check in deeper in the source tree but not the root level, will ultimately be able to check in. However, the experience is bad due to error popup and check in policies will not be evaluated.

TFS Application Group	Inherit Permissions
[SERVER]\Team Foundation Valid Users	No

Development Branch Container

Apply to $/FOO/Dev . Use the access types for each TFS application group listed in the section above. Since we do not want the [SERVER]\team foundation server valid users group to have access anywhere in the source tree we remove inheritance at this level.

Since “dev” is really a container for child development branches we only grant access at this level to the build in server groups listed below.

TFS Application Group	Inherit Permissions
[SERVER]\Service Accounts [SERVER]\Team Foundation Administrators	No

Development Branches

Applies to $/FOO/Dev/dev_xx. Permissions are set at the dev_xx level (i.e. development branches and inherits to all levels below.

TFS Application Group	Inherit Permissions
[SERVER]\Service Accounts [SERVER]\Team Foundation Administrators [FOO]\Build Services [FOO]\Project Administrators [FOO]\Contributors [FOO]\Readers	Yes

Main Branch

Applies to $/FOO/main – access to main is set at this level and is inherited through main. In general, only members of the Project Admin groups will be checking fixes into main.

TFS Application Group	Inherit Permissions
[SERVER]\Service Accounts [SERVER]\Team Foundation Administrators [FOO]\Project Administrators	Yes

Release Branch Containers

Applies to $/FOO/release and $/FOO/release/[release name] (e.g. product 1.0). Similar to the development branch container we want to make sure the [SERVER]\Team Foundation Valid Users do not get read access at this level or below from the parent so we do not inherit permissions.

TFS Application Group	Inherit Permissions
[SERVER]\Service Accounts [SERVER]\Team Foundation Administrators	No

Release Branches

Applies to all release branches under $/FOO/Release/[release]/dev_sp, SP0, SP1, etc. Only members of the [FOO]\Release_[xxx]_Contributors should have access to check into the release branches. In practice, membership to Release_[xxx]_Contributors should be controlled via membership in a local group on the TFS AT (i.e. Release_[xxx]_Contributors is a local group on the TFS AT and is the sole member of the [FOO]\Release_[xxx]_Contributors TFS application group. This will assure that this is no downtime waiting for new membership to be applied via active directory.

TFS Application Group	Inherit Permissions
[SERVER]\Service Accounts [SERVER]\Team Foundation Administrators [FOO]\Release_[xxx]_Contributors	Yes

Targeted Access

Vendor or contract worker

Members of the [FOO]\Vendor_[xxx]_Contributors group (where xxx is a “friendly” name for their project) should have access to only the directories that they need to do their work. This group is added to the specific directories as needed using the same access type as contributors.

The change here is that vendor permissions are not usually set at the development branch level. You have the flexibility to set these permissions in a very targeted, directory by directly way if needed.

Core contributors

You may want to restrict access to higher value intellectual property or core libraries. In this case you can isolate the folders where this content is in your development branch and add [FOO]\Core_Contributors and deny [FOO]\Contributors and deny [FOO]\Project Administrators. If additional security is needed for sources you may want to consider putting the sources in an offline TFS and only check in a library.

Conclusion

The presented security plan strikes a balance between security and developer productivity. It allows for all development branch activity to be controlled and the branch level. You also have the ability to restrict access to vendors or allow access to more secure sources to core contributors.

When locking down for release you control access through release specific local groups reducing any latency caused by going through a separate or waiting for active directory to reflect the security group change.

Bulk update of TFS Areas with ICommonStructureService

2009-06-07T00:48:45Z

I recently had to create an area tree, in a TFS project, with large number (500+) of nodes. I was not looking forward to doing this manually. I had the area tree that I needed to create in a comma delimited (CSV) file so I looked around online to see if someone had a utility I could use to import the areas paths in a csv file and add these as new TFS areas in a project.

The TFS community online is so great. But this time I could not find anything really close to what I was looking for. I list some good blog posts at the end of this post that got me started using ICommonStructureService.

With these leads I created the below command line utility that will consume a file with your areas and add them as areas in your particular TFS project.

You should be able to cut and paste the code below being sure to reference the following assemblies as well.

Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Server.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.dll

Input CSV format example

Parent,Area1,SubArea1
Parent,Area1,SubArea2
Parent,Area2,SubArea1

Sample syntax

TFSAreaTool.exe [TFS Server] [TFS Project] [input csv file]

example: TFSAreaTool.exe http://TFSRTM08:8080 sandbox "Feature Areas.csv"

Code

using System;
using System.IO;
using System.Text.RegularExpressions;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Server;

namespace TFSAreaTool
{
class Program
{
    static int Main(string[] args)
    {
      //check and set required parameters
      if (args.Length < 3)
      {
        showSyntax();
        return 1;
      }
      string tfsServer = args[0].Trim();
      string tfsProject = args[1].Trim();
      string inputFile = args[2].Trim();
      string line;

      //connect to TFS
      TeamFoundationServer tfs = null;
      try
      {
        Console.WriteLine("Connecting to " + tfsServer);
        tfs = TeamFoundationServerFactory.GetServer(tfsServer);
      }
      catch (Exception e)
      {
        Console.WriteLine("Error: " + e.Message);
        return 2;
      }

      //use ICommonStructureService to access area nodes
      ICommonStructureService m_css = null;
      try
      {
        Console.WriteLine("Connecting to structure service");
        m_css = (ICommonStructureService)tfs.GetService(typeof(ICommonStructureService));
      }
      catch (Exception e)
      {
        Console.WriteLine("Error: " + e.Message);
        return 3;
      }
      //iterate through input file with list of areas
      StreamReader sr = null ;
      try
      {
        Console.WriteLine("Reading input file " + inputFile);
        sr = new StreamReader(inputFile);
      }
      catch (Exception e)
      {
        Console.WriteLine("Error: " + e.Message);
        return 4;
      }

      while (!sr.EndOfStream)
      {
        line = sr.ReadLine();
        string[] areas = Regex.Split(line, ",");
        //start with top level area path as parent
        string parentPath = tfsProject + "\\area" ;

        //iterate through areas listed in input file
        foreach (string area in areas)
        {
          createArea(area, parentPath, m_css);

          //parent path for next iteration is the node that we just created
          parentPath = parentPath + "\\" + area;
        }
        parentPath = null;

      }
      sr.Close();
      m_css = null;
      tfs = null;
      return 0;
    }
    static void createArea(string areaNode, string parentPath, ICommonStructureService m_css)
    {
      String node = null;
      try
      {
        Console.WriteLine("Create Area:   " + parentPath + "\\" + areaNode) ;
        node = m_css.CreateNode(areaNode, m_css.GetNodeFromPath(parentPath).Uri);
      }
      catch
      {
        //any duplicate area paths will catch here. May be good to post a warning
      }

    }
    static void showSyntax()
    {
      Console.WriteLine("TFSAreaTool creates TFS Area tree based on CSV formatted input file.");
      Console.WriteLine();
      Console.WriteLine("Input file example:");
      Console.WriteLine("Parent,area1.0,area1.1,area1.11");
      Console.WriteLine("Parent,area1.0,area1.1,area1.12");
      Console.WriteLine("Parent,area2.0,area2.1,area2.11");
      Console.WriteLine();
      Console.WriteLine("Syntax: -[TFS Server] [project] [areas list file]");
      Console.WriteLine();
      Console.WriteLine("Example: tfsareatool.exe http://myTFSServer:8080 SANDBOX areas.csv");
    }
}
}

Caveats

The catch block in the createArea method catches attempts to create areas that have already been created or fail to be created. Some additional handling here would be helpful.

Also note, if an area is created already this catch block with activate and your existing area will persist. This means you can run this script multiple times if needed to add on to your area tree without losing any existing area information.

Links to related blog posts

http://blog.benday.com/archive/2007/07/24/23153.aspx

http://blogs.microsoft.co.il/blogs/shair/archive/2009/01/30/tfs-api-part-10-add-area-iteration-programmatically.aspx

http://blogs.msdn.com/bharry/archive/2006/08/28/728333.aspx

Conclusion

I hope you find this saved you a bit of time when doing a bulk import of TFS project areas. Enjoy!

Windows Server 2008 Hyper-V + TFS Build

2009-04-28T17:56:34Z

My colleague, Ian Ceicys (http://blogs.msdn.com/iceicys/) just pointed me to a great book on Windows Server Hyper-V. I’ve been a been late ramping up on this server role so I’m excited to get caught up. I’m reading this now Windows Server 2008 Hyper-V: Insiders Guide to Microsoft's Hypervisor: John Kelbley, Mike Sterling, Allen Stewart: Books.

My first thought is how useful Hyper-V running on a build machine could be to enable isolated testing on the build machine. I’ve always been bothered by how little utilization most build machines have. With Hyper-V running on a build machine it would be interesting to spin up virtual machines to test the product of the build. On a test failure we could save off the VM for debugging later. All this without tainting the build machine.

Something to think about. I’ll be installing Windows Server Hyper-V in the next few weeks to explore this more.

Team Explorer cache cleaning

2009-02-26T21:51:09Z

When switching between TFS servers (i.e. different servers not TFS projects) there can be data that is cached between projects on the 2 servers leading to some confusion in the Team Explorer UI that makes is appear you have not really changes servers.

This information applies to both TFS 2005/2008. I’m not sure how this behavior will change in the 2010 release and beyond.

To preempt any problems related to caching you may want to follow steps below when changing between TFS servers.

Changing between TFS Servers

In Team Explorer disconnect from the existing TFS server. In Team Explorer ->Right click server->select disconnect
Close Team Explorer/Visual Studio
Remove the Team Foundation local cache	1. cd "%userprofile%\local settings\application data\Microsoft\team foundation\2.0" 2. rd /s /q cache
Restart Team Explorer/Visual Studio
Connect to new TFS server

This can be especially important if you are switching between a production and test Team Foundation Servers that have similar data.

There is no worse feeling that realizing that destructive change you thought you made in the test environment was made in production.

TechReady 8 in Seattle

2009-02-02T05:01:54Z

If you are attending the Microsoft technical readiness (TechReady) conference this week in Seattle please drop by one of my sessions below. I’ll be speaking with Mario Rodriguez, from the Visual Studio team, about source code branch requirements, strategies and execution in TFS.

DEVCT311-R1 VSTS Rangers TFS Branching howto

Thursday, February 5, 12:45 - 14:00, (WSCTC) 206
Friday, February 6, 13:00 - 14:15, (WSCTC) 206

Primary Track: Development Tools & Technologies
Session Type: Chalk Talk
Speaker(s): James Pickell, Mario Rodriguez
Abstract: Learn how to use TFS branching structures from basic to advanced in this educational and hands on session
Objectives: 1. identify branching requirements. 2. describe the most frequently used TFS branching strategy. 3. execute common branching scenarios.