Rally Software Reviews

For us, the most valuable feature was writing all the stories. We found features such as figuring out what stories are going to get into which sprint and organizing the backlog and dependencies, to be useful to us.

In terms of improving the organization functions, it gives us a lot of visibility as to what features are getting released and when. It also helps us to track across the organization in a much better fashion. In my opinion, visibility is the biggest benefit that we have received from implementing CA Agile Central.

We would probably like to see a more robust dependency management system.

We have not experienced any issues. So far, things have been working fine for us.

We have started a little slow. There are just a couple of teams that are using CA Agile Central, so we've not really scaled it up for multiple teams across the organization. However, within our group there are 3 or 4 teams that are using CA Agile Central right now.

We've not used them so far. Thankfully, we didn’t need to use them.

We were not using any other solution prior to this. Since our organization was moving to agile, we evaluated a few products and CA Agile Central seemed to be a good option that would fit all of our needs; so that's how we decided to go with it.

Not me personally but there was somebody in my team that was involved in the initial setup. We did not encounter a lot of issues or challenges.

Of course, we had to pull some experts from CA as well just to get their ideas on how we're supposed to set it up, how things work and what are the best practices to follow and so on.

Other than that, the first couple of iterations/sprints we had to learn and tweak a little bit as part of retrospectives. Otherwise, it has been okay.

Initially, we looked at a couple of vendors, namely Pivotal Tracker.

You need to clearly know what you want or how you want to implement and use the product. Once you have clarity then you can figure out how you want to setup the solution and go from there.

For us, the user interface was the most important criteria while choosing a vendor. We found it to be more intuitive than the others. We also felt that it can probably scale up to the needs of what we have within the organization, in terms of integrating with the rest of the ecosystem.

Agile Central has really helped us document our Agile requirements. It's really strong in terms of being flexible and how it's set up, getting a team organized quickly and easily. In our particular organization, we're responsible for maintaining the tool portion of it. We are not so much involved in driving the development of the individual applications, so from a maintenance perspective, we kind of admin the CA tool. Agile Central is what you'd consider an Agile management tool. It's a way of logging and storing your requirements, defects, test cases and things like that in a collaborative and Agile fashion. Everybody can go directly into one tool, see what's going on, and track their respective status.

The biggest benefit that we've found has to do with the ease of use. We can get into the data and actually report out of it. Historically, we'd gather requirements in Word documents and things like that, so moving to a tool where you've got easy access to get to the data was a big win for us. The reporting in the tool is pretty good at the team level. It struggles a little more in a big organization. We are trying to look at things across all of the teams, trying to do reporting across the whole tool, so it's a little less good there, but overall it’s pretty nice.

In the next version I'd like to see more of a focus on reporting at that overall level. I want to find a way to do analytics on what's going on within the tool, how many people are using it, and not so much detailed reporting on individual teams. I want to see how the organization is doing as a whole as they use the tool.

As an example, one of the metrics that we'd like to be able to see has to do with this idea of teams that are meeting their commitments when it comes to deliverables. So when they come in to start a sprint, we'd like to be able to say "By the time the schedule ended, you hit this many of your stories, or features." And we'd like to do that, not necessarily for a specific team, but on the whole tool overall. We want to be able to compare between teams, and say "What is this team doing that's better, what is this team doing that's not." I think they could really do some work on the overall analytics. There are parts of the UI that could use a little bit of work, as they are older. It would have to do with changing the analytics and a little bit of the performance.

Stability has actually been really good. We use the cloud service, and while it does go down occasionally, they're on it and it comes back up right away. No major complaints there.

In terms of scalability, we're a pretty big project, with thousands of teams out there, so sometimes we feel like we're pushing the tool to its limits. We start to see slow-downs in response time, and things like that, but it continues to function, for the most part. We'll see as it continues to grow. It usually shows slow-downs in the UI, or particularly in the web service interfaces, that are trying to fetch out data for large projects with thousands and thousands of features. Things can be slow because it's a lot of data to move.

We do use technical support. We are engaged with support and we have several open tickets. The technical support has actually been pretty good. They're definitely responsive. Some of the problems that we run into are a little more difficult to solve, so the response time's not always there, but for the most part, it's good.

I would definitely tell them to make sure that they plan out what it is that they're trying to accomplish with the tool. Making sure that they get a good structure set up, and if they are trying to manage multiple teams, try to establish early on what those teams will look like in terms of size and what they will be doing.

One of the pain points that we see in having so many teams, is that every team has its own slightly different thing that they're doing in it. This is great from a tool perspective that it is supported, but from a metrics and reporting point of view, that makes things difficult because not all teams are doing the same thing.

Rally Software is typically used for dealing with all the scrum and agile principles and work orders. It keeps track of whatever workers do in the application development lifecycle before release.

The most valuable features of Rally Software are the executive dashboards, ease of use, and many other features. They have encapsulated everything that a GI can do, such as monitoring, maintaining, and then releasing. It's continuous integration and development. 

I have been using Rally Software for approximately six years.

Rally Software is stable.

The scalability of Rally Software is easy to do.

Our team typically handles all of the support for Rally Software. Only when there are some difficulties is when I come in to give assistance.

We have used Jira and Microsoft Excel previously.

I found Jira and Rally Software similar in functionality.

The initial setup of Rally Software is straightforward. In the beginning, there was more hands-on attention needed but after that, we were in operation.

We are always looking for a discount, if the solution was less expensive it would be a benefit.

My advice to others is when you use Rally Software every day, they must be more hands-on. The employees have to have a level of maturity for gaining knowledge of the software. They need to know what it can do, what it can't do, knowing the ins and outs of the software are important.

I rate Rally Software an eight out of ten.

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.

It is easier to:

• Create a new iteration
• Add new user stories
• Copy from the old user stories
• Add tasks
• Search for user stories

The agile methodology has made it easy for all disciplines of software development such as the developer, QA, software architect (SA), and the product owner. Thus, anybody can open up CA Agile Central and find out what they need. That has improved our productivity. It is easy to use this tool.

When you open up a user story, consider opening it up as a modal/dialog box on the top of the page, rather than splitting up the screen. In my opinion, if it opens up by splitting up the screen, then it becomes hard to read.

I have been using this solution for about a year.

There were no stability issues.

There were no scalability issues.

In my previous company, I used JIRA. In my current company, I am using CA Agile Central. I found CA Agile Central to be more user-friendly.

The setup was quite straightforward.

Please go ahead and try it out. It is a good product.

• It is easy to use.
• The flexible manner data is entered/viewed.
• Good technical and company support.
• Good range of out-of-the-box reports and easy-to-construct customized reports.

Parts of our business use Agile Central to deliver in an agile and features-based method. It is a much more user-friendly product compared to other products in market.

Pricing could be improved. Compared to JIRA, it is not cost effective for a large user base (1000 user plus). User licenses should be a group level within the company, rather than company level.

Jira is more cost effective once set up – no cost per user seat.

RALLY costs around $60/month/user seat

If you then multiply this cost by the number of users (let's say 2000 – 5000 users), it's a very large amount of money, not effective from a price point of view.

If we could get an Enterprise license at a reasonable price then, management's view of the product may change.

I have been using Agile Central for two years.

It has good availability.

We did not have scalability issues.

Technical support is good. A local resource is always available, is knowledgeable and visits us on site when needed.

Excel sheets were previously used, prior to moving to an agile-based delivery.

Setup was easy in conjunction with technical/local support to discuss the method of working in our company.

There is good pricing for a small number of user licenses (i.e., 50 to 200) for outcome (effective usage including reporting).

We evaluated JIRA and others.

Visibility of the backlog hierarchy and issue status are valuable features.

I like the way you can view the hierarchy of issues, i.e., within the tool in a tree view, showing the traceability between epics, features, stories and tasks. This is something that is not available in the other tools that we currently use.

It is not compliant with the FDA regulations on electronic signatures (21 CFR part 11), which is required for regulated industries.

We produce medical devices, which means we have to comply with the FDA regulations if we wish to sell in the U.S. One of these relates to being able to have electronic signatures within the tool, when we close or reject future defects.

CA Agile Central does not have this functionality and when we asked them, they said they had no plans to implement this. As a result, we cannot use this tool for defect management. In fact, the tool has such few security features that you cannot stop anyone with an account from editing, deleting, or otherwise interfering with the records storied within it. As a result, we cannot use the information stored within it as part of our quality system.

I have used this solution for six months.

I have not encountered any stability issues.

I have not encountered any scalability issues.

I have not used it personally.

We are using Atlassian JIRA. We have not switched tools but currently we use both solutions in parallel, due to the FDA regulation issues.

It is very expensive; currently it is the single biggest tool cost that we have.

Make sure it meets your needs before rolling it out. Don’t buy it just because it is recommended as the “safe” tool.

We use the dashboards to allocate and track team workload. It allows us to concentrate on deliverables rather than spending more time managing.

I have a team of about ten people. Like me, all our team leaders have difficulty managing their workload. They are spending at least half an hour a day to share their updates with team leadership and this costs us down the line. With Agile Central, everybody knows what their tasks are and the current status. This allows team members and leadership to focus on the current work deliverable rather than managing their work.

There are a couple of accelerators in the market that allow teams to manage meetings and notes, particularly stand-up call notes. Integrating these with Agile Central will be more powerful than manually explicitly adding it and generating reports. The capability to manage stand-up call minutes will inspire this to happen.

It's very stable. We have been using it for quite a long time. We have not seen any issues.

We try to make the most use of the API as much as we’re able, such as for automation updates. But we see a limited use of this regarding the dashboard. Aside from that, this a very good, powerful system.

I would rate technical support 7 out of 10. It has definitely exceeded our expectations especially regarding the integration of additional marketing tools. In these cases, we need the technical support team and they promptly answer us. They help us through the process in case there are any issues and help us determine whether an issue is an application or outside issue.

Originally we were using JIRA and a couple of other products but scalability and technical support were a big challenge. These were issues that kept us from upgrading as fast as we wanted to deliver. Agile Central is more stable and a proven product. CA technical support is much better and they help us progress with more integrations, helping with more with manual interventions.

I was not involved in the initial setup. I was in a separate team that does not configure Agile Central. We are the end users.

JIRA was one of the options, but scalability had been a big challenge. They also had limited support. There were open source projects available, but they require a lot of investment to build from scratch and make use of the basic features that are available. In the long run it would take too much effort for us to take it forward. Whereas with an existing product like Agile Central, it’s easy to just start using it.

Agile Central allows us to more effectively plan our sprints. As a sprint progresses, we learn more about what works and what doesn’t. We can then apply that learning directly into the next sprint. When we have perfected our system, we will be able to create things like burn down charts so we can colorize what happened and analyze more clearly our process with little manual analysis necessary.

One of our major criteria for a vendor is whether the product will help us be more productive. We want to know their track record. The market is marching towards CDCA. If we have parts of features already coded, how that can be transformed to this new paradigm is a key area.