Planning Team Projects
When starting to work with Team System, one inevitably gets confronted with a lot of self posed questions about how to structure or organize Team Projects. While there was little or no information about this available at the launch of Team System, Microsoft put up some information on how to ‘Plan a Team Project’ after a while. They state that four categories of questions should lead you to the best way to organize your Team Projects, categories are:
- Questions about the Current Team Project and Your Future Work
- Questions about the Capacity and Performance of the Team Foundation Server
- Questions about the Structure or Hierarchy for Organizing the Team Project
- Questions about the Preferred Software Development Process
This is all great information but in the end you will have to decide for yourself if the choice you get by following this guidance is the exact solution you wanted or expected to have (or not). For us it was not… The main reason for this is that we are organized in a very specific way; now I know you were afraid of this from the start, but let me elaborate.
Projects versus Maintenance
Basically our shop is divided into two groups. We’ve got people belonging to the Projects Group and others belonging to the Maintenance Group. I think it’s pretty obvious and self explanatory what these teams do, but still, I’ll tell you J
The Projects Group
- Is divided into several project teams
- executes each and every new project
- lives on short term assignments (project scope)
- uses latest version of framework, etc…
- task management & reporting related to one specific project
The Maintenance Group
- does maintenance on each and every project delivered by the Projects Group
- lives on longer term assignments
- maintains projects built on different versions of the framework
- task management & reporting related to monthly delivery milestones
At this very moment we’ve got 4 different projects running, all staffed by members of the Project Group, the Maintenance Group currently has more than 50 applications in maintenance. So we had to look at the situation not only in two different ways but also had to cater for the scenario in which projects move from a project phase to a maintenance phase. And keep in mind this move means handing it all (software, documentation, …) over to a different set of people.
Projects
What we feel is important for projects is that we:
- can assign a limited set of people (team members) to a certain project
- are not bound to one and only one Project Template which is not upgradable at all
- are able to report easily on one specific project
- do not have to follow the same pace in terms of iteration and/or release dates
So in our scenario each new Project we start gets its own Team Project created with the latest version of the Project Template. This way we are not long term bound to one specific Project Template. Our early Team Projects were based upon the MSF for Agile Project Template after which we moved to the Scrum for Team System Project Template from Conchango and finally ended up with a customized version of the latter. Some of you might think ‘well ok, but isn’t there a certain limit in the amount of Team Projects one is able to create in Team Foundation Server’. The answer would be ‘Yes, there is, but read on…’
Maintenance
What we feel is important for maintenance is that we:
- can assign a group of people (team members) to a maintain all projects
- can use one type of Team Project for all projects
- are able to report easily on all projects
- can follow the same pace in terms of iteration and/or release dates
To accomplish this we just created one Team Project for the Maintenance group, each project that enters maintenance phase is then moved to the Maintenance Team Project. We made this very easy by organizing our source control folders in an organized way. In the root folder of a new Team Project we create a sub folder stating the name of the project and all other artifacts are to be stored beneath it. This was we can easily move that folder to another team project, taking all what’s in it, with it. Once the move is complete, we remove the Team Project itself, which keeps us far away from the capacity induced limit of (worst case) 250 Team Projects.
There are some back draws to this but we can live with them:
- While change sets are preserved, work items are not. So you will still be able to see who f*cked up but not which task he linked that specific change to.
- Moving stuff away from one Sharepoint site to another is not that simple. The fact that it isn’t simple does force you to think about the nature of the documentation being short term, midterm or long term;
- We have to modify the Build Types when moving them to the Maintenance Team Project*
- Only one Build Type for the same project can run at the same time*
(*) nothing that a new version can’t fix 🙂
Ok, that’s about it for now, if I left something out feel free leave a comment and I will try to answer as soon as possible…
Thoughts on IT 
Hey Peter. I’m from Microsoft and I work on Team Foundation Server. As it so happens, we are designing what team projects look like in the future.
I like your distinction between Projects and Maintenance. What I understand is that after a Project is completed, you move the source to the Mainteance folder. So a project is closed down in that it produced a release, but the source code is moved to “Maintenance Mode” is that correct?
One question I have is what if you have another Project that produces another major release of the same product. Does your model have you doing maintenance on multiple versions, or just one?
Also, if you had your way, would you have a team project for each of the products in “maintenance” mode, as long as you were able to enforce process across all of them, and report across all of them easily? It would seem that would be helpful for things like builds, websites, bugs.
Here is an old post of mine about Team Projects:
This is awesome !!! Good work