Mike MacDonagh's Blog

Somewhere in the overlap between software development, process improvement and psychology

RTC: Structural patterns for Project Areas vs. Team Areas

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.

Advertisements

5 responses to “RTC: Structural patterns for Project Areas vs. Team Areas

  1. Ksenia Mukhortova November 11, 2011 at 8:12 am

    Hi Mike,
    This post was really interesting as at the moment I’m trying to define, which model to choose. We have a complex product, that consists of number of smaller products integrated on late stages of development. And I’m choosing between Model A and C. The only thing that makes me think of Model C is that we’ll need to see joint plan for the whole large product along with plans for component products, milestones in those plans should be synchronized. Is there any possibility to have shared milestones between project areas and joint plans (at least in readonly mode) in Model A?

    In any case, thanks for the post!

    Regards,
    Ksenia

  2. mikemacd November 14, 2011 at 11:40 am

    Hi Ksenia,

    Unfortunately there’s no way to have sync’d milestones or joint plans across project areas so you’ve got a couple of options:

    1) Put the milestones in a “parent” project area with dependencies on work in the “child” project areas this allows you to run queries showing the milestone progress by date and open dependencies across project areas, although not in plan view.

    2) Put them in 1 project area in model A and separate them by category (or some other field), remember you can always filter plans down to a single category to view them in isolation.

    Cheers,

    Mike

    • Ksenia Mukhortova November 14, 2011 at 12:46 pm

      Hi Mike,
      When you say “parent” and “child” project areas do you actually mean team areas? As I understood, there are no nesting of project areas. Or am I missing some concept here? Sorry for possibly silly questions, I’m new to RTC.

      Regards,
      Ksenia

      • mikemacd November 14, 2011 at 12:58 pm

        Nope, I mean project areas. You’re right they can’t be nested, that’s why I put “parent” and “child” in quotes. There’s no structural relationship between project areas, but you can still write queries against the web of related work items regardless of where they live. It’s well worth experimenting a little with this technique. Hope that helps 🙂

  3. Anonymous July 1, 2014 at 8:51 pm

    We used the model of single project area with mulitple teams – yes it was a bit of a struggle getting managers and stakeholders to understand the process especially since RTC was new as well – but it made a lot of sense as we created separate timelines/iterations/plans/dashboards.
    This was also useful as most of the team members were in more than one team and securing them was a lot simpler. We created separate development streams and as there was merging going on between the different streams to keep the main development stream in sync with updates from multiple teams this model was required/came in handy.

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: