Rally Software Reviews

It helps us find our users stories and allows us to see what everyone on our team is working on, and if we have any blocks.

It's performed pretty well.

It allows our team, and all the external teams that are waiting on us for dependencies, to see where progress is on the stuff that we're about to develop and deploy.

It integrates well with the things that we have. We're able to tie our stories in with our code repository, so that way our check-ins are tied back to our user stories.

I can't really think of any additional features that it needs. It pretty much has everything that we use it for.

It's been really stable. There have been some downtimes with it, but they're fairly short.

I'm not sure how well it scales. It's worked so far with our team.

I know a lot of our teams are using JIRA. The switch is because it has more features.

When looking to select a new vendor, our criteria are

• price 
• feature set.

I give it a nine out of 10, just because of the slight downtimes, which make it hard to go in and update things.

Definitely look into it, because of all of the different tools for user stories and test case management. It's been one of the best I've experienced.

We are promoting SAFe within our organization and we have a organization that actually follows the Scaled Agile Framework. We're using Agile Central right now to track our users' portfolio items, our product features, our product backlog, our iteration status, and to track metrics. That's what we're using it for right now.

It's been pretty good. We've been using it for the last two and half years. We've tried a couple other products in the past, before we moved on to Rally CA or Agile Central 2. So it has really worked out very well.

The metrics - collecting metrics. It's because we've used several other tools in the past, and they don't give you a full indication of how well your teams are performing, at a portfolio level, at a product level, and at the team level. CA Central actually makes it very easy for us to track metrics for our trains, for our teams, to find out what the velocities are, what we should plan for, and what we should anticipate.

It really helps us scale in terms of our organizations, and be more predictable. That's one of the biggest advantages that the Agile Central tool has provided us. As I said, gathering metrics and being more predictable, that really helps us in the long run.

We have a couple of pain points, but I can't remember off the top of my head what those are. Every once in a while we'll submit feedback through their online tool. 

In terms of improvement, perhaps some more metrics. If they could add some additional, that would be cool.

It's quite stable, we haven't had many issues. Every once in a while, we have had some problems with the total number of features that it runs into but other than that, nothing else.

I haven't had much of a problem with scalability. It seems quite scalable.

There are times when we struggle with stuff but we haven't really called customer support yet.

There are some features of the product, a couple of the things, that were not really intuitive. We just had to go through online documentation. They have good online tutorials, support, documentation, where you can go and read up on things, so we just used that.

We started using the product, so we were more of the consumer than the actual installing team. That was done by a different team.

We explored a lot of tools when were trying to promote SAFe or Agile across the entire organization, so we moved through the Scaled Agile Framework. And then there were only three or four tools that we explored, and Rally, or CA Agile Central, was one of those that we thought would really work.

We looked at VersionOne, the Atlassian tool, I can't remember the name of it, I think it's just JIRA, and Rally.

What's most important to us when selecting a vendor are 

• ease of use
• how intuitive it is
• customer support
• metrics, for us, that is really important.

I give it a solid eight out of 10 because of the way that things are laid out. It's more user friendly, it's intuitive. As I said, it's easy to use. I think they've done a good job with the metrics in general.

I would tell colleagues who are looking at this type of solution to do their homework and see which one works best for their company, for their teams, and for their organization. We went with Agile Central because of a lot of the things it provides, in terms of the features. I know every company is different, every team is different, and things that might serve their needs may be different than what is useful for us. My best advice would be to do their homework and explore.

Primary use case is agile development and Mode 2 development.

It has performed really well. We have taken some teams that were non-Agile and tried to do a combined approach. This eliminated some of the heavy documentation that we were used to with waterfall. We have been able to deliver our integration between CA and HPE ALM in a period of time that is about half of where we were before. 

It documents stories in a way where we do not have to be heavy on front-end requirements, front-end documentation, and front-end workflows. We are able to create those stories in a more of a just-in time approach. Since we are doing combine and not scrum, we want to get those stories on as we think of them and immediately work on them instead of waiting for a time box. So, it was the ability to adapt quickly. 

We are very new on agile and Mode 2 devolvement. It has really allowed us to experiment with approaches that we would have been a bit afraid to experience before. So, it has allowed us to try new things and to take risks. 

When you copy a story, I would like the attachment to copy with it. This is a big one for us. We do requirements in one sprint, then do development in the next, which still is a little bit of waterfall. So when we copy those requirement stories and they become development stories, the attachment does not come with it. So, it is a lot of manual effort to do that. It would save us a lot of time. 

