Rally Software Reviews

As a requirements engineer, most valuable is user story writing/editing/reviewing with peers.

It is supposed to shorten the project’s lifecycle. I do not have proof of this.

The text editor is for sure an area with room for improvement. Under IE 11, the Backspace key is not functioning as expected; it deletes and also inserts empty rows. If you continue, you end up with a lot of empty rows that you do not want. The DEL key, as well. Formatting is difficult.

A CR (carriage return) always creates a new paragraph. But sometimes you just want to stress something in relation to previous statement, but you do not want it in a new paragraph.

Pasting text from Word can create a lot of formatting issues, mostly in cases when the font is not recognized. Also, features such as graphics and tables are supported but only if coming from Word. So, if you want to eliminate a column or a row, you need to go back into Word, make the update, and then past back in the editor. In fact, if you want to come back to a text and edit it, it is very difficult to maintain the initial format.

These issues slowed down my work.

My comments are meant to help improve the product, not criticize it.

I have used Agile Central for five years.

We have not had stability issues.

We have not had scalability issues.

Technical support is very good.

This is our first solution for agile projects.

Setup was somehow difficult until all folders had been created and the rules on how to use them were set up. This has nothing to do with the product itself.

I had no involvement in this, so no advice.

It was a company decision. I just adopted the company decision.

Be very clear in agile and then “map” your knowledge into the product setup.

Defect management is most valuable, since I am on the QA side. It's a very good tracker.

We have centralized all our agile process on it, so it's been our agile central during the project.

Based on my experience and the level of use, I think this tool fits everything we need.

I’ve been using Agile Central for 1.5 years.

Sometimes the app freezes when creating either user stories or defects in Safari. The performance, in terms of response time when creating elements, is not as expected.

I have not seen any scalability problems.

I have never requested for support before.

I had the chance to work with Atlassian JIRA in a prior project. When I arrived at my current project, it was the first time I worked with Agile Central and I am still using it.

The rampup was very straightforward.

Pricing and licensing it is not my responsibility. I am an end user only.

Choosing the tool was not my responsibility. However, I was using another tool and the rampup with this one was very straightforward.

I would recommend using it without any doubt. I think it fits perfectly with the agile processes.

The most valuable feature of the solution is that we are able to identify individual teams, and those teams can then break down their work, and watch it flow through their process. The benefit is that it provides transparency into the work that teams are doing.

It has brought a lot of light to the differences in the way our teams process the work through. They may be doing the same set of work, but Team A is doing it completely differently from team B. We've identified some of those differences; and we're now starting to align the process.

Our biggest struggle right now is that we're a SaaS customer, and that we don't have access to the database behind the scenes. So we're being asked by our Scrum masters and teams to provide data and reporting that we're not able to get to using the tool.

The stability has been very good. Although, this year and last year, we did notice problems on Monday, just as CA World started. I think it's very coincidental. It was just kind of odd.

I think the scalability is there for our organization. We are not in a position to take advantage of any of that yet.

There have been a couple of cases where we've asked questions, and the answer has been, "Here, go read this site." That's been a little frustrating; but, for the most part, all of the cases have been resolved, timely, and with good results.

We were previously using a different solution, and it was not suiting our needs. We had teams circumventing the process and using spreadsheets, or wall-based paper models, which is good; but we wanted a way to report and review all the work that was being done. So we went with CA Agile Central when we converted. It's been much better and there has been a lot more adaption of this tool than the previous one.

It was very straightforward. We didn't have any trouble rolling it out into our organization. The issues we had were internal in adaption.

We did a side-by-side demo and evaluation with two vendors. At that time, it was CA Agile Central and Version One. We chose CA Agile Central over VersionOne because of the reporting features and ease of use.

The only solutions I've experienced are CA Agile Central and VersionOne, and obviously, we chose CA Agile Central. There was also Serena Agile Planner, which was not ideal. Of those three options, I would way that CA Agile Central is excellent. Among those three, we were very happy with it. We are able to incorporate it into our environment. That is the most important thing for us. We're pretty rigid in the way we do things.

My advice is that they need to understand their environment and what they need. Then look for that in the tools that are provided. CA Agile Central was very flexible. You can configure it without customizing it. That was one of the things we really liked.

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.

The most valuable feature is the ability to track projects; not so much the reporting, but what you enter and the use of the product, and that's for tracking purposes. That's why it's important to me.

It allows us to better scrum and Kanban. It allows us the opportunity to not need a board and physically co-locate it. We can do it online.

Building custom reports is difficult and cumbersome. Trying to find the correct field name to test is only part of the problem. The field name and qualification changes depending on what level I am trying to report.

When reporting at the task level, the story needs the story qualification whereas when reporting at the story level, the qualification is not needed. When reporting at the task level, I cannot qualify based on Feature Group. This limits my ability to programmatically limit my results. The syntax of the reporting is also cumbersome. The help is only limited help and is not written for non-programmers.

Solution: Provide a query help that actually lists all of the fields at each level. Even when selecting “To see a list of all fields available for each type of work item, check your Web Services API documentation

It is easy to put information into Rally but it is all overhead without an easier way to get the data back out. I have team members who continue to double entry the Rally data into a spreadsheet just so they can more easily produce the reports that are helpful to them.

I have used it for about three years.

Over the last couple of years, it's had moments of slowness, but it seems like they've resolved that, and every so often it goes down, but that just seems like it's a few minutes, so that's more like a support type of thing. So, it's not a big stability problem.

It is very hierarchical in structure, rather than relational. Maybe if it was built on a more relational database concept, it might be a little bit easier to manage.

I don't see any scalability problems.

I've talked with tech support but mostly about reporting and trying to get the information back out of it that we need. I use internal support teams, so it's Comcast employees that are supporting me.

It was a corporate direction to switch. The tool that we were using before was very poor at accomplishing what it needed to accomplish, so anything would have been better.

I wasn't involved in the setup; I was a consumer.

I was never part of the pricing and licensing. Training definitely; everybody that's using it should go through some training, but a lot of the training was very generic in terms of using CA Agile Central and it wasn't specific to the team's application.

The tool actually includes a lot of things that most teams don't do. That information was included in the training, but was never applied, and yet some of the things that we needed to do weren't covered in detail in the training like they should have been, so it was a lot of groundwork to come up to speed on that.

My advice would be to make sure that you're implementing it in conjunction with agile methodology. If you implement this tool with waterfall, you will see that it's very oriented towards agile, and it's set up and structured to support agile and not set up and structured to support waterfall methodology.

I think that it isn't that flexible for helping with teams to migrate to agile; it's not very flexible with customizing for my team. There are a lot of pieces of data that my team needs, and we're having to use non-ideal fields for those. I know that that's the way that it's installed in our application, but a lot of the customization that's available in CA Agile Central isn't available to me to do. So, I would say that it would need to trickle down to the group admins, the ability to be a little bit customized, to be able to customize it to the team.

Portfolio management is a valuable feature.

It is 100% designed 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 our senior executives in order to be able to choose which projects we did and to check 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 it up and running quickly. They could have more controls around user types and as to what permissions they have.

I have used this solution for 18 months.

We did not encounter any stability/scalability/deployment issues; 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 assume this is the same for any system whether cloud-based or self-hosted.

I would give the technical support a 6/10 rating. There weren't too many problems, so I didn't have to use them much.

However, if the issue was specific to your data, then they couldn't really help easily. They had to get permission to duplicate your 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 setup was simple as it only does agile.

We implemented this product in-house. The adoption wasn't the hard part. It was the overall agile transformation that required the effort which was a culture/process thing.

I am not certain but we couldn't work without it.

You have to adopt agile and be true to it. This is an agile solution 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.

The Kanban board is probably the most useful feature. It is very customizable and is great for somebody who doesn’t need to run the project with a scrum approach. The second most important feature is the overall ability to customize almost all of the solution’s features and work products such as user stories, defects, and features.

The product helped engage the business product owners by increasing both their view into the development cycle and their responsibility to assist in setting up work priorities.

The weakest part of this solution is its primitive report generator.

The report generator is very simplistic with a limited capability to filter, sort and group, and the designer is not WYSIWYG. The product would benefit from a more capable browser and a more compatible report builder.

It needs a UI that has a Crystal Reports-like design and WYSIWYG capability. Right now, it is an early 80s throwback.

We have not had many stability issues. It is a stable product, but in the past, CA has fixed some server-side issues or implemented an “improvement” without any patch notes. That is usually just frustrating but one time, an “enhancement” broke our link to TFS. It took us two days to re-enter all the users.

We have no scalability issues. We have 185 users. However, because we are a cloud product, we are at the mercy of the internet routers and traffic.

Technical support is good once you get their attention. What is critical to you might not be critical to them. As an example, we had a broken TFS connector. It took about six hours for them to understand the problem, and that they were the ones who broke it. Once that happened, they were very helpful.

We used Microsoft Project. At that time, it was very weak with agile projects. Prior to purchasing this solution, we created a vendor grading scorecard with the features that were important to my company. We started evaluating six products. We then eliminated three, re-compared them, and settled on this solution.

Since we bought the cloud option, there was no specific setup. There was, however, lots of customization that we have done since 2012. It is straightforward once you are familiar with the product.

We also purchased five days of CA Agile Central on-site training. It broke down like this: one day for developers, two days for project managers/scrum managers, a half day for product owners, and a half day for administrators.

CA seems willing to give deep discounts when you have 100+ licenses.

We evaluated five other options. They have changed so much since we evaluated them in 2012, so it wouldn’t be fair to name them.

Make sure you have adopted an agile methodology on a few small projects first and then work with IT and business colleagues to accept that methodology. We did that before we looked for a tool. That makes the purchase, acceptance, and customization of this tool much easier.

A lot of the reporting is very valuable to us. We really need to control certain releases and milestones, and so on. Being able to report and get statistics on all of that stuff is one of the features we really like, especially now that they're expanding that as well. We like that.

Honestly, it keeps us more organized. We have a lot of products and we ship them pretty fast. CA Agile Central is great for us because we can categorize all these different things. It really gives our top-level leadership visibility into what we're doing so that they don't pound down our door every two seconds. They can actually go into CA Agile Central and figure things out for themselves. They can make better decisions without really needing us.

I use it a lot. I don’t really have any complaints. There are a lot of alternatives out there. They are also useful, but I have no complaints with CA Agile Central or with CA in general. I don't find myself saying, “I wish it did this,” or ”It's really killing me here”. It has been a good experience.

As a release manager, what they’re coming out with now in terms of release automation is going to be very valuable to me. I think that with CI (continuous integration), as much as it is expanding and taking over most software shops anyway, I think that's the way to go. I think they're doing it right. As a release manager, I'm happy. CA is coming out with a lot of CI-type things, which is good.

It is stable. There are no issues there.

It is scalable. There are no issues there.

The customer support at CA is good; however, we haven’t had to use it, which is good. It's always there if we need it. That's also good.

I don’t believe we’ve needed technical support. It has been pretty stable. It fits our needs for what we need so far.

My company has been using CA Agile Central for as long as I’ve been there.

I've been at other companies where they're using different tools, like JIRA and stuff like that; but CA Agile Central is fine. At one of those companies, we weren’t using JIRA all the time. It was really too convoluted for what we needed.; so we didn’t use them. Sometimes you needed to dig for certain things that were not necessarily laid out flat like CA Agile Central is. Even though, in JIRA, you can kind of organize them in different ways; but only if you use them. Like I said, CA Agile Central fits our needs pretty well.

Our top reason for selecting an agile platform was needing to ship as fast as possible. Waterfall is good for new products coming out, but we have a lot of long-standing applications that have been out on the market for awhile. Getting releases together and shipping them as fast as possible is what we needed. It was kind of a no-brainer for us.

I would say our agile maturity is intermediate. We're still learning. There's so much you can do. Like I said, we are even coming out with new products, so we have to use waterfall sometimes; but we're still learning about it. We're trying to integrate as much as possible and tailor it to our company.

When we evaluate vendors, are most important criteria are the customer support, scalability, and availability. We've had problems in the past with some other vendors whose products’ availability was not what we needed. They would go down quite a bit, more times than you would think, honestly. That's a big deal for us, especially whenever we put so much into it. If a system goes down, the entire development department basically stops working. That's a big thing for us, especially as we keep putting more and more into CA Agile Central.

If a colleague of mine was evaluating this solution, I would advise them to keep it small. Simple is better.