Hi John,

since nobody else dares to respond, I'll try.

RTC is already widely used in a really big software development company - IBM. It is used here in more than 180 projects of different sizes.
Project boarding time is down to less than a day.

There are reasons why RTC is gaining momentum so successfully in IBM i have heared: the agile planning, the reporting/dashboarding, the collaboration and the process support.

However, there is no "one size fits all" answer to your question.

I strongly recommend you get in contact with an IBM sales rep and set up a meeting to discuss what your situation is in more detail. Then you can plan on how to go ahead and what you want/need to achive and maybe run a pilot project.

Thanks,

Ralph

I'm looking into using RTC for a very large company. This company has all the challenges RTC was meant to address, namely:

Lots of developers (thousands)
Lots of different tools (SVN/ClearCase for SCM, CruiseControl/Plain old Ant/nothing for build, and on and on)
Geographically distributed teams
Home-grown systems for things like signoff, etc.

We want to use RTC/Jazz as the overall ALM brain, and give teams the option to use built-in RTC tools for things like SCM/build/whatever unless they have a reason to stick with one-off tools like above.

Has anyone had experience using RTC in this environment? We're not against using the tool for all (or substantially all) of our dev teams if the gain is high enough.

I realize that the best of tools will come to naught if we don't implement it properly. I'm looking for systemic reasons why we would/wouldn't go this way.

Hi John

I am working with a company going through this process - they have deployed RTC, starting with projects who really wanted to change initially and use is growing rapidly.

As Ralph suggests, this needs to be planned out carefully (nothing to do with RTC as such, more like how to implement anything in a big company).

RTC can replace most existing tools you mention used for development (within the constraints of platform/os/language/etc) - and the ability to tie together different aspects like agile planning, source control, work item management, build, etc is critical and one of the real benefits of RTC

Some suggestions - educate the tools support people first (and if you don't have a tools support team - you need one!). They run the infrastructure, provide a central point of guidance and advice, and keep the deployment moving. Pick some small(ish) projects to start with - people who are keen to try something new and a little different. Give them lots of help to start with. Get a community going internally - so people can help each other. Get everyone to create logins on jazz.net and show them how to use it effectively.

Word does get around quickly, and soon the main challenge is having enough people to physically support the demand for teams wanting to migrate or start using the tool.

A final warning, people do tend to get a little overexcited about RTC and Jazz, and see possibilities or options to use RTC in ways it was never intended to work. Be very clear what RTC does and does not do - and make sure projects adopt the tool for the right reason.

Does that help a little? Keep asking questions here on the forum - there is experience here from different deployments.

anthony