blog

Working within a single Team Project with Team Foundation Server 2012

Published on
9 minute read

Working within a single Team Project with Team Foundation Server 2012 provides a lot of benefits. There are however many design consideration for working within a single team project and we need to consider all of the complexities that is entails.

One of the customers that I work with has over 200 departments in their organisation that are currently using TFS and each one of those supports one or more teams building multiple products in a single team project. They do not give any of those divisions “Project Administrator” on their Team Projects and in itself sounds like a management nightmare. Why? Well that means that ANY security change needs to go through a central administrator. In order to support this type of situation we need to create some workflow for making sure that everything is setup correctly and some automation so that we can build out the correct permissions without needing direct access. But before we do that we need to look at all of the angles and design our implementation to take advantage of the features in Team Foundation Server 2012.

Working within a single Team Project with Team Foundation Server 2012

Figure: The TfPlugable Team is part of the TfsExtension Team Project

Unfortunately the implementation of Team Project is a little flawed as it imposed some technical restrictions that are difficult to live with and if you look at the top items on the Team Foundation Server User Voice  site you can begin to get a handle on the issues. Even worse, the inability to rename your Team Project is the least of your worries; You can query across Team Project but that’s not the default; You can’t load cross Team Project queries in Excel; You can’t move a work item created in one Team Project to another.

Ultimately we should always have been working in a single Team Project even if we did not know that we were supposed to.

What you describe [single team project] is what we generally do internally and what we recommend. We make very heavy use of area path to categorize the work within a larger project.”
Brian Harry  , Microsoft Technical Fellow & Product Unit Manager for Team Foundation Server

Design considerations for Working within a single Team Project with TFS 2012

Because Team Foundation Server is a group of tightly coupled but flexible services it does not force you into any one way of working like many other tools. So we do need to think about how we are organising our Source Control, Areas, Iterations and Teams to understand how we might be impacted across the board and what our automation workflows are. In our deliberations we have three main entities that we need to cater for:

There many be other things like Work Stream or Cost Code or other flat categorisation elements that you might want to use in your single Team Project. These can easily exist as drop-down-lists on the work items that exist in our requirement work item and don’t necessarily impact the workflows described above.

“Using areas in existing team project instead of creating a new team project (a.k.a. “prefer small number of big team projects over large number of small team projects”) has been established best practice for long time. Microsoft works that way internally and they recommend everyone should. We use it internally and all of our partners have been thought to use it as well.”
- Ognjen Bajic  , Visual Studio ALM MVP, Product Owner of Team Companion at Ekobit

Note You may want to have Teams own projects. If you have many projects and your teams own more than one at ay time you can use Teams without areas  but instead of having a list of “Teams” you create a list of Projects and define which Teams own which projects in the Team configuration.

Team in a single Team Project

In Team Foundation Server 2012 everything within a Team Project revolves around a new feature called Team. A Team is ultimately a security group with a bunch of meta data and features hanging from it (Yes..unlike a Team Project you can rename a Team). In the agile world a “Team” represents a long running tight group of individuals that operate more like a sports team but building software. If you are not an agile team, or in that half way phase of trying to get there, then you might also think of “Team” as something more akin to “Project”. In that scenario you have a time limited group of individuals that operate either full or part time together only for the duration of said “Project”. While the latter would reduce the effectiveness of the Team and would thus be considered a dysfunction it can often be a reality of that awkward transition towards agility.

Working within a single Team Project with Team Foundation Server 2012

Figure: Adding teams working in a single Team Project

In either of these cases you can use Team as the thing that you create instead of Team Project. This Team gives you the bucket of compartmentalisation of work items while allowing those teams to interact in a tightly integrated manor as needed. You also gain the ability to move work items between teams and query cross team with ease. If you are working on a large software project you might have many teams on the same cadence and while you want them to have their own space they still need to integrate and report things together. Or you might have multiple cadences across multiple products and only teams working on the same product work in the same cadence. The Team feature gives you the flexibility to choose you own way and adapt as you grow.

Product in a single Team Project

Product is a thing that you version, create instances of, and then deploy to production. A version of this entity is what is promoted through your release process although you may need to break it down into components if it is really big. Some of your Products will be built in an agile fashion and release at least every 30 days while other will have longer iterations and be delivered less regularly. We need to come up with some way to wrap all of our Products regardless of the things that may be different between them. This interface will allow us to control creation and security by following a pattern that we can automate.

Working within a single Team Project with Team Foundation Server 2012

Figure: Area as Product when working in a single Team Project

Considerations for your Product hierarchy:

Note If we maintain the level at which Product exists in both Area hierarchy and in Version Control then we can easily automate against it.

Note The same rules apply and you can use the same physical organisation as Project of Projects with Team Foundation Server 2010  .

Project in a single Team Project

Project is that time limited group of deliverables that results in a new release of one or more Products. The Project may contain many releases or it may be one. A Product may have many Projects or even just one that contains many releases. We need a model that supports whatever our teams need and that is reflected in Iteration Path.

Working within a single Team Project with Team Foundation Server 2012

Figure: Iteration as Project cadence when working in a single Team Project

Considerations for Project hierarchy:

Conclusion

While I can’t hope to provide a method of using Team Foundation Server 2012 and its features that work for everyone I am trying to create a versatile wrapper for any sort of work that is done within a Team Project. Ideally you would have only a single Team Project within your Team Project Collection and using Teams, Area Hierarchy and Iteration Hierarch we can map to but not into Teams, Products and Projects. The hope is that this wrapper described in the design guidelines above can allow you to automate against the TFS API’s and thus minimise your administration overhead while providing that versatility. There is an awesome post on backlog grooming  that shows you how to configure more advanced team organisation in Team Foundation Server with Teams and there are plenty of other options.

If you are using Team Foundation Server already then there may be a lot of work that needs to be done to reorganise your existing work before you start as well as implementing your new and specific workflows based on the generic implementation above. This is however the only way for an enterprise, or really any organisation with more than one team, to take advantage of the new Agile Project Planning features of Visual Studio Team Foundation Server 2012.

It can however be a lot of work and the great god Murphy  can strike at any time. Plan carefully and make deliberate and tested changes to TFS and your structure to support this.

tools-and-techniques blog area-hierarchy configuration excel improve infrastructure iteration-hierarchy process product project project-administrator tactical team-project teams tfs tfs2012 tfvc tools wiql

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

Philips Logo
Brandes Investment Partners L.P. Logo
DFDS Logo
Flowmaster (a Mentor Graphics Company) Logo
Workday Logo
Genus Breeding Ltd Logo
Sage Logo
SuperControl Logo
Alignment Healthcare Logo
Emerson Process Management Logo
Trayport Logo
Cognizant Microsoft Business Group (MBG) Logo
New Signature Logo
Graham & Brown Logo
Epic Games Logo
Hubtel Ghana Logo
Lockheed Martin Logo
Microsoft Logo
Ghana Police Service Logo
Department of Work and Pensions (UK) Logo
Royal Air Force Logo
Washington Department of Transport Logo
Washington Department of Enterprise Services Logo
New Hampshire Supreme Court Logo
Boxit Document Solutions Logo

CR2

Microsoft Logo

NIT A/S

Lean SA Logo
Big Data for Humans Logo