Rally Software Reviews

• Portfolio management

It is designed 100% for agile, so if you run an agile/scrum organization, it will work for you. With the portfolio management feature we were able to understand our capacity for the first time and visually understand all the various initiatives in-flight. We could provide very clear dashboards to senior execs to be able to choose which projects we did and if they were on schedule.

Its greatest "feature" is also its limitation. Nothing is locked down or mandatory, with no complicated permissions, so it's very easy to get up and running quickly. They could have more controls around user types and what they require permissions to do.

There were no issues with deployment, stability or scalability because it's cloud based. It only went down a few times, which is very inconvenient when you run your entire team on it. But I guess this is the same for any system, cloud or self-hosted.

Technical support is 6/10. There weren't too many problems, so I didn't have to use them much. However, if support issues were specific to your data, they couldn't really help easily. They had to get permission to duplicate the database and then work on that, which in a large organization required quite a few approvals.

I have used JIRA in the past. This is not originally agile-based and requires more setting up to get it right for you.

The initial setup was simple as it only does agile.

An in-house team implemented it. The adoption wasn't the hard part. It was the overall agile transformation that required the effort, which was a culture/process thing.

I don't know about ROI but we couldn't work without it.

You have to adopt agile and be true to agile. This is an agile product, too. If you don't want to plan in sprint and build teams around the agile process, then it's probably not the tool for you.

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.

Defect tracking is the one feature that behaves most like I would expect and I have found a good way get it to work for me.

The features I use the most are the Test Planning, Test Set, Defect, and Defect Suite functionality. The Project Manager has stated multiple times that the reporting features of the User Stories & Sprint Planning work well for him. Though, like every other piece of the app, there are things that either do not make sense or have to be worked around to utilize the system as needed.

The Defect Tracking of CA Agile Central functions well enough with some severe limitations. I believe the intention is for you to put Defects in Defect Suites and Defect Suites in Iterations. You can put Defects in User Stories, but only one User Story at a time. So, if the defect crops back in, you either create a new defect or pull the defect from the previous sprint's User Story, thus changing history.

If you put them in Defect Suites you can add the same Defect to multiple Defect Suites in different Sprints. However, this also comes with some weirdness in removing a Defect from a Suite. You can't pull the Defect from the Suite directly, you have to go to the Defect and remove the Suite from there.

There is a Notes section for each of the Defects. Unlike JIRA there is no way to keep straight who made what comment when in the notes section. You have to manually add your name and date and time to the notes field making it so that if you have a back and forth about the root cause of the defect there is no ease way to facilitate this on the defect itself.

If one defect is causing failures in multiple Test Cases you cannot tag multiple Test Cases in the Defect. You either have to create multiple defects or note in the result that it failed because of the defect.

Test Sets & Test Plans, again, ALMOST function how you would expect. You can fairly easily lay out Test Cases in a Test Plan, unless you want to move a Test Case from one Test Folder to another, then you have to do so from within the Test Case rather than on the Test Plan page. You can move an entire nested Test Folder from one Test Folder to another. Deleting of a Test Folder orphans all the Test Cases making you have to hunt them down manually for deletion.

Test Sets are the method by which it appears you're supposed to keep execution results separate. Unfortunately, there is no way on the Test Plan to choose a Test Set to see the results. Test Plan only reports the latest results with no easy way to view historic execution results by Test Set. You also cannot view a Test Set's results independently. Further, adding Test Cases to a Test Set requires looking them up by Test Folder from the Test Plan. If the Test Folder has nested Folders, you can't search for the Parent Folder and add all Test Cases in the child folders. You can only create Test Sets in the Iteration, not in the Quality > Test Suites and then assign to an Iteration. Yes, It's called a Test Set and a Test Suite in the application.

I use this at a customer’s site. I cannot say for certain it is better than nothing, but I do not know what they were using prior.

Generally speaking, I can usually think of a product that functions better than CA Agile Central for the features that are utilized the most.

I have yet to see a section of CA Agile Central that could not benefit from improvement. As I tell people, it ALMOST behaves how you would expect. There are so many twitchy bits that require workaround for the business process to function. It’s ridiculous and feels almost like it gets in the way more than it helps.

For example, these problems come up when re-executing test cases. I have found no way to easily set up another testing cycle that reports the results independently and I’ve LOOKED. There is no way to assign a test case to multiple stories or a defect to multiple test cases. Associating a defect with a defect suite is easy. Removing it is hard; exceedingly so. Creating test cases in a test folder on the test plan page is easy. Moving those test cases around is exceedingly difficult. I could go on and on and on about how this product has let me down.

I have used CA Agile Central for one year.

