Enabling SharePoint Co-Authoring on TFS Sites

Out of the box, SharePoint co-authoring isn’t enabled on Team Foundation Server (TFS) sites. Since this is one of the coolest collaboration features to be included in the integration between SharePoint 2010 and Office 2010, it is a shame not to use it. Unfortunately, those who are running SharePoint 2007 or the default WSS 3.0 sites will not be able to make use of this feature, but this should give you something to look forward to in your next upgrade.

In the more traditional models, documents that are stored out on the TFS SharePoint site are either just dumped into libraries or will have checkout enabled. In the former case, there is no document control and different versions of the same document will just overwrite each other. In the latter case, checkouts will let one person check the document out and make edits exclusively until they return it to the library. This is great, but in very dynamic teams, it is helpful to let more than one person edit the document at once – especially when you are able to do this in real time, over a conference call perhaps. With co-authoring enabled, several people can work on the same document and will see the changes that are being made every time they save and synch changes. Even better is the chat and presence information that can be provided if you are using Lync Server or Office Communication Server, you can interact and see the other people who are modifying and updating the document.

Enabling SharePoint Co-Authoring

These settings are done at the Document library-level and can be done one at a time with no impact to other TFS projects or Collections on your server. Changing a bunch of existing sites would require some scripting or mass changes. Likewise, if you would like this to be the default in your environment, you will need to modify the site template and save it for new sites that will be derived from that template.

  1. Ensure that you are an Administrator of the Team Site that you will be editing
  2. Navigate to the SharePoint sire for your project
    1. Enter the URL for your site http://<SharePoint URL/Site/<Collection Name>/<Project name>
      – or –
    2. In the Team Explorer, right-click on the project name and select Show Project Portal
  3. In the left column, select Shared Documents
  4. At the top of the screen in the ribbon, navigate to Library Tools | Library
  5. In the Settings Section, click Library Settings
  6. Select Versioning Settings
  7. Ensure that Require Content Approval for Submitted items is set to No (Default)
  8. Enable versioning

    By default, versioning is not enabled on TFS libraries.
    1. You can choose to keep major and minor versions at your desire, but I prefer to keep both.
    2. If you are at all worried about disk space (and who isn’t?) you’ll find it a good idea to limit the number of document versions it keeps for both major and minor versions.
  9. Draft Item Security
    1. I prefer to restrict this to Only users who can edit items
  10. Require Check out
    Requiring checkout will disable the co-authoring features you it is imperative that you disable this. Of course, team members will be able to check the document out for exclusive edits if they would like, but forcing it will not allow others to share the document. This is a small training piece for team members who are used to doing it the other way, but this should be a huge barrier.
    1. Ensure that this is set to No.
  11. Click OK

Now when you are editing a document from either the Documents folder in the Visual Studio/ Team Explorer window or from the SharePoint site, your save button will be changed to Synch and Save. You’ll also get notifications when others open a document you have open and new email and chat options will show up in the footer bar as well as on the file menu.

How Cool!

For a cool demo of what the feature looks like, have a look at the screencast: http://sndshreeman.wordpress.com/2010/05/17/sharepoint-2010-multiuser-co-authoring-and-tfs-screen-cast/


Spell Check in TFS

One of the most-requested features in TFS is to add the ability to do spell check in the work items to avoid dumb typos being stored forever in the database. I am sincerely hoping that fully-integrated spell check is in the next version of Visual Studio, but in the meantime, there is another option.

Most of the fields on the Work Item screens don’t really need spell check, but it would be really great to have on the larger text fields that are used to story WI descriptions, acceptance criteria and things like that. If you are using the CMMI template you probably already have these as HTML fields and usually one of the first customizations that you had probably considered was swapping out these on the Agile and SCRUM template. Once you do this, many of the IE plug-ins that you’re using will become available to you.

I have ieSpell installed on my computer and it provides a full-featured spellcheck simply by right-clicking on the paragraph in the field. The days of misspellings in requirements and User Story Work Items are over.

IeSpell can be downloaded here: http://www.iespell.com/ It is free for personal use, but can be used in a corporate setting for a very reasonable cost.

Control Means Measure!

All too often managers complain about the difficulty managing outcomes, people, or situations without taking a step back to think about what it is that they’re really trying to accomplish. They’ll work hard and put in long hours only to see no appreciable change in the things they’re trying to manage. Let me throw out two axioms.

  1. To control means to measure
  2. If you’re not measuring it, it isn’t important

Let’s look at that in a little bit more detail. (Yes, I’ll come to the logical inference later…)


