Hi Paul,

I've been working on how best to use RTC for a development team with very similar characteristics to yourself and have come across and reached the same conclusions as you.

The key is that there is a 1-M relationship between a development line and team area (i.e. one development line can have many teams), but then this means that you need to duplicate teams when you have more than one development line.

So, in a typical product where there are overlapping product cycles, the complexity starts to grow.

However, I think this approach is probably ok for most cases. The one thing that does bug me however is the fact that work assignments are not smart enough to recognise the team area to development line mapping and instead you end up with something like this:

http://dl.getdropbox.com/u/204132/assignments.jpg

Hi, Paul.

Everything you're doing here sounds reasonable.

About your work item categories... fortunately, these don't have to be
duplicated. The work item category editor lets you associate the same
work item category with a different team in each development line. It
may not immediately jump out at you, but above the tree of team areas on
the right side of the categories editor you'll see a pulldown to choose
a dev line.

Jared Burns
Jazz Process Team


sims wrote:

I'm consulting the community because I'm not sure we're implementing
good practices in setting up our RTC environment. We're using the
Scrum Process Template. So far we're only using RTC for planning and
tracking, so we can put SCM and build considerations aside. (Or can
we?) Our organization consists of about 200 developers, testers,
writers, and UX professionals organized into about 20 Scrum teams
that span three geographic locations.

When we started using RTC, we created one project area, one team area,
and multiple sub-team areas, one for each Scrum team. We also created
one work item category per team area and associated each category with
its corresponding team. So far so good? We were able to create a
product backlog and sprint backlogs for each team and all seemed to
work well.

We now want to track development on three different deliverables
(releases). The teams and people are the same, but the releases are
on slightly different schedules and are happening in parallel.
Initially I thought we would use separate project areas for each
release, but realized that meant duplicating team areas and reports;
not what we wanted.

Earlier this week I created two additional development lines. Now we
have one line for the main release, another for a feature pack, and a
third for another deliverable. I created an iteration for each of the
deliverables, and iterations for the sprints in each deliverable. How
am I doing so far?

At that point I thought we were set but quickly learned that to have
separate sprint backlogs for each development line, you also need to
define separate team areas. When you create a sprint backlog, you
have to specify the project area, team area, and iteration. What I
found is that by selecting the team area, I am implicitly selecting
the development line (release) and therefore the corresponding
sprints. I was hoping that the iteration would be independent of the
team area, but it is not.

Now I'm creating additional team areas for teams who are
simultaneously working on two development lines. Is this the best
approach? Can we still share the teams' work item categories across
the three development lines, or should I be thinking about creating
additional work item categories too?

I was hoping to keep the structure simple, but it's grown more
complicated now that we have three development lines. Is there a
better way to set up our environment?

Paul Sims
IBM WebSphere Commerce

Wow, this is SO familiar. You have exactly described what we've been
going through the last few months. I am also using RTC for a large org
and multiple deliverables being developed in parallel, so have multiple
development lines. We differ slightly in that we decided to fix the
iteration dates across all the development lines. We view the concept of
a Sprint as a commitment from the team to deliver. If one deliverable is
in trouble people can be reassigned at the start of a Sprint and we
won't be moving people around in the middle of a Sprint because
everyone's on the same schedule.

One of the principles of Lean is to prevent context switching, so
structuring the teams in a way that they only work on one deliverable /
development line at any one time is the nirvana. For us, this isn't the
case because a large number of our teams are teams of specialists and so
they're potentially needed across multiple development lines. But we're
aiming for the above Lean principle. Until we get there, which may never
happen completely, we're going to have teams of people who are
represented as multiple team areas in Jazz - one for each development
line. It then comes down to each team member to be involved in multiple
Sprint planning meetings and be able to track their work in the 'My
work' view.

Since you don't have iterations sync'd across all development lines then
I think you have a much more complicated situation. Is there a way you
could sync your iteration dates without sync'ing the release date?

In terms of what could be improved in Jazz / RTC. I'd describe the user
story like this:

My development teams are (for now) organized in teams of specialists and
they work across multiple development lines concurrently. So: as a
product owner I'd like each team to be managing a single Sprint backlog
at any one time with the goal of minimizing the complexity of managing a
Sprint backlog.

We did toy with the idea of having a single global development line and
use the 'found in' (release name) field as the way to indicate which
deliverable the work items are meant for. So now a deliverable is
represented as a release name rather than a development line. However, I
don't think this is really the way the releases are meant. They're meant
to be for code that's actually been shipped, rather than in development.
I concluded this because there isn't a 'found in' field in the Story
work item category, just in Defect and Task. So with a single
development line across all deliverables there's no way of indicating
which deliverable a Story work item is targeted to. We could solve this
ourselves by adding the 'found in' field to the Story work item type in
our process configuration. But ...

