Good practices for setting up RTC environment
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 |
32 answers
I'll be out over the next couple weeks as well, but should be focusing
on a usage model for our project starting first thing after I return from the holidays. Brian |
Millard Ellingsworth (2.5k●1●24●31)
| answered Dec 17 '08, 6:12 p.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER And if you want to bounce a draft of the article off of a Jazz/RTC "newbie" to make sure it's written "for dummies," I'd be happy to review it. We will take you up on that. Need to find a couple of reviewers (I've put your contact info on the story, so you'll be hearing from us). Those who have said "count me in", you're in and should have received an invite from RTC by now. If you want to work and contribute to this effort and you have not received an invite, please send an email directly to me. I won't be monitoring this thread looking for folks after this. |
Did anything (for example, a TechNote) come out of this effort?
I'm struggling to understand how all of these fit together in a multi-team, multi-release environment: * Team areas * Iterations * Work item categories * Components * Releases Thanks, Gary |
|
Millard Ellingsworth (2.5k●1●24●31)
| answered Feb 20 '09, 12:07 p.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER Did anything (for example, a TechNote) come out of this effort? I'm still trying to pursue this, but my team and the RTC team both have summer ship dates, so time is tight. I'm making some progress, but it will still be weeks before there is something worth sharing. |
Has any article or technote been produced for this topic?
I also have a project area with multiple teams and deliverables that overlap. We're using a single timeline to minimize the complexity of the project area, categories and teams. At the moment, I have one large team that needs to be divided into subteams. Should the subteams be set up by grouping the deliverables? Should we set a category for every deliverable and assign it to the proper sub-team and corresponding stream? How does this affect "Found in" and release artifacts? The bottom line is... how do you minimize complexity when there are multiple teams responsible for multiple deliverables? It seems to me that creating multiple timelines in this situation creates havoc on Team hierarchy and Plans. What are the trade offs? |
Just thought I'd add a reference to the RTC deployment guide.
It makes some recommendations for process setup: http://jazz.net/library/article/398#Process_Configuration but doesn't really cover recommendations for structuring development lines. I agree that would make for a useful article and/or addendum to the deployment guide. |
Hi folks,
I'm VERY interested in such an article. We struggled a lot to set up our first environment, and there are still some "dark" zones in our structure that I would like to clarify (we also have distributed scrum teams). Just as Mike Johnson, if you need I could help on reviewing the document providing an outside-IBM point of view. Hope to hear from you! |
Hello All,
I am wondering if there is any artifact out of the earlier discussions. I'm also very interested in such an article. |
Me too.
I find "structuring development lines" is quite confusing during a pilot. BTW, I can find little guidance on this subject in Internet. Hello All, |
Hi all,
Thanks to those who have posted on this topic already. Nick, I took a look at the article in your earlier reply. I didn't even know that it existed, but in reading it, I realized that we were following most of the recommendations in it. That may be because of the fact that IBM helped set up our environment here. I would like to add my "uninvited" opinion on this topic. In reading the article, it is apparent that it really is all in the "planning". That is, creating plans, teams, projects, etc..., in RTC is relatively easy. The hard part of it is all in the "up front" planning (and getting everyone involved to agree to the plan). Once you get though that part, the implementation is easy. I think most of the posters to this discussion would agree with that. Having said that, I would like to volunteer to help with taking this subject further. I am not an "expert" in this subject matter (others in this discussion may be along with the authors of the article), but I can provide some examples of how we work with this topic here. Thanks, - Walter Me too. Hello All, |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.