Rally Software Reviews

I don't know which feature would be more specifically valuable. I guess the portfolio items would be the ones I use the most, but I also am very familiar with the quality module as well.

Some of the reporting stuff would probably rank right up there as well. Those are probably my top three.

I think what it's helped with in general is that we've learned a lot about how to break things down a little more in detail. Going from primarily a waterfall organization into an agile organization, the tool has been very helpful to help people make that transition.

It's a relatively slow process, unfortunately, as it's a large organization we're dealing with, and everybody interprets things a little bit differently. We've had some people that have really spent a lot of time with the CA resources, who really understand the product and help the users use the tool effectively.

I think one of the things that we stumble upon is how to organize the teams. We have one overall workspace, but outside of that workspace we have many, many teams underneath it. I think you can organize them in two different directions. You can organize them by leadership or organizations, or you can organize them by, for lack a better term, product. And those two don't sync together, because you have many organizations contributing to a product that don't roll up to the same leadership level.

So from a reporting aspect, for different things, we struggle trying to get that balance; to get the reporting for the leadership side, and then get reporting for the product side. That is one aspect. It's not necessarily a hierarchical issue, it's a flexibility issue, if you ask me. If you put it in one direction, you can't get it to the other. So you need to be able to balance it both ways. That would be something I think that could be worked on.

I have been using the solution for more than three years.

I personally haven't had any stability issues. The only time that it's been a problem for me is when I've extracted data around test and defect information. The extraction process has to be broken up; you can't do it all at one time. It's not impossible; it's just a little more work. Whether it's just because of the amount of volume we're talking about, or if it's just that there would be no way to fix that, I don't know.

Specifically, in our case, we're getting very close to the millionth test case written in the 3+ years that we've been doing this, and that's a lot of data. But you can't extract it all at one time; you have to break it up into chunks.

I personally have not encountered any scalability issues.

I would rate the technical support at 9/10. That's a very, very strong nine. We work very closely with some of the technical support people, and have for a very long time, and they are great partners.

I think what they do today, especially with their tech support side and the relationship we have with them, they are very open, they listen, and we understand that we're not the only client. We know what our users come to us and ask for. We take that information in and compile it, and have conversations with CA Agile Central, saying, "Here's what we've come across," and they've actually been very responsive to some of the things that we propose.

We know we can't get it all, because they have to make the tool useful to all their clients. So we'll present what we think is viable, and it's just like anything else. Some of it makes it, some of it doesn't. I really can't ask for anything more than what they do. They're very open, they will listen, and they will do it if they can. That's fine by me.

This was the first Agile Central tool that we used on a grander scale. Again, we switched from a waterfall organization to an agile organization, and this tool doesn't support waterfall.

I wasn't involved in the setup process.

I am not involved in the pricing and licensing side of the operation.

I wasn't involved in any such evaluation.

I have had some experience with one of the other tools out there and personally, I like this one better, so I'm a little bit biased around that aspect. If somebody were to ask me, "I'm looking between this and that ...", if I know the tool, I would have my biases towards CA Agile Central, for sure. I think it's a pretty good tool.

Organizing all of our Agile work load, and projects that we have in the pipeline.

It's been good. I don't know that it's best suited for Kanban which is the Agile style that we're using. It seems a little more focused on Scrum. So having some more Kanban methodology built into the product would be nice, but it does allow us to move our stories along the board, and have a good visualization of where everything is in process. 

It probably would be mostly the visualization of what's in flight, and being able to move the cards across the board, and plan our releases based on completed work, which really is the goal of Kanban.

The most valuable feature is actually creating a field within there for architectural review. So when teams are struggling or have questions on the architecture or strategy that they take, they can actually flag that particular story, release, or project. Those can then be reviewed by the architecture team and the teams actually get additional information on how to course-correct, build on the architecture that we're trying to build throughout the organization, and get over road blocks much quicker.

I would like to see more Kanban support. As it stands, it doesn't seem to have the features or the layouts that the teams really need to be able to execute their tasks. It almost tries to force you into more of a Scrum style.

Stability is great. We rarely have problems with it.

The scalability is fine. We don't have a huge development team, so it doesn't really need to scale that big.

We were doing everything Waterfall at the time.

We were looking at two different products, CA Agile and JIRA, and it seemed like there was less customizability for CA Agile, and that was important because we didn't want to have all the teams doing different things. So the lack of customization was a selling point for us.

Also, the reporting, and being able to roll that up across the verticals, was an important selling point for us.

The most important criteria when selecting a vendor are 

• the support that we can get
• the ease of upgrades
• just having software that works. 

Even though it's not part of our core business, a lot of the supporting tools need to work for us.

Having the right tools is important, but more important than that is actually the culture, the people, and the processes. Take a look at your culture, your people, your processes. Make sure that those are what you need them to be and then select a tool that is going to work well with those objectives in mind.

There are so many high-value features it is hard to choose but I will say the most valuable feature is the fact that it provides traceability from the strategic objective to task level with rolled up and detailed reporting. This is valuable as activity is joined up from top to bottom; a developer in a feature team can trace their input at the task level all the way up the hierarchy to the strategic objective they are helping to deliver. On the flip side, the CTO can have a view of real-time progress against the delivery of strategic objectives, drill down to the portfolio epics and business outcomes with the potential to see the value being delivered.

It has enabled the transition from a project-based portfolio to a product-based portfolio.

It could do with a wider range of colours for cards and the Kanban features need some improvement (which I know is on the way this year). The colour swatch for cards in Kanban board views is quite limited; I think there are 9 possibilities. Using these to visually differentiate cards on a busy board becomes less valuable when multiple themes are sharing a card color.

Kanban features should be built around flow, which implies they should not be constrained by time boxes. This is of particular relevance when considering many of the views that, by design, require one to select a time box. This is also true of reporting. There are some things to consider, though, as when viewing a personal or team board, one doesn’t want to see the entire backlog, so it would be useful if that could be limited to a user-defined number of stories.

I have been using Agile Central for seven years.

We have never had stability issues in seven years of use.

It is the most scalable product of its kind out there.

Technical support is excellent.

I have used JIRA, Trello and IBM Rational, but none of them are close to Agile Central.

Initial setup was very straightforward and guided by CA consultants.

If you want the very best, expect to pay accordingly. But you will get ROI from it, especially if you are doing agile well and at scale.

In my current role, the firm evaluated JIRA, Agile Central, VersionOne and IBM Rational (I think).

You will only regret it if you have chosen the Rolls Royce when you could have got by with a Nissan Micra.

The ability to integrate to the HPE Quality Center is a powerful feature although we haven't used it yet and won't be doing it.

The test case organiser is another useful utility which could help users still using waterfall methods of working if they intend to use it for a while. This functionality is not inbuilt but was showcased by one of their support guys from CA who are happy to share it with customers.

Another notable feature is reporting at Portfolio level, and an organised business area which is set up from scratch with this tool can benefit from this feature. A senior manager will have more visibility as to what is happening in various projects and teams.

It needs to become more mature for large organisations with better integration required to DevOps. 

It has the capacity to let you integrate if you have in-house development capability but not out of the box. 

Solutions are available to integrate it with development tools or Atlassian tools but they are expensive.

I believe Excel imports and the ability to modify workflows are two important improvements which will enhance its competitiveness in the market. 

I believe the feature to use Excel to import issues, tasks, test cases or any other relevant data will be a useful functionality which is missing and many teams are willing to have such a feature. Also, the ability to modify workflows to support custom requirements will increase acceptability of the tool. Currently it has a slightly rigid response to users wanting to tailor the project for their need.

I have used this product for less than a year.

It's a SaaS solution so no involvement in building it up. 

For a large organisation, whether a bank or retail outlet, it has some challenges to integrate with the company's authentication methods. 

Data integrity holds a challenge as data needs to be made secure which takes effort to achieve.

For a large organisation, whether a bank or retail outlet, it has some challenges to integrate with the company's authentication methods. 

Data integrity holds a challenge as data needs to be made secure which takes effort to achieve.

Customer service is 7/10.

I don't know the price but it's certainly cheaper than others.

Atlassian JIRA and HPE Quality Center: They are market-leading tools and still quite competitive with more features to support both waterfall and agile models.

I would suggest to do a comparison chart for your organisation's needs and look at least 5 years ahead for the functionality and budget you are looking for in a tool. Not only the tool cost is relevant but also the resources to maintain it. For a very small organisation, I could certainly recommend a SaaS solution but for an organisation with more than 500 concurrent users, a standalone solution would be more apt, in my opinion.

We primarily use the solution to scale agile and for safety.

We use all of the features. It's been a great solution so far.

It's very user-friendly.

We are able to implement PI planning for safety.

We'd like to be able to export information about the users, like rules. It's not easy to identify the teams, users, and rules. We'd like better dashboards to make visibility better. They are a bit complex right now. 

It is not integrated with the PPM. It's very difficult to make an integration with both.

I've been using the solution for seven years. 

We have 1,000 to 1,800 users on the solution right now. We bought 2,000 licenses. 

The solution helps us scale our agile projects. 

I'm at a different company now, and they use ServiceNow. 

We renew licensing every three years and pay for the solution yearly.

I was a user and customer. 

I'd rate the solution ten out of ten. I've very happy with the solution. 

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.

Managing our development life cycle. In the ways in which we use it, it has been adequate.

We have gotten away from so much paper, which is more dynamic. It allows us to work in a more dynamic fashion and track more of the development lifecycle. 