The other thing that won't work with a single development line is
reports. The Burndown report needs a team area and an interval. If it
required a 'found in' / release name then we'd be able to produce a
report that's specific to a deliverable. We could go through all the
reports adding the 'found in' field as a parameter to the report.
However, this would break the dashboard which only shows reports of a
specific type - those that accept a team area and an interval as
parameters. At this point we concluded to go with multiple development
lines.

In terms of how this might be done in Jazz / RTC: allow development
lines to be grouped together. A top level team area is responsible for
either a single development line (which isn't in a group) or for a group
of development lines. For development lines that are grouped together,
there is a single set of iterations. When a team creates an iteration
plan it can be for a group of development lines.

Regards,
Jeremy

On 10/12/2008 12:58, sims wrote:

I'm consulting the community because I'm not sure we're implementing
good practices in setting up our RTC environment. We're using the
Scrum Process Template. So far we're only using RTC for planning and
tracking, so we can put SCM and build considerations aside. (Or can
we?) Our organization consists of about 200 developers, testers,
writers, and UX professionals organized into about 20 Scrum teams
that span three geographic locations.

When we started using RTC, we created one project area, one team area,
and multiple sub-team areas, one for each Scrum team. We also created
one work item category per team area and associated each category with
its corresponding team. So far so good? We were able to create a
product backlog and sprint backlogs for each team and all seemed to
work well.

We now want to track development on three different deliverables
(releases). The teams and people are the same, but the releases are
on slightly different schedules and are happening in parallel.
Initially I thought we would use separate project areas for each
release, but realized that meant duplicating team areas and reports;
not what we wanted.

Earlier this week I created two additional development lines. Now we
have one line for the main release, another for a feature pack, and a
third for another deliverable. I created an iteration for each of the
deliverables, and iterations for the sprints in each deliverable. How
am I doing so far?

At that point I thought we were set but quickly learned that to have
separate sprint backlogs for each development line, you also need to
define separate team areas. When you create a sprint backlog, you
have to specify the project area, team area, and iteration. What I
found is that by selecting the team area, I am implicitly selecting
the development line (release) and therefore the corresponding
sprints. I was hoping that the iteration would be independent of the
team area, but it is not.

Now I'm creating additional team areas for teams who are
simultaneously working on two development lines. Is this the best
approach? Can we still share the teams' work item categories across
the three development lines, or should I be thinking about creating
additional work item categories too?

I was hoping to keep the structure simple, but it's grown more
complicated now that we have three development lines. Is there a
better way to set up our environment?

Paul Sims
IBM WebSphere Commerce

I'd loved to see a Tech Note on this topic -- I've struggled with it as well. I've considered writing such a thing, but I'm still struggling to understand it, much less explain it reasonably to others. And any reasonable approach would take some real work -- actually setting up the Project Area, populating the people and Team Areas, building Development Lines and Iterations and Iteration Plans, adding Stories and Tasks and assigning them and generating a reasonable collection of reports to see how they turn out based on the configuration.

And you'd want a couple of examples, each of which was big enough that the pattern would be visible and could be extrapolated for even larger projects. A "small" example might be two dozen team members, at least three sub teams, at least a Main and one Sustaining line. A reasonable size example would probably be closer to 50 team members and an appropriate proliferation of sub-teams and active development lines.

Maybe we could take up a collection to motivate a potential author? I'll put $20 USD (which ain't worth what it used to be) into the hat... ;-)

Hi,

Putting the exchange rate to one side for a moment :-)

I do think that there would be value in a dW article or similar around using RTC for medium/large scale multi-release projects. I'd be willing to collaborate on this if anybody else is.

... you're offering me $25 to do the work. That's equivalent to a Thanks! Award. :-)

If you'll do this much work for a Thanks! Award, do you want to join my team? :-)

Okay, since at least a couple folks took the bait, let's do this. All that time off during the holidaze was going to make me crazy anyway. I think it would make a fine developerWorks article (I'll hit up the fellow that handled my RTC with Scrum article to see if he's interested).

Anyone else want in? I'm assuming we can bother the APT team ('cause we'll need them), but I'd be delighted to have one of them completely onboard.

Do we want to conduct business in a series of forum threads? Or maybe fire up a wiki page? Or a Bluehouse area or Quickr place? We'll need screenshots and attachments and stuff, so a forum thread may not work, but I'm fine with having the ugly process of building an article out in the open. Quickr or Wiki might not be public enough if we pick up a non-IBMer contributor. I'll look into Bluehouse and get back to y'all.

The first step is to identify a couple unnamed candidate teams and their mode of operation as our scenarios. Need an org chart, description of the team's makeup, product components, development lines, etc. No theoretical mumbo-jumbo, even if the team is unnamed, let's make sure we have at least one real beneficiary. Maybe a first pass with a medium sized team, then we can look at what we did and determine if we need Part II to address even larger teams or if the interested observer can extrapolate on their own.

I've been following this thread as I have a similar project I'll be working on over the next couple months (see https://jazz.net/forums/viewtopic.php?t=2948). I'm also interested in contributing to an article.

Regards, Brian