.NET Zone is brought to you in partnership with:

Martin has worked with many customers in government, finance, manufacturing, health and technology to help them improve their processes and deliver more. He provides management and technical consulting that intends to expose processes and practices to gain transparency, uncover impediments to value delivery and reduce cycle-time as part of an organisations path to agility. Martin is a Professional Scrum Trainer as well as a Visual Studio ALM MVP and Visual Studio ALM Ranger. He writes regularly on http://nakedalm.com/blog, and speaks often on Scrum, good practices and Visual Studio ALM. You can get in touch with Martin through naked ALM. Martin is a DZone MVB and is not an employee of DZone and has posted 64 posts at DZone. You can read more from them at their website. View Full User Profile

One Team Project

07.15.2012
| 3350 views |
  • submit to reddit
I have talked often of the idea of a Project of Projects in Team Foundation Server and with the new feature in Visual Studio 2012 Team Foundation Server I though it would make sense to revisit. I will talk a little of the idea of the Master or Hierarchical Backlogs using the new Agile Planning tools and I always find an example help with understanding so I will be using a recent engagement as a base. But first lets dispel a few myths.
  • Team Project ≠ Team
  • Team Project ≠ Project
  • Team Project ≠ Product
  • Team Project = WTF?

You might think that it has been unfortunately named, but the Visual Studio ALM tooling has been designed to have a low barrier to entry and as such the happy path is:

  • Team Project = Team
  • Team Project = Project

Have I confused you yet?

Well, for the single, or small group of developers the common and easy path is to create a new Team Project for each project and they will only ever have one team. So this is the way that it is out-of-the-box and it serves its purpose.

One Team Project to rule them all

The rest of us live in a more complicated world of multiple teams, multiple projects and multiple priorities. To achieve this we need to think about the following things in Team Foundation Server:

  • Teams (can be mapped to Area or to a Work Item Field Definition)
  • Areas (Tree)
  • Iteration (Tree)
  • Source Code  (has folders)
  • Work Item Queries (has folders)
  • Build

No matter what our configuration and requirements we can use a single Team Project. There are however a number of circumstances where you will not be able to do this:

  • A large consultancy

    If you are in a large consultancy with 1000+ customers then it makes more sense to use a  one Team Project per customer model so as to avoid confusion and scaling issues. Don’t think just because you are a consultancy that you need to use this model. Think carefully about your choice…

  • An organisation with 100’s of Teams

    If you are a single organisation that has 100’s of teams than you might also run into limitation of scale. I would in this case recommend that you have one Team Project per Department or Division depending on their scale and organisation.

  In these cases there are two limitation that need to be considered carefully. You can only have 254 areas per level and there is a soft limit of about 300 Team Projects per Team Project Collection. 

If neither of these apply (or you are at the Customer, Department or Division level within an organisation within which it does) then you can achieve a single Team Project.

One Team Project to find them

So, what has changed? Well with the advent of the idea and the technical implementation of Team in Visual Studio 2012 Team Foundation Service we can take advantage of the new constructs and reduce our complexity while simultaneously increase our features.

I do however have a reality check for those of you that want to use the new tools but work within a traditionally run organisation.

More than 34% of companies are now doing agile
Figure: More than 34% of companies are now doing agile

They are called the “Agile Planning” tools for a reason. They are exclusively targeted at the ~34% of the industry that are working in an Agile manor and that are 3 times more  likely to succeed than a traditionally run project. They are also aimed at the 30% that don’t really know what the want as an easy adoption path.

Agile projects are 3 times more likely to be successful
Figure: Agile projects are 3 times more likely to be successful

Does this mean that those of you can’t use the Agile Planning tools? Hell no! It just means that you are not in the happy path so make the most of them that you can.

One Team Project to bring them all

In a recent engagement my customer needed some rather specific things to be possible but also wanted to take advantage of the new Agile Planning features. They wanted to pull together all of the Teams and individuals from the Business all the way through the Development Teams to Infrastructure. To achieve that we identified a few must haves:

  • Must be able to see an ordered backlog per team
  • Must be able to see an ordered backlog per department/customer
  • Must be able to see what product and product area each work item is assigned to

In order to achieve this all I need to customise is to add a single new field to the Product Backlog Item. Is we add a “[mycustomer].Customer” field to the PBI and make it a drop-down-list of all of the existing customers

image
Figure: Adding a field to store the external customer

I can then create a query for each of the customers to show the backlog and allow anyone with permission to view that backlog.

image
Figure: A Query showing an external customers backlog

If I can query it I can then export to excel and reorder it just like we did when connecting to TFS 2010.

image
Figure: Reordering the backlog in Excel

So with a single added field we have enabled not only querying and ordering of data associated with a customer, but we also made the field reportable as a dimension in the data warehouse and cube.

Awesome and easy…

Now all we need to add is two teams in the new Agile Planning tools in addition to the default and configure them to only show their own backlog based on the Area Path (or we can configure it to use a Team drop-down).

The point is that we can support most, if not all configurations as long as you are willing to change the way that you work a little. Hopefully not much, but there is always change in adopting a new tool. Although we don’t want our tools to prescribe our workflow, we may actually want to change the way that we work to take advantage of cool things that we just had no access to before.

And in the Process Template bind them

The key to a successful Team Foundation Server deployment is in the Process Template that is chosen to be the base moving forward. I always start with the Visual Studio Scrum template as a base as it has the most compatible workflow and terminology to the way we tend to speak and discuss about work.

Remember that whatever process template that you pick it is but a starting point for building your own process on top of. Don’t be afraid to customise, just don’t go nuts… no one likes a frankin-template…

Conclusion

Not only is larger Team Projects the recommendation of almost all of the experts in the field, it is also the recommendation and expectation of the product team for mature teams and organisations using Team Foundation Server.

How are Team Projects used at your organisation?

Related Posts:

-Do you want to move to Visual Studio 11 Team Foundation Service NOW? Microsoft is providing a Go-Live licence (that means that it is supported in production) and you can use it today! For help moving forward contact info@nwcadence.com

Published at DZone with permission of Martin Hinshelwood, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)