We did submit an enhancement request. I think a lot of teams that do very large scale products have the same issue. They just do not realize it would help them. 

Also, there are a few things in the way things trickle up from category to theme to feature that I do not really like. I wish there would be some enhancements there.

It is very stable. It was purchased by CA from Rally, which I was familiar with beforehand. It has gotten better since CA has taken over, adding some new features, but it is a very stable platform. 

Since we are more of a Waterfall shop, as we bring new teams into the agile approach, I think it is quite scalable for us. However, it will probably be a more longer term poll. 

We have used them quite a bit. They have been very responsive. We use a competitor's tool for our waterfall approach. I won't say which competitor it is. However, we have been very happy with the speed and the availability of CA's technical resources.

Our issues have been lower scale problems, but we do not have a support staff to manage Agile Central. What we found was technical support was not only giving us the ability to get help, but also helped us evolve our support team into a team that can be managed well on its own. So, I have felt they have helped us in a lot of ways.

We did not have a solution in place. We were looking at Mode 2 and agile teams and we knew we needed something. Putting post-its on the board was not going to work anymore for a company of our size. While we still do some post-it exercises, it all ends up in Agile Central and we knew we needed something to manage this. We still have PM's who want to see portfolio management, so we knew it had to be digital. It could not be paper anymore.

We took our instance and revamped it from the beginning, which was very straightforward.

We were. We were looking at a few. Not sure if I can say which.

They were not providing a solution that was mature and developed. They were providing solutions that they wanted us to be like a test customer on.

They still feel like a small tech company. The support we have gotten and the way they have managed or accepted some of our enhancement requests. They still treat it like a small company, like Rally was before they purchased Agile Central. They still have that feel, knowing how big they are and seeing how they can act small. It is really nice.

Make sure your agile processes are really well-defined before you go out into the market and look for a tool. Tools do things differently, they call things a feature in one and a subfeature in another. Make sure your processes are defined, and once you have that, look for your tool after that. Do not look for your tool first.

Most important criteria when selecting a vendor: We have price, which I would not say is our most important. We are looking for more of a fit and finish to our process, though price is really important to us. One of the things that we look at is: We want to create a really good process, then find a tool that fits that process. I think a lot of customers do it the other way. So, if our process is mature and we like it, the tool really needs to fit that.

Software development and infrastructure.

Sprint planning and overall work management of the stories and the project lifecycle.

Sprint planning is valuable because it keeps our teams all in the same place in terms of where information is stored. We always know what the status of a project is and anybody can see it.

• Ease of use
• Visibility

As a PMO Manager, I need to be able to look and see what the project status at any time without having to go ask somebody or look for a status report. So, I could go there and see exactly what percentage is complete, what the blockers might be, and just see who is assigned to what, so I can look at resourcing.

It has made our company more organized and it is helping us be more true to the agile principle. When I came to the company, we did not have any agile practices in place. So, it has helped us, because it gives us a framework to put the agile practices in place. 

The integrations with the PPM tool and making sure those two work well together. 

Improved engagement with TFS, because we still used TFS for code management. There is an API between the two. I think that the APR could be easier to set up and the API could be a little more fluid in terms of when the code is checked in. It really relates to how a project is updated based on that.

Stability is better. A couple years ago before CA bought it, we had a lot of problems. Now, we do not have as many problems. So, it has been good.

Scalability is getting better. It used to not be as good, but they are adding some features that make it easier to build portfolio items in.

The problem before was that there were just a lot of little bugs where you create a project in one place and it would not continue to exist in another. Also, there were not very good templates or anything. So, they are improving on that. 

I have not really used the technical support.

We did not have a solution when I started. I picked it because I was familiar with it from a previous company. I actually used it for a couple years before that, as well. I just knew we needed something that we could hit the ground running with pretty quickly.

I was involved in the initial setup and subsequent upgrades. 

I am not really sure how it is now to set up. If you are putting into a GreenField brand new product, I do not know how that would work now. Previously, it was just figuring it out on your own.

Upgrading was pretty straightforward, especially if you are used to using any of the agile tools in the agile practices. Once you get used to some of the unique namings for Agile Central, or formerly Rally, it is pretty straightforward. It is a like-for-like, in terms of what you have learned, in terms of being agile in what you learned on what you are doing on a day-to-day basis. 

The vendors on the shortlist would be TFS's Project Management through Microsoft, ServiceNow's Project Management, and JIRA.

Earlier on, we went a little faster and we did not do a full software evaluation. We actually are doing a tools assessment now. We are going to be looking at replacing CA, possibly, because we want to make sure we have the right tools. We want to make sure that they flow between all the different tool sets that we have. 

It has performed well so far. It has improved over the past couple of years.

For any product, do a full software evaluation and make sure you actually test them side-by-side with like-for-like test cases. Then you know exactly what you are getting yourself into. Otherwise, you build out and realize it might not be the right product for you. So, a full software analysis is important.

Most important criteria when selecting a vendor: Initial support is always important. It is always great when you can have a few free hours to have somebody to come in and help you understand the idiosyncrasies of any software, figuring out exactly what the best way is for it to be set up. Otherwise, you are just trying by trial by error. So, that is important. Also, stability is important.

It's designed around Agile, so it has all of the pieces that match up with the process. For us, at the portfolio management level, we can see everything at one glance, all of the projects, where they're at; and, at the iteration level, we’re able to populate the iteration, and view progress reports on it. We've recently moved all of our defect tracking onto it also - it's nice to be able to pull defects right into sprint plans.

• We're using it to manage the training content development we're doing, so it's kind of a one-off case. It's not your typical agile project, but so far it's working well, and we're able to incorporate most of the agile methodology into our processes. We get all of the transparency that comes with the tool; so we have a clear view of what's happening with all of our projects, what state they're in, and where all the pieces are. Blockers stand out, so they're getting more attention. It's become our single location for project information. Although there's been a bit of a learning curve for the team (more around the processes we're using than with complexity in the product), I've had several team members tell me that it's a good product that they enjoy working with.

I'd like to be able to color code timeboxes, so I have an easy visual way to track the success of sprints. Workflow is not a strength, we've cobbled together our own workflows around changes in State and Ownership.

About a year now. What we're doing in CA Agile Central is pretty stable now, although we still tweak our own internal processes from time to time. Still exploring and learning the wonderful world of Agile.

We weren't involved in it.

It's been extremely stable for as long as we've been using it.

I see no problems with scalability. In addition to what we're doing, I know our Services team and Product Development team are using the product, so I expect scaling is not an issue.

Haven't really used it.

Haven't really used it. Which I like.

Spreadsheets and MS Project. CA Agile Central is designed around Agile methodology, so it was a perfect fit for the processes we wanted to put in place. We couldn't do the things we're doing now with the previous products.

I wasn't involved in setting up the product itself. I jumped in after it was already in use.

Wasn't involved.

The decision to use it came from our development team. The whole development team is using it. Our Services team has been using it for years.

If you're focusing on agile, this is the right product to use. It's built around it. I've tried to do things with MS Project and that sort of thing, and you just can't manage it the same way. It's just not built for the same kind of cycle.

It is a well thought-out solution. It's a great centerpiece for Agile methodology. It works.

I like it because I have several projects, and it keeps me on track for each one. So, I can track each iteration of each project, and see where I'm at and where other people are at, visually. I guess maybe the iteration planning and tracking status is the most valuable feature.

It has helped a great deal in the fact that we are able to take small chunks of data and get them actually moved forward end to end. Previously, we had to wait several months before something would actually be available for the end user. This has helped us to break that and to move forward quickly.

I think I'd like to be able to color-code the words more easily, not just the side. You can change the color on the side, but to actually change the font color would be useful.

Currently, I use an HTML color font to change the title of a user's story or something. If, instead of having to put in the HTML version of it, to make it change the color of the font, and I could easily change the color of the fonts, it would be a lot better.

I have been using the solution for two years.

I think occasionally it will slow down, particularly when we have a lot of users on the same project, especially around stand-up time or whatever, because we're spread out across the country, so we usually do it by phone. So when everybody is on the project at the exact same time, it will slow down a little bit.

Also, if I make a change and somebody else makes a change, you can't retain both changes. It doesn't accept both. The first one who finishes, who hits Enter, Save, Done or whatever, will get the change.

Then, it will warn you. It will say, "Do you want to keep your changes or the other person's changes?" But you don't know what they are changing, and they don't know what you're changing!

It slows down a little bit if you have a lot of information in there. It seems to work really well, however.

I like the personalization of the home screen because I may not want to look at everything, i.e., the same things that other people want to look at. So it's nice to be able to personalize my home screen. I have a lot of stuff on my home screen, and it seems to be able to handle it just fine.

We have an administrator, and I've had to have people added back in because they don't go in there and use it, and get suspended. Then they ask, "How come my name's not in here?" So you have to respond: "Because you never use it."

I haven't really had any help from technical support.

We previously used a different solution. We switched to be able to move more quickly to a resolution. Because the industry changes quickly, we can't still be in development stages on a product that needs to be out in the consumer's hands today. That's why we moved on to something like this where we can actually get things out there quicker.

The setup is very straightforward.

I have no input as far as the cost is concerned. That goes further up the chain than me.

I would definitely say it's a very good solution to have for a company, yes.

The tools are not overly complex for Agile. It appears that CA has recognized that. They're not just building the connector for Rally, but they are also allowing other groups to build connectors from JIRA into CA PPM and from other tools to CA PPM.

If you are looking at open source products, why isn't somebody building an open source product so that it could actually do this interface? I build open source interfaces that allow me to get to use different products.

In terms of the APIs, you have consulting companies that are building other products that you buy and you pay for maintenance

In the open source community, they are attempting to tie the old to the new, or they are just looking at the new. In the open source community, there's a lot of need for tying the old to the new. (The old refers to CA PPM.)That's the old way to do project management, which involves governing and controlling.

The new way is Agile. While you still have to do some governance and control, Agile allows you to get away with a lot of things that CA PPM doesn't allow you to get away with.

There is a need to connect these two elements. What I'm seeing in the open source community is more of a focus on the new products.

There is a lot old stuff out here that has to be connected to the new. You can't just ignore it.

The Agile release management is ready to go. When I take this function and try to run it as a discreet element, the other function of the system is rendered as a separate sprint.

All the other vendors wrap around this core. They interface with SharePoint and Clarity. They will also interface JIRA to Clarity. It is a methodology. It is basically taking the Agile methodology, doing some things, and not redefining the whole process. It is, rather, adding some additional components to it, so you can understand what you can do with it, and what cannot be done with it.

PPM: Has administrative overhead associated with the waterfall approach and a lot of DTL tracking.

JIRA: The scrum masters have a lot of flexibility in the sprints in terms of how they actually track work. In financial organizations, or in organizations that are regulated, you need to be able to have that governance component that PPM provides. You also need to provide the flexibility, which is what JIRA or Rally provides. JIRA has been around for a long time. It is open source, so a lot of people have moved to JIRA. It is a suite of products and not just one piece. It is not just about Agile development. It can also do incident management, work configuration, and a lot of other different things.

We have adopted JIRA, as well as Rational. Connecting both PPMs is important, because you still need the governance.

However, we haven't found anything as compelling as Rally. If we didn't have JIRA, and we didn't have other tools, Rally would probably be a strong consideration. However, we already have teams that are familiar with the other tools.

You have intake and change management, which is part of PPM, but you can also tie into it. You have release management and testing.

It would really be interesting to see an open source community that actually focused on how we build the connectors from the old to the new, and then make that transition possible.  Once you build those connectors, you transition the old into open source, so the old goes away.

I was just looking at a small company and their release management. It felt like it was very close to this, but it's the opposite end of the spectrum. They tie in to CA PPM and they do the development and the project management. 

They are doing Agile this way, but they have these other components that they have to put in front of it and behind it, to make it tie into release and change management.

Agile comes at this development piece of work. It's now production ready and I put it on the shelf. Most systems don't allow that. I put it on the shelf. Somebody else develops another piece of work. My piece of work has to come back off the shelf. 

They interact with one another, so I can't just say this one is ready for production, and then that one is ready for production. I have to go into a system test mode, and not just the function test mode. Agile generally doesn't look at it that way. Agile is really built to run on building services.

It is a very complete solution. It provides a full solution for us, which is extremely essential.

The principal is because they listen and that helps a lot and the business, this is very important to us.

So far it seems to be doing everything we need it to. We don’t require any improvements at this stage.

So far it seems reliable and we are happy with this product

We are not sure so far on this as we haven’t used it long enough but we hope it will be scalable

They are smart people, knowledgeable and helpful.

It was time to get a product like this in house, previously we were using a local software and it was time to upgrade. For us it is all about the support of the company, and we really like this from CA, they have been very helpful.

It has been a straightforward partnership so far. We are in the initial stages, but all looks good.

I think that you should do some research but ultimately go for someone that addresses what you need and who is able to provide great support.