ALM Rangers switching to single TPC/TP and multiple Teams model
We shipped the Team Foundation Server Planning Guide BETA a while ago and are currently in a holding pattern waiting for feedback from our product owner for the release candidate which is dusted, packaged and waiting for a go-for-launch sign.
In parallel the infrastructure working group is looking at continuous process and infrastructure improvement. One of the tasks is to prepare the team environment for the next wave of projects, which introduces new concepts such as discoverable queues for small ad-hoc tasks, centralised backlog and bug management and aligning our own infrastructure with our latest guidance.
So, let’s take a quick detour into some of the new concepts:
Discoverable queues for ad-hoc tasks
The typical ALM Ranger project has a small, geographically dispersed team and a bucket of challenges, which Brian covered in ALM Guidance: Visual Studio ALM Rangers — Reflections on Virtual Teams. The usual duration of the project ranges from 3-6 months, which requires an active part-time team over a fairly long period of time.
This already challenging ecosystem is a blocker for a few ALM Rangers, who can only deliver short-spurts of commitment at random times.
What the infrastructure working group is investigating is the introduction of an ad-hoc, self-contained task queue, from which these ALM Rangers can pick a task when and as they can. For project teams it is a place to drop (but not forget) self-contained tasks, which can be worked on in parallel to their project. A win-win situation 
Centralised backlog
Our current model is a single Team Project Collection and as shown 32 separate Team projects. The advantages are project and team isolation, however, the overall “wave of projects” monitoring and management using the tools out of the box, has proven a challenge. As shown below, the visual feedback is exception for individual projects, but to create reporting and especially overall burn down diagrams is not straight-forward.
Our wish list states one backlog for the ALM Rangers, which can be sliced, diced and viewed as one or from a specific project view.
Centralised bug management
The same challenges and wishes we have for the backlog applies to bugs. Using WIT queries that traverse all projects is feasible and used in our environment, but ensuring that the right bug is raised against the right team project, is adding unnecessary churn.
Aligning Rangers infrastructure with latest guidance
Stepping through the Team Foundation Server planning guide, as shown in one of the cheat sheets with highlighted decision paths, we come to the conclusion that Team Foundation Service is a good deployment model.
We probably need one Team Project Collection and one Team Project for the mainstream ALM Ranger solutions. Each solution, project and initiative would be isolated in terms of a specific Team, owning its own backlog and area path.
The experimentation team project,in our new world would potentially look like:
Default Team
Let’s define the iterations and associate the area for our default, core team. Note that the “Black Hole” iteration spans both Team X and Team Y sprint. We start when the first team starts and finish when the last crosses the line.
Team X
We do the same for Project X …
Team Y
… and finally for Project Y.
Test Data
Our test data is simple. We create a few Epics and one task for Project X and two tasks for Project Y.
Team X View
If we switch to Team X we get the familiar and informative home page. Switching to the board, we see the only task we created for project X.
Team Y View
In the project Y world we see one of the two tasks we created for the team, which falls within Sprint 1.
Consolidated Board View
If we switch to the default team, we see the correct accumulated 9 hours, but as expected see no burn down. Switching to the board, however, we suddenly see all the tasks which are being worked on by team X and Y.
The advantages we see in the single TPC and single TP model are:
- As Gregg mentions in Team Foundation Service Preview – Configure a master backlog and sub-teams, we will have one backlog to rule them all
- We will drill into specific projects and sub-team backlogs, board and status, or switch to an overall view.
- We will have less context (team project) switching needed by ALM Rangers working across multiple projects.
- We will be able to share and re-use queries easier amongst the various teams.
The disadvantages we are pondering over:
- It will be like merging a few teenager caves into one room. We will have to be proactive in terms of avoiding messy or non-actionable backlogs.
- When a project is cancelled the deletion of its state will not be as easy as running the tfsdeleteproject command .
- Would be “cool” to see a burn down for Consolidated (default) View as well … pondering over optionsat the moment.
Thoughts? What do you think of our new single Team Project Collection and Team Project suggestion?
Comments
Anonymous
April 28, 2012
Your disadvantages are all wrong: •It will be like merging a few teenager caves into one room. We will have to be proactive in terms of avoiding messy or non-actionable backlogs. ANSWER - Use areas and iterations and TFS Security to restrict access. Security and Active Directory Groups will be your friend look here: social.msdn.microsoft.com/.../b40cebfb-3a35-468e-b147-021fd3824a77 •When a project is cancelled the deletion of its state will not be as easy as running the tfsdeleteproject command. ANSWER - tfsdeleteproject is a cop out. When a project is cancelled just move the area/interation under a hiearchy called canceled.Anonymous
April 28, 2012
The comment has been removedAnonymous
April 29, 2012
The comment has been removedAnonymous
April 29, 2012
We are aware of the granular security model in TFS :) ... but as mentioned every ALM Ranger has (full) access to everything, which include our Team Projects.