Back to the ‘teams’ topic, it is new in TFS11 … (see below the previous posts about this topic)
- http://www.clemensreijnen.nl/post/2011/10/09/Teams-in-VS11.aspx
- http://www.clemensreijnen.nl/post/2011/10/10/Teams-in-Visual-Studio-11-feature-teams-and-backlogs.aspx
- http://www.clemensreijnen.nl/post/2011/10/12/Teams-in-Visual-Studio-11-CTP-the-Bug-Backlog.aspx
Beside using the new team concept in TFS11, you also just can do it the ‘old’ way. Put all your team members in the different TFS Groups (readers, contributors, … ) and give them access to the team project. Just as you did the past decade. But, you have to understand what happens when you do it. You also can mix things, create teams and only add TFS groups to it, or give people specific rights within a team… actually you can make it a complete chaos. In this post some usages scenarios. (at the end of this post a final conclusion, maybe you want to read that one first.)
Scenario 1: A team project with no teams and only team members in TFSgroups configuration.
When you create a team project, you get by default a team with the team project name, prefixed with ‘team’. This default team has one member, the creator of the team project. Which as you can see I deleted.
When you browse to the administration page, you will notice that you can’t delete the default project. but, with no members it can’t do any harm.
Next, you can start adding members to the different TFS groups. For example I added several people to the contributors group.
Following step, make security settings for the different groups... for example for the iterations
or the areas. You can find it at the same places as you can in VS2010.
Interesting is that the security settings for the source repository only can be set in Visual Studio.
When you have a team project without a team (beside the default team), you do have a backlog, with a board.
Everything works as expected, only the capacity planning seems to be broke. The ‘only members in tfs groups’ project gets a bit more complicated when you start working with area’s. For example add two sub-areas and mark one of them as current.
Good to know when you mark the parent area as the current one you can set a child area as default. When adding backlog items by using the backlog it will automatically set the area property.
Doing this and adding PBI’s and backlogs to the this area. Will result in a new backlog and new task board, helping the team members (which are only in TFS groups) to focus on this specific area only. Set the area setting to the parent area, including all sub area.. will result in a combined backlog.
The only thing what stays the same when changing the areas for your team project are the Team favorites (we don’t have a team :) and the queries behind it don’t have a current area path clause. You could add it yourself.
Conclusion
It is possible to create projects without using the new Team concept. Things look a bit strange, we have team favorites but no team members for example. But the main functionality works. It only gets a bit complicated when you start using areas and make different people responsible for different areas. You have to swap between the admin page and the home screen when you want to see a different backlog / functional area.
Scenario 2: teams only
I created two additional teams for the two different areas, added the team members to the default team and added the default team to Team 1 and 2.
All teams are in the contributors TFS group, resulting in the fact that all team members have the same security settings.
Having you teams setup in this way, gives them the easy capability to swap between the teams. The backlogs are up to date and the team capacity planning works. One annoying thing, the team favorites, the work item queries, are the same for the whole project so I have to create queries for every team and add them as team favorite.
Scenario 3: teams with tfs groups
Another scenario, for playing with security, teams and TFS groups is… adding the team members to TFS groups and add these groups to the teams as members. Now, you have members in your team with different security settings. Doesn’t feel really scrum, but it works.
Only the TFS Groups Readers and Contributors in the the default team and Team 1 and 2 have only the default team as team member.
Scenario 4 and 5 Teams with team members with specific security settings.
The last scenario, is where you add only users to your team and set explicit security settings per team members.
I won’t recommend this, you really can’t administer this.
Final Conclusion.
So, after this small journey across the different possibilities of configuring security settings in TFS11, I must say… Be careful, you can create chaos which you aren’t able to administer anymore, and think up front about your areas and team structure, it influence the usage and capabilities of the nice agile tools.
- Scenario 1: No Teams only TFS groups with Team members.
You can use the backlog and task board, the capacity planning doesn’t work (yet?). It gets complicated with multiple areas and multiple backlogs. For example when you want to use a bug backlog, don’t use this scenario go for number two or three.
- Scenario 2: No TFS groups only Teams with Team members
This feels like the only real agile solution, all team members have the same security settings and the usages of multiple backlogs is easy.
- Scenario 3: Teams with TFS Groups with specific security settings
When you want to have team members with different security settings, this is the way to go. Areas and multiple backlogs are fully functional including the capacity planning.
- Scenario 4: Teams with Team members with specific security settings
Forget this one… you will go crazy over time
- Scenario 5: Teams with Team members with specific security settings and with TFS Groups with specific security settings.
You not only will be crazy you probably will have to go to the hospital when you try to maintain this scenario.
For now… number three is my favorite, number two is more pure… one is ok, four and five not ok.