A lot of managers approach problems like they might approach walking their dog. Fluffy will be jumping at the door wanting to go out to mark the neighborhood as his, but the plan isn’t much more specific. Sure there is an objective, there is an end in mind (you do want to end the walk back at home don’t you?), and there is a routine (organizational process assets). Getting that done doesn’t take much more than heading outside and monitoring the situation. Once the door is open, Fluffy will take off like a bolt, wander around, sniff at the trees, and the manager calls to Fluffy to make course corrections when things seem to go farther out of bounds than he’s expecting. Managing something more elaborate may have hundreds of tasks that all rely on each other to arrive at a satisfactory result. This means that simply making course corrections isn’t enough to ensure that we get Fluffy home – we need a plan and we need to know how well we’re executing against that plan.

The next time Fluffy wants to go out, we realize that it is -20 outside and we’re not in the mood to run around the neighborhood losing several toes to frostbite. This time, it is important that we manage the process, keep the walk as efficient as possible, and stop Fluffy from running amok. For this, we need to measure Fluffy’s performance and make corrections in an immediate or even proactive way— we’ll use a leash. The manager can make immediate corrections. Because this is important, we need to get constant feedback as Fluffy pulls on the lead.

Now for the nectar… and I love nectar.

If a problem is important to you, you need to have metrics in place if you’re going to have any ability to control it.

Think of all the things you’re responsible for in your daily work. These are the things that you’re expected to control and if you don’t have at least one measure assigned to each of them, the best you can do is call out hoping that it’ll come back in line. These needn’t be complicated or elaborate statistical measures, but you have to be able to answer two questions about each.

  • How do I know when it’s wrong? (Measure – Do I have a leash?)
  • How wrong can it be before I react and what will I do? (Threshold and mitigation – When and how can I pull on the leash?)

Do it now! Make a list of your dogs and identify your leashes.

If it is important to you, you have to be able to measure it so you can control it.

Top 8 Mistakes Implementing Agile Methodologies

Agile development practices have been around for years and there seem to be evolutionary new flavors introduced almost daily.  As a testament to its mainstream appeal, even PMI is releasing an Agile certification, opening the floodgates to an organization that has long been seen as the keeper of the Waterfall keys.

As more and more organizations scramble to work in an Agile way, it seems that there are as many failed or ailing attempts as there are successful ones, though I have seen studies putting the successful adoption rate between 20 and 75% — a huge range to be sure.  Looking in from the outside and having worked with organizations making that jump, I have seen a number of trends that I want to call out.  Unfortunately, these are not cited with scientific statistical rigor, but I am hoping they are helpful nonetheless.