Stability hasn’t been TOO bad. There are occasions that I have had to close my browser and start a session over. But what do you expect when using Adobe Flash instead of something more modern.

Opening new browser windows (middle-click) takes FOR-EV-ER, relatively speaking. While it is MUCH faster to just click a link in a given instance/tab, the general user behavior is to open new tabs and that takes WAY too long.

I have not had to utilize technical support.

I was not given the option to use a different solution, as this is the solution my client utilizes.

TestRail is my hands-down favorite test case DB to work with. It has every feature a tester needs to easily create and design test suites, add defects, and retest with multiple configurations. CA could learn a LOT from TestRail about how to manage test cases properly.

Choose a different product for your test case needs, and explore other options of managing of your agile processes, such as TFS.

To manage our work in a common way.

In terms of performance, we're just getting started on it. No issues so far.

It helps me plan the work. Also helps me plan an estimate of how soon or how far out we'll be able to deliver something. Those are big things.

• Visibility across the team
• Ability to see the team's capacity - how much free time, how many deliverables

It could use some templates and patterns that we can follow. There's a lot of support for Scrum and Agile, but something for the Kanban side, I'd really appreciate that.

I don't have a comment on this because we've just started to use it. From what I've heard from other users, it seems like a good, stable product.

We were looking for a tool to support our work, to support our process, especially in the Kanban area. Without that, we started to use Excel, we started to use SharePoint but, really, they were not giving us value, the visibility. Then we started to look for something which is specifically made for supporting this kind of process.

When our company is looking for a new vendor we float an RFP; there is a set of criteria, we get together, list down all the requirements that we have. Any tool that we look for we look for, we typically look at four different vendors, four different tools, and try and compare them.

I would recommend CA Agile, certainly, but it all depends on what processes you have and whether it's a fit for them. 

• The ease of user provisioning, i.e., bulk provisioning via API
• The configurable Portfolio Management and parent-child relationships
• The object classification (tags/colors)
• The seamless integration with many other systems such as Salesforce and GitHub
• Consistent uptime
• Rapid response support

Team collaboration is made easy and effective to meet business initiatives, while tracking progress across all the solution groups, regardless of their geographical location.

• The Reporting feature can improve, especially around executive summaries and dependency mapping.
• One report that would be especially useful is a Release Dependency report that displays the relationship of dependencies, across release trains. Currently, Agile Central will show you respective dependencies, but only if they exist within the same release train.
• CA Agile is hosted on a multi-tenant server, which prevents duplicate user names to coincide. This has become bit of an issue, in terms of provisioning users that had demo accounts in the past. In our experience, when provisioning a user who held a demo account with their company's email address, we had to reach out to the user to have them rename their old demo account. This opens the door for us to then proceed with the account creation.

I have used this solution for four years.

CA Agile Central is very reliable, in terms of consistent uptime. We have, however, encountered site latency during peak times of activity (far and few).

There were no scalability issues experienced by us, to date. We had a user base of 500 in 2015, and will have 3,000 by the end of 2017. We have not encountered any noticeable limitations.

The support staff at CA is excellent! They are very responsive and work to resolve any requests or issues, within a time span of a day on the average.

Previously, we were using VersionOne. CA Agile offers a more structured model of Portfolio Management.

VersionOne tends to offer a more open and free configuration setup, in terms of creating portfolio items. For example, in VersionOne, you can create child features, and then produce another set of child features for each parent feature. It is nearly impossible to restrict a portfolio model that allows for consistent reporting.

In Agile Central, you can configure and define your portfolio structure in the administrative console. Each child must roll-up to its assigned parent, i.e., Task > User story > Feature > Epic > Initiative (bottom-up).

The initial setup of Agile Central was straightforward and very repeatable. If you get it right once, the process to scale your subscription is consistent and efficient.

The license costs are fairly high as compared to some of the other solutions out there. CA Agile Central licenses are “one shoe fits all”, i.e., in terms that a Viewer license is the same price as an Editor or Project Administrator license.

A tiered pricing model would be a better approach. For example, the cost of the Viewer's license would be less ($) as compared to the cost of the Editor's license ($$).

CA Agile Central has worked very well in our ever-growing, agile-centric organization. If you’re looking to implement an agile development solution that scales extremely well and is backed by solid performance, stability, and an outstanding support team, this is the solution for you!

We recently went through a rigorous analysis across ALM tools in an effort to justify the continued use of the Agile Central, in comparison to the alternative solutions. CA Agile Central was chosen hands down, as our one and only ALM development tool across our enterprise!

The most valuable feature is that it follows the agile methodology more than ALM or JIRA. However, I know companies using more than one tool, separating test management and requirements, which I agree to.

Currently, I would prefer to use QAComplete by SmartBear to track test cases, since CA Agile Central doesn’t work well with reporting on that level or for that matter on any level.

One of the jobs that I adopted was to design procedures using CA Agile Central. In the beginning, without a procedure (not sure if the online help has much “method” suggestions, which it should), it does allow the agile process to be followed easily from features > user stories > team capacity > sprint sizing > test management and defect management. If properly used, it can be an amazing tool relaying to scrum masters, project managers and for all management levels to show exactly how a sprint is going. I will say the CA Agile Central Excel plugin is great for real-time extraction of data, i.e., if you know how to use it correctly, and out-of-the-box you will not know the hidden tricks that I have learned. But, CA Agile Central Support is actually very good.

On the test case level, I feel there are a couple fields missing, i.e., I cannot easily create a day-over-day report. I cannot find out what is planned for the QA team, as I cannot track what is “ready”, or as to the day when it’s planned to execute.

I have been using this solution for one and a half years now.

No outages have yet been experienced.

There are always latency issues when accessing anything in CA Agile Central Portfolio Manager; it takes a good 10 seconds to load. This isn’t only due to concurrent users, it can be the case at 1 AM when no one is on. It hasn’t been that much of a nuisance.

I would rate the technical support a 10/10. The funny thing is that I didn’t care much for the CA Online Support. I didn’t know there was a ticket support system. However, once I did, my goodness they were great in returning answers.

We did previously use HPE ALM. HPE ALM didn’t produce much of good reporting, yet neither does CA Agile Central. Plus, the agile process was all wrapped up in CA Agile Central, so we decided in our department not to maintain two tools. Other departments and UHG do use both tools, and some HPE ALM still.

The setup was very simple; it was probably easier than HPE ALM.

One major problem when obtaining CA Agile Central is ensuring the framework is exactly what you want. Many don’t look at this aspect and later realize that they have lost traceability and that they should have created a dropdown menu instead of free text (i.e., there is a defect found in the free text field – this should be a code drop version, adaptable by iteration). Yet, I’m still not sure at the moment what is and what isn’t adjustable since I’m not an admin. However, from what I did hear is, when something changes, it may change the enterprise and not just the project; not sure about that yet though.

Count the cost! Find out what you have in place and how much longer you are charged for and then compare this to your budget. I find it a big waste in having too many tools, but it really matters as to what you want to see and how much you want to maintain. For example: With the SOP that I created for using CA Agile Central, I can create almost perfect reports from Excel. However, the problem here lies in Excel! You need manual intervention to formulate and macro out the data, thus involving more costs.

Only afterwards did I evaluate other options, since I was not a decision-maker; they already owned HPE ALM and CA Agile. SmartBear QAComplete is a great tool and probably my number 1 choice, i.e., if I had the choice. It also works with SoapUI, XML, Selenium and manual scripts.

I would consider it highly. Be sure what you want to accomplish; it’s not reporting-friendly. It is good with team burndown and sizing.

Although, it’s agile-based, it’s not like HPE ALM that informs you via emails when something changes, i.e., even if you enable notifications, it’s fluky, as you get more emails than needed. CA Agile Central has a dashboard per user feature, as to when logged in that must be viewed.

The key thing is process! You must know how it works and how you want to use it, before you implement it. To be honest, there is only one way to use it that I have identified above.

With Agile Central, we are able to map out our work and time chunks for our sprints. It forces us to plan our work and enables us to get software builds to our customers more efficiently and quickly.

It has helped us to become Agile. It has helped us to really get our products in front of the customer faster. It's changing the culture of how we build software.

When you look at the old waterfall methods, we weren't adapting to change fast enough. We weren't able to rapidly deploy what we were building. By the time we would build something, there would be changes that came down the line. We didn't react to it fast enough. This allows us to react faster, and to build better products. We're learning more and more every day, and using their coaching.

An Agile Central mobile app is long overdue. At the end of this conference, I want to look at my burn down charts. I want to look at how my teams are doing, and trying to look at the full website on a phone. It's a terrible user experience. We need a mobile application for Agile Central.

It’s a great tool other than that. It's been fantastic. Developers love it. My managers love it. It's been great.

Stability has been very good. Every now and then, there is something. Ironically, it was down a little bit on Monday at the start of this conference, but we typically never have an issue with Agile Central being down.

It's very scalable.

Initial setup was straightforward. It was easy.

We're a long-time CA customer. We actually bought Rally before CA purchased them, so we were already a Rally customer when CA bought them. We were also already a CA customer for other products, so it really worked out well for us. We weren't upset at all over that acquisition.

We compared Rally vs JIRA, but we felt that Rally was the better 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.