Essentially, we are replacing TeamTrack. TeamTrack was more of a waterfall type of process and documentation for us. In fact, I have tried to go back and look for some of those old projects and it is not possible to find them. Although with this product, searching for historical information or the evolution of the requirement, detecting conflict between projects has helped a lot.

Better requirements. As the story is developed, there is not so much time devoted to clarification of requirement. It helps us get a better product to production.

It is a more detailed process for a lifecycle. We go from requirements to implementation. I use it with my teams for time management as well, time reporting and management.

We are not on the most current version, so it may have been addressed, I have not really seen the new product yet. 

I would like to see more in the way of capitalization. I spend a lot of time on capitalization. Working out capitalization, it is largely manual work, where it does not have to be. The tool, I think can support it. When it is a story, capitalization in the current version of the solution we are using, occurs at the task level. I would like to see it roll up a little better to the story level, then up to the feature.

I have not had any issues with stability at all.

It requires better scalability for the implementation of the whole suite. We do not use it in that fashion, and visibility is sometimes a problem.

We are housed with our business units and we are a Fortune 200 company, but not all the elements of the business units can always see an aspect of a project or stories. They can't get those stories, which are not necessarily visible. I happen to manage development on a product that has impact across all business units, across all business departments. So, I have to do some housekeeping, and maintenance in trying to broadcast what we are changing about the software to those other units that do not necessarily have the ability to see those changes, or awareness that those changes are happening.

I have not used technical support. I work with a person in-house who liaises with CA.

We underwent a philosophical change, if you will. We consciously chose to move away from waterfall as a development mechanism to more of an agile framework. We are not a traditional agile approach, because of the nature of our business. I would really like to see more flexibility, flexibility in adopting hybrid approaches. 

I did not find it to be complex. I find the methodology to be more complex than the tool.

One of my development teams was one of the first teams to use and embrace it. It was a new team, so it was an easier transition for that team to begin using this product over the other tools that we use.

Have a clear vision of where you want to go, and make sure the elements of the tool accommodate that vision.

Most important criteria when selecting a vendor: 

• Cost
• How well we can adapt the practices of the vendor to have some pretty clear direction on where we want to be, not necessarily how to get there. It has to be a partnership. 

It helps us organize our projects so that we can get down to really detailed work items; really granular, busting up a task, a feature, and parsing it out so that we really understand what's needed. We can put it into small, bite-sized pieces that can be addressed quickly. If somehow there's a misunderstanding or miscommunication, it can be adjusted and corrected fast and easy.

I'm the subscription administrator. I rarely use it as a user. I generally only use it as a user to troubleshoot. So to me, as an administrator, the most important tool is looking up the subscriptions of my customers to see if they had logged in recently.

To me, the biggest thing I see that needs improvement is the navigation. When somebody's using more than one workspace, it's not obvious how to go from one workspace to another. It's simple enough once you know, but is you're looking at the screen, you don't notice it.

I actually have to write documentation, and I sent it out often to tell people how to navigate from one workspace to another when they're on more than one workspace; in a sense, more than one project, though a workspace is a bigger bite of a project. If you're really just on a different project, and they're all on the same workspace, it’s not a big deal. But when they have to switch from workspace to workspace, it's not obvious. So, that's where I see they could improve in their navigation. Make it more intuitive.

For the most part, stability has been good. They did go through a small shaky patch when CA bought them (Rally) and they decided to move data centers. It seemed like there were some outages, but that has been fine since. It can be a little slow at times, but as far as up time, it seems to be quite good.

I don't know about scalability. From my understanding, we're medium to small in the grand scheme of things. There are much bigger shops than us. But we're not small either. We're in the hundreds. So, it seems like there's plenty of scalability.

I have to say, since CA bought it, support has actually improved; which I'm very surprised about. I found in the past, when it was wholly owned by Rally, they forced you to always go through their website first, search their knowledge base, and then post a case. And then they'd contact you within a day or so. It was okay, but it was less satisfying when that's the only way to contact them; and I always had to go that way.

The technical support seems to have improved quite a bit since CA bought them, which, again, I was very surprised that it has improved instead of get worse. It seemed to be able to handle phone calls better and are even more responsive. I'm very happy.

I wasn't part of the discussion to buy initially. It was already here when I started. It seems that we have grown, though, and switched from other tools. It just seems like the granularity it provides and being able to really be good for development teams and really focus on their needs, and that is why we use it so much and it's growing.

Setup seems relatively straightforward. It was easy to learn. Most teams teach themselves how to use the tool and new teams generally hire somebody who understands the concepts, so just a cursory show them the fields and the setup, and they're good to go. There's nice three- to five-minute videos that CA provides from their website that helps teams understand the concepts and the usage.

Just be open and take advantage of the videos to see if they understand what the product is and to reach out to the vendor and ask them questions. They seem very willing to help without necessarily charging. If they feel that you're a potential customer, they're happy to talk to you and give you some guidance. If you need a lot of help, then of course, then they have programs to actually send experts.