Just for full disclosure, I manage a Project Office responsible for delivering a wide variety of development projects in a consulting environment.  This affords a certain perspective favoring the business outcomes of adoption rather than the technical ones.  Further, I am focused on using the correct methodology to meet the situation while building reusable organization assets and collecting performance metrics.  So with that, here we go!

  1. Treating Agile as just a Development Practice rather than a Business Process — Working in an Agile way requires an understanding and realignment of your project selection, portfolio management, budgeting & funding process, requirements gathering and acceptance process.  Assuming that none of the business functions will be affected and that just the development teams will work in an agile way leads to a cognitive disconnect between the business and the delivery side — a gulch that is often there before you even try to implement agile.  This is especially true when Agile is a grassroots effort that is greenlighted without support.
     There needs to be a clear understanding of what the organization will get out of the new process and where there are opportunities to remove barriers before they are even an issue.  Failure to address these alignment issues will just lead to communication gaps and the business side demanding that you revert to the pervious practices.
  2. Using Agile Coaches who don’t have a Stake in a Delivered Product — Bringing in an agile coach can be a huge benefit to your organization as teams usually learn best by doing.  Usually a team (and the business side) will need to go through a full release cycle before the process really sinks in and an agile coach can help you to identify risks and guide the team through this.  Unfortunately, the coaches often will act as academics or shamans who want to sit in an advisory role with no real team deliverables.Always insist that the coach work with the team in a real-life product cycle and plan for the learning curve in your capacity planning.  You’ll get a ton more out of it and will see better adoption. This also means that you’ll be working with a coach who is a practicing professional and able to get things done.  Better yet, tie compensation to adoption metrics or success criteria for the release. 
  3. Forgetting to do Sprint and Release Retrospectives — One of the biggest benefits to agile is the virtuous cycle of continuous improvement, building on the lessons from the previous iteration.  When the going gets tough or there is a perceived lag in the project, this is usually the first area to be cut.  This just bleeds the value out of the Agile process and perpetuates problems rather than learning from them. Repeat after me…   “I will not cut Retrospectives! I will not cut Retrospectives. ” (Especially as they pertain to capacity planning.)
  4. Treating Agile Development as a Replacement for Planning or Requirements — Organizationally this is usually in response to poor planning or badly defined requirements.  The thinking usually goes, “We end up in trouble trying to deliver against half-baked specs and unrealistic project plans, but if we have neither of those things, we’ll be free to just deliver (and no one can say we failed.)”  That last part is usually subconscious.
     If you can’t come to an agreement with the development team as to what you want to deliver or aren’t willing to staff the team appropriately, there is little hope that working in an Agile way will improve things much.  Yes, letting the team interact with the business directly will help to specify what is asked for, but in my experience, the issues usually lies in poor arbitration between parties with conflicting needs.  Agile don’t directly fix that.  Failure to address the root problems can lead to additional churn and rework.
  5. Not Having a Vision of Done — This one might be a bit contentious, but every project needs a picture of done with acceptance criteria associated with it.  Usually this is a set of stories, grouped into a release, with UAT criteria associated with them.  As a consultant, I usually have to be much more specific than that as building a backlog against unlimited time and dollars usually doesn’t get us invited back.  Just make sure that you have a clear picture of whether done is “good enough with a list of nice to haves” or if there is a more stringent criterion that you need to be shooting for.  Not identifying that up front and structuring the team for it leads to bad things.
  6. Not Preparing the Business for Participation — It is essential that the business side of the organization have daily participation in the project.  Most likely, they are used to an intense upfront requirements phase and then are ignored until UAT.  Sure, they will still need to have initial engagement as the Product Backlog is built and the release plan made, but the ongoing participation often comes as a surprise and must be managed carefully.  Often they are happy to do it, but springing that on them with little notice or input can hurt feelings and lead them to a feeling that the development team is needy and unsure of themselves, rather than following a prescribed process.
  7. Starving the Factory — Trying to treat each iteration as its own waterfall or expecting that all story elaboration will be done in sprint often leads to work starts and stops — especially as a team scales.  Planning your stories and digging into the business drivers and needs one sprint ahead allows you to engage with your QA teams and Business Analysts to provide the fuel that the development team needs to keep the factory rolling.  This is not a substitute for having the developers interact with the business directly, but it does take some of the burden off of them and can leverage the specialized skills of your BAs and QA folks.  For me, this seems to be the best blend of sustained agility and supporting a scalable and even geographically distributed team.
  8. Expecting an Agile Experiment to Scale — So you wanted to prove that Agile can work and will be able to be adopted into your organization.  You’ve pulled 4-6 of your top architects and high-potentials into a mini project because you expect them to be leaders of additional projects when you scale.  The project goes great, the team blazes through the deliverables, and you’re ready to go!  Right?  RIGHT?
     This is a great way to train leaders in the overall flow and tenets of Agile, but it doesn’t always paint a good picture of how this will work in a real environment, especially if you work with distributed teams, outsource groups, or 9-5 developers who are phoning it in.  Once you have those leaders, make sure you do a real PoC with a realistic team to work the kinks out, especially around communication and code acceptance.

Wow, that was more typing than I had anticipated and I am sure as soon as I hit publish, I’ll think of 5 more that I just have to include.  Maybe there will be a part 2.  Hopefully this will save you a few headaches and help you to navigate the agile waters.

When to create a new Project Collection

One of the greatest features for TFS 2010 is the ability to create new project collections in the TFS system.  This gives you the ability to separate projects into logical collections and manage them as individual groupings which can be a huge benefit.  There are, however, some things you should consider when creating collections.

The Pros:

  • Each collection gets its own database on the SQL data tier.   This means you have the ability to move it across different database servers and manage it individually.  Also, this gives you a bunch more options in scalability and monitoring.
  • This makes the collection portable, meaning you can detach it and transfer it to another TFS server.  This is especially useful if you are in a consulting environment and will need to transfer just that project or suite of projects back to the client.
  • Scalability!  This means that you can create new collections to spread your databases across SQL servers or instances to isolate their performance and risk profiles.
  • Each collection has its own set of process templates, sites, and linkages.  This gives you an opportunity to isolate projects from each other.

The Cons:

  • You’ll need a separate build controller for each collection.  If you are not planning for the proliferation of build controllers, you may suddenly find yourself supporting more machines than you’d anticipated.  There is a hack that let’s you map multiple collections to a build controller, but it is not supported.
  • Having multiple collections creates an additional support and backup burden.  The backup scenarios with TFS are not simple and they must be done by database.  This needs to be added to the “new collection” SOP.  If you have a dedicated SQL server/ instance, you can add these procedures to the Master database so they’ll be created automatically.
  • While you can change things between collections and have TFS function separately, there is only one data warehouse.  Mismatches in the data types or aggregations in the cubes will cause TFS to throw errors and stop data collection until the conflict is resolved.
  • many of the permissions are set at the collection level.  As you create new collections, you’ll need to manage the permissions individually.

All in all, there are huge benefits in having multiple project collections, but you need to plan them carefully and ensure that you are accounting for the additional overhead needed to make them work well.

Troubleshooting a Broken TFS Data Tier

I have seen a number of questions out there around troubleshooting a broken data tier in TFS 2010 in cases where the application tier appears to be working correctly, but the whole system is down because the AT can no longer reach the core databases.   Here are the steps I have gone through to resolve the issue and to get back into production.

Start at the Data Tier

  1. For now, let’s ignore anything that isn’t App Tier (AT) or Data Tier (DT) as almost all of that can be rebuilt or you probably have it elsewhere (though possibly not the case for SharePoint documents).
  2.  First, check your database backups and their logs to make sure you have them in a safe place.  I am hoping you went through the real backup procedure (either through the painful process with all the SQL statements or through the Oct version of the Power Tools) rather than just clicking “backup” on the databases.  Make a copy of them elsewhere in case the problem comes down to a bad disk or something with the hardware.  If you can have them in a safe place, first, that is some measure of security.
  3. Check access to the databases with SQL Management studio.  You need to make sure you are using the account that you expect TFS to be using for data layer access.  Try connecting to Tfs_Configuration and to your collections Tfs_[Collection Name]
  4. Triage issues in the event logs

Validate Network Connectivity

  1. Log on to the AT server
  2. Validate that you can ping the Data Tier by its server name and its full name (FQDN)
  3. Triage issues in the event log

Validate AT Connection

  1. Open the TFS Administration Console
  2. Check the TFS logs here
  3. Click on the Application Tier Node and scroll down in the main pane to confirm that the data connection is right
  4. At this point you can try resetting the database registration in TFS
    Attempt to repair the connection http://msdn.microsoft.com/en-us/library/ee349268.aspx
    Attempt to Re-register from scratch RegisterDbs  http://msdn.microsoft.com/en-us/library/ms252443.aspx
    RemapDbs (more complex/ split server scenarios) http://msdn.microsoft.com/en-us/library/ee349262.aspx
  5. If you are still not at the problem, I would go through the steps as though this were a data tier move…  that means you will try to reattach the working AT to the DT.  You should first try this with the existing databases, but these may have gotten munged so you’d then move to the backup.


If you didn’t have the right backups, you may have to recover the collections once connected, but this would result in possible data loss of the unsynched portions (usually only a few seconds of difference) http://msdn.microsoft.com/en-us/library/ff407077.aspx

Custom Email Templates in TFS 2010

Team Foundation Server 2010 can create custom alerts that fit almost any set of criteria you can come up with, but the emails that it generates are pretty generic, though informative.  Wouldn’t it be great if you were able to customize the information that was contained in them and maybe even spice them up a little bit with corporate branding?  With just a little bit of work, you can have these looking much better.

On your server that is housing the TFS 2010 Application Tier, all of the e-mail templates are contained in the same folder where TFS Job Agent was installed.  In my case, the files are located at:

C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\TFSJobAgent\Transforms

There are many different templates here for different kinds of alerts, but for this example, we’ll concentrate on the normal Work Item alerts.  These are the ones that are used for alerts relating to Work Item changes, reassignment, and status updates, but there are others there for build alerts, checkins and the like.  These two files are:

  • WorkItemChangedEvent.xsl — This is the HTML version of the alert that is usually sent when the alert is triggered.
  • WorkItemChangedEvent.plaintextXsl — This is the plaintext version of the alert. 

Opening these files, you will see pretty standard XSL used the transform the TFS data into the alert e-mail.  For this example, let’s just add a header and create a link to the style sheet that I use for my custom process guidance to make sure the branding is identical across all communication with the end-users of the TFS instance.

So let’s modify the header and body of the e-mail to make things a bit more friendly…

<?xml version=“1.0” encoding=“UTF-8”?>
<xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform&#8221; version=”1.0″>
   <xsl:import href=“TeamFoundation.xsl”/>
   <!– Common TeamSystem elements –>
   <xsl:template match=“WorkItemChangedEvent”>
      <!– Pull in the command style settings –>
      <xsl:call-template name=“style”>
      <!– Link to the Company TFS Style Sheet –>
      <link href=http://processguidance.Company.com/Style/Content.css&#8221; type=“text/css” rel=“stylesheet” />
      <!– Company Email header –>
       <img height=“17” src=http://processguidance.Company.com/Images/EmailHeaderBar.png&#8221; />
      <br />
         <div style=“float:left;”>
            <img alt=“Company Name” height=“40” src=http://processguidance.Company.com/Images/Company_logo.gif&#8221; width=“270” />
<!– End Company Header–>

Now that we have some really basic markup in the header of the e-mail, our correspondence with the end-user will look much better.  Of course, you can dig a bit deeper to change the fields displayed in the alerts or add a footer.  Just make sure that you always have a backup of the original file and test test test!