How big should a project area be? What’s the relationship between Project Areas and Team Areas is an interesting problem and for new users the relationship can be a little hard to understand. This post describes the relationship between them and some experiences of using them.
I’m going to write a series of posts on top tips based on experience and real projects of using IBM RTC for Disciplined Agility. It’s a bit of a brain dump, but here goes… they’re all tagged as rtc_tips if you want to read the whole set :
Simply put a Project area is for work that will share the same work items, workflows, visibility (as of v2, v3 improves on this). Team areas are areas inside a Project Area that you can use to scope plans, burndown charts, dashboards etc. Initially therefore it might sound sensible to create quite large Project Areas and then create Team Areas inside the large area for each project/endeavour (what I call Model C) but there are some problems with this idea:
- it’s not easy for users to create new team areas with all the associated things that need to go with them (timeline, categories, dashboard etc. – the team dashboard templating is rather limited so you can’t easily parameterise queries on a template)
- people with rights to a project area can see all work items in that area (true for v2 but this has been somewhat improved in v3 allowing you to set 1 arbitrary project area to control the access to a work item regardless of it’s “parent” area)
- once you have more than 2 teams and more than 2 timeline the navigation of current plans and understanding how to scope plans/charts etc. gets too messy for the average user. Indeed every real life team I’ve worked with that has used multiple timelines & multiple team areas in a project has after a while decided to split them up into separate project areas.
These factors have pushed me to always create a Project Area per project/endeavour (which I call Model A) which gives you better access control/visibility, permissions control, well templated project dashboards & navigability. However there are some downsides:
- You can’t write cross-project queries. Or at least the capability is severely limited even if you exploit bugs in the querying engine. It is possible to put viewlets from multiple projects side by side on a dashboard but it’s not possible to do things such as “Show me the top risks by priority for these 5 projects” or more importantly “Show me all my tasks by priority from all of the projects I’m a member of” – see Jazz.net work item 94575 for more on this.
- As a result it’s not so easy for an individual to work across a number of projects although cross project dependencies and traceability queries are just about ok (in Eclipse if you show relationships, but not really in the web)
- Once you get a large number of projects on your server it becomes a little annoying that you can’t manage them other than as a flat list (sort by “My projects” then “All projects”)
I’ve come to think of these different options for structuring RTC on a scale of simplicity to complexity and factors that push you one way or another:
Structural choices for RTC configuration
Model A says [0..]1 Team Areas because although it’s possible to configure RTC to only have 0 team areas and make everything scoped to the project area I’ve found that to be a bit buggy, especially in templated charts on dashboards. So the simplest model I recommend is 1 Project Area with 1 Team Area. You can do quite a lot with Model A by using categories well, and having views of plans by category with different category owners. I’ve used this model with teams from 3 to 50! The best advantage of this model is that for any time period there’s only 2 plans, the overall Product Backlog and the current Sprint Plan. (Maybe a release plan, but that can be optional as it’s just a subset of the Product Backlog).
For non-software this Model still works but depending on the required simplicity I would either go for no plans at all, or a single plan that is a mix of the Product Backlog and Sprint plan views.
Model B offers a bit more complexity in that there are multiple teams, seperated by categories but sharing a timeline. The advantages of this model are that you can manage multiple teams in seperate backlogs and plans but you can also create backlogs/plans that span all of the teams giving you individual views and an overall view. The downside is that this can start getting quite complex in terms of navigation as for any time period there can be a multitude of plans, not including release plans (as optional as before) that leads to 2 * (no. teams +1) plans if you’ve got 3 sub-teams and you’re on 2 week sprints that can be 8 plans for the next two weeks!
Model C offers fully seperated teams in their own timelines and categories. This is a bit like Model B but they can be on their own rhythms. In fact in this model the My Work box in Eclipse can’t quite cope with the multiple timelines so users really are quite seperated, to the extent that they may as well be in different projects – so I say they should be. It’s better to have multiple Model A’s than a single Model C.
Obviously this is all generalised stuff based on the projects I’ve been involved with and other factors would affect the decision, notably SCM considerations over how component source needs to be dealt with across teams. Having multiple somewhat seperated teams, on their own timelines editing the same code base might make you want to adopt Model C but if you’re in that situation you’ve got bigger problems than navigating a set of complex plans! In fact to unpick the problem I would still recommend multiple Model A’s with their own dev streams, then deal with integration from an requirements, test and SCM perspective in a master project, which is where your Scrum of Scrum behaviours can be implemented.