Rally Software Reviews

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.

For me, it is the burn up and burn down chart, so I can measure progress easily. It shows me the progress of the team and it helps me show the progress to my business.

The charts that this tool has make it transparent. Also, the information is there for everybody to share and it supports Agile methodology. This tool makes it easier. These are the features that are valuable to us. Our team’s Agile maturity level is close to expertise.

I would like to see it more well connected with the PPM tool. We have Planview. It does connect to it but I would like it to connect more robustly. They just introduced a new milestone feature of the product. I would like it to be more user-friendly.

Stability of the product is good.

We have over a thousand employees using it and it is extremely scalable.

I personally haven't used technical support. We have a PPT tool support group which has used it. So, if we have any issues, we report to our PPT support group and they reach out to CA technical support.

When we moved to Agile, we were just using standard scrambled writings on the wall. We knew with the scale of our organization, we needed something to suit our needs and so we decided to invest in this product. It did meet our needs, especially in terms of scalability as we knew that there were going to be so many licenses we would need. We needed a more robust organization.

In addition, we needed someone who was flexible to work with us. At that time, it was Rally and they were very flexible to work with us. The most important criteria for choosing this vendor was their willingness to work with us, features, scalability and cost; also it needed to fit our organization culture.

I did not choose this tool personally, it was an enterprise decision.

I believe they looked at JIRA as well and they picked CA Agile Central.

Go for it but make sure you learn the tool and understand it. Hopefully, you have a product expert.

I would like the milestone features to be more seamless and user-friendly.

The Portfolio is the most valuable feature that I found, because it allows us to drive our requirements along with planning at an enterprise level. That helps a lot. Along with this, there are other valuable features, such as Timebox. It provides proper cadences based on the Timebox that we work with. Those are the two features I find most valuable.

Agile Central is an enterprise tool, so it allows our teams to work together. Individual teams don’t work in a silo. Agile Central allows us to drive all the metrics at an enterprise level. We can then discover what needs to improve at the enterprise level, instead of looking at it on the team level. We are using it for our Agile project delivery.

As I've mentioned elsewhere, Kanban needs to mature a little more. The product itself is focused more on the scrum, but they need to go forward. Also, they did a pretty good job on the scaling side, but they could improve.

Stability is pretty good. It's improved from the past. Ten years ago, I was using this product. As a product, it got better over time.

Scalability, is good, but needs some improvements on some other aspects of the framework, such as Portfolio Kanban. It requires a little bit of work, but we can make it happen. It’s the best tool.

We have ASP service with CA Agile Central. It is kind of technical support, but it is personalized support that we could get for the company.

Our business has been using Agile Central for five years, but I have been using it for almost 10 years. I see the evolution of the features that have come along, as well as the product overall, making this an option that allows me to take it to the next level.

The most important criteria when selecting a vendor are the sustainability of the product, their reputation in the market, and pricing.

I have been part of Agile Central since the get go. Initial setup is straightforward. It is software as a service, so it is very easy for us to set it up; the project and initiative.

The tool is amazing. If you want organized, overall delivery at the enterprise level, this tool allows you to do it for sure.

There are a couple things that our company found really good. One is that it’s scalable, and a lot of the other products on the market for us don't scale. We have close to 20,000 people using Agile Central. So that was one of the keys. Within the company developers, they all have their preferences. So some like JIRA, while some like Agile Central. But from a backend environment standpoint, Agile Central can actually scale for the whole business.

Agile Central helps in terms of Agile management, especially with our scrum teams. It's designed to be used from an Agile standpoint, so I think the teams that have struggled with it are the ones that aren't really set up for Agile. Agile Central is really founded as an Agile tool, so if you're not doing Agile, the tool doesn't work all that well for you.

Our company is large and we've got a very wide gamut of Agile maturity. We have some teams that are very expert in Agile and we have others that are still Waterfall. It's a 100+ plus year old company, so it runs the full gamut. Personally, I have been using Agile for a couple of years, so I'd say I'm pretty familiar with it at this point.

We've been asking for a couple of things. A big one for us has been on the administrative side. Again, I'm coming from a very large company so these are the things that are, at that scale, very important to us, such as access. How do we get access to people? How do you move a large number of people?

The other big one that we've been requesting for years is the ability to move people between workspaces. For us, that's really important. Every time we've had to do this, we have to get technical support involved and it's just a big pain in the butt. Within Agile Central, each workspace is very independent and one workspace can't talk to another workspace.

We have multiple workspaces set up and when a team wants move from one to the other it's very difficult to do. For instance, with a big organization you're always going to have organizational changes. So you may have set the things up perfectly when you first set it up, but things change. Now when they go and change, since we can't move workspaces easily, the new teams that are together can't collaborate because they're in different workspaces. There's no easy, functional way of doing it.

I also think the UI could use some improvement. I believe they're working on it. Also, it's not the most developer-friendly tool. So while management tends to like it, I don't know if developers are huge fans of it, at least in my business, from what I've seen.

I think stability has been fairly good. I don't know whether to attribute the issues that we've had to Agile Central or to our own network. And we have had issues, but they've been pretty quick to respond and try to come to the root cause of what's going on.

We've had some scalability issues but, to be honest, because it's a SaaS product, I'm not sure if it's a function of our network or Agile Central. Sometimes it's difficult to tell, because we've got a lot of internal networking that we're doing in terms of security, etc., that slows things down. So when we have had complaints about it, a lot of times it may be us that's at fault and not so much Agile Central. But, an important factor in choosing Agile Central was scalability.

We actually offer both JIRA and Agile Central within the company. So we try to somewhat make it a user choice as well. What we typically recommend is that if it's a very small project and it's a quick turnaround, JIRA's probably your best bet. If you have something longer term, Agile Central is probably going to be an easier tool for you to use.

I wasn’t involved in the initial setup.

We didn't evaluate anything other than JIRA and Agile Central.

I think you have to think through how you're going to organize, especially if you have a large company. We've struggled with the structure of our teams and the way they're set up. So that's something you need to consider. And I don't know if they've done a great job of it. They actually call teams “projects”, which is a bit of a naming issue.

You definitely need to have some foresight when you set it up in terms of how that's going to work. You also need to think about how you're going to do workspaces, because there's no functionality there to change it once it's set up. You've got to get that right from the get-go or you're going to have a lot of trouble going forward.

The best feature for our company is that it's easy to use, and it integrates with our other solutions, such as the code warehouse, the test solution, and the deploy solution. We wanted an ALM product that was easily integrated, because we have 170,000 users in my company. We need a strong solution to support us. We must have:

• Ease-of-use
• Easy to integrate with other solutions
• Good stability

I don’t know this product well enough yet to offer suggestions for new features. I recently went to a conference to learn about CA Agent Manager as well.

See below regarding stability.

Stability of the product is not good. It is critical for us to make the solution stable.

CA Agile Central scales very well. We have 170,000 users.

We have not used technical support. We bought the product and were ready to work with it.

Initial setup was easy for me. A consultant came to our company to sit with our people.

The ability to extract data to provide feature and release metrics for our executives and our customer stakeholders is very important. It provides reports on the cycle time from the time that feature requirements are initially defined to when they are available for release. Release in this case does not mean production, because it does not include that capability.

For me, it's important that it supports both an agile scrum and a Kanban implementation. I've had responsibilities for operations in the past in which people were trying to force the operations team into a scrum implementation or methodology, that doesn't work in an interrupt-driven world that you have sometimes have in production when you have to deal with production issues. 
 

• By using this extracted data, it provides a real picture, instead of a perceived picture, of the amount of work the team is doing, the time it's taking to get new changes out, ready to put into a user acceptance test area, and production, which is really where our problems are. It's not solving those problems right now; but it is providing data that I use to present data on the deployment delays. For example, we can see that we’re finished at point A, but we're not actually deploying it to a production environment until point B, which is sometimes only three months later. So there is a delay in getting the features that customers want to production. This is because we lack a DevOps culture. CA Agile Central is giving me real data to show that for many features. 
• Our company implemented the scaled agile framework. I believe they've created a heavyweight bureaucratic implementation, and I think they have some work to do there. It’s putting wear and tear on our team. We just did a total pivot. With scaled agile, we work in three-month program increments. I'm actually used to planning out that long, but we had a business situation that came up in which our whole department did an immediate pivot; so we are pretty agile. I just think that we have some work to do on the wear and tear on the team.
• I think I have a great handle on agile methodology, but I haven't done any portfolio management using agile tools. 
• Our team’s agile knowledge is intermediate, but they're learning; and they're learning on their own now. They actually understand their limitations. When I started, they had been doing the whole methodology for a couple of years, but they didn't realize where they had opportunity to grow, which is one of the reasons why I was brought in. Before, they just needed to be directed.
• For people outside my team, we created a scrum master guild, and we use that all the time. One of our best practices is that we created agreements across all of our teams regarding how those specific teams work. Those agreements are not the same on every team, which I think is exactly the right way to go. It is definitely a positive change for the organization now that each team can provide information transparently to executive management. Everybody seems to think that’s a good thing.
• We also do a retrospective across our teams, which I think is very open. That's pretty refreshing to see.

• I would like them to give me back the fields I used to have. We lost the release field because they mentored our scaled agile framework trainer to actually use the release field as what I would call a program increment.
• We're releasing every two weeks, so it's pretty hard. They also should put a product field in there. We have work areas. Our work area is our team, it's not our product. So my team actually supports four different products. I'm doing name mangling that I then have to write code around to understand how to get metrics out. That is challenging.
• The other thing is that I think I can pull out data from the release, but we're not using all of the CA Agile Central projects. For example, we're not using the testing part of it. We do use the defects. I don't know how I'm going to integrate the testing tool that was selected by the test organization. I don't know how I'm going to integrate all of that. They might have plug-ins for that. I don't know.
• The only thing I can think about is finishing the lifecycle. There are tools in there, and I don't know how I can close the loop.

I have been using Agile Central for 10 years. At my last company, I had access to just go in and look at everything, but I don't have admin access at my current company.

Our product is doing very well. We had one production issue in the last three months, which is pretty good considering how large our customers base is.

We launched our product in April or May. We had two or three issues in the first month that I think had to do with the whole DevOps theme; and how it was configured and set up. We are working really hard on the DevOps side, but we have some work ahead of us. We’re not there yet. But we haven’t had any real software problems.

We're able to scale as much as we need right now.

The initial setup was complex. We have a lot of different internal and external integrations.

I wasn’t there when they selected it. However, I will say that having had the scaled agile framework, I'm a little disappointed at what it looks like in comparison to something like AgileCraft.

I think that they have some work to do on the scaled agile framework side. I don't know if they're doing it because I'm not in those discussions. 

I haven't really looked at any other vendors. Someone just sent me a link to AgileCraft. That's the only reason I mentioned them, and I don't know if it works. I just saw the “marchitecture” stuff.

I fully support CA Agile Central as a product. I would guess that I also support their scaled agile framework Implementation of it, if you go in with your eyes open and have honest discussions with the CA Agile Central implementers.

We do technical support and even more than that. We do what I call operational monitoring. We have an operations team on one of our products; on the other product, we don't. We're the operations team.

We actually just instituted a new process that we're implementing. We go out and check each of our environments every day. We are always deploying to QA, and always have something in our user acceptance testing area and in our production area. We look at all three of those environments. Any problems we see, we immediately investigate.

I think that's how we've been able to prevent some of the problems we were having. At least the development team is doing that. The operations team has their own methodology.

It allows me to do large team planning operations, where I can do "big room planning" and have all of my Agile teams in one session. We can get through all of our planning through the use of the software. With big room planning, we can get it all laid out, understand what the dependencies are, where the interlocks sit, and which sprints can be optimized. The portfolio tracker tool is phenomenal. It gives us the opportunity to look at our features holistically across the entire landscape of the solution, where they fall within a continuous delivery (CD) release when you're looking at a DevOps model. It allows us to apply those features to the DevOps model. I can take that and apply it across all of my teams, look at it when we can pinpoint exactly when that feature is going to be delivered holistically. This is a huge value to our client, who is Cisco.

We can have high predictability, which is what Agile tries to do. We can have low cost of ownership, dealing with “just-in-time” delivery for the monthly releases, because we release on a monthly cycle. We can look at this information and say when those features are going to become available. The portfolio tracker is huge, a phenomenal piece of the add-on functionality that's been wonderful.

I also like the use of apps, and the ability to use the customized HTML capability of the apps. We're working with the consultants to design a custom look and feel for specific types of reports that we need. It's very open architected, so we can take advantage and utilize the software as we choose to use it, and have a really good experience with it.

There's some room for growth. There's some more functionality we'd probably like to see in it, but at this point, it's been a stalwart product for us.

It's optimized how our organization runs. We can look across multiple teams, using Scaled Agile Framework Methodology (SAFE), so that we can look at various release trains, and how that then flows up to the overall program budget. Each train has its own unique budget line. I can look holistically across all the trains and have it flow up to the program office’s budget. I can track personnel within the software. We can do all of the quality functionality and spread that across multiple tracks. In this way, one track is not going to be heavily burdened by taking on the quality function.

The big value add is not only the ability to do Agile, but scaled Agile as well, utilizing the budget functionalities. It’s really top notch in that regard, with the ability to work with the personnel function of the software. It gives us another holistic view of the overall functionality and operations that we have providing a value add to our customer, Cisco.

The main area to improve is performance. If they can get that performance improved, they'd be golden. They really need more in the DevOps modeling, and the use of Kanban. Their Kanban area is fairly weak. That's probably the one area of the tool that, outside of performance, really needs improvement. If they could add more robust Kanban functionality, then they would have the best of both worlds. You would have a DevOps capability, Scrum capability, and Test Driven Development (TDD) within the tool.

That would also help from the quality perspective. When you're dealing with your DevOps team, especially when you're trying to do releases on a monthly basis, they need to be tied into deadlines and be able to track through a Kanban mode. They need to know about the workflows, the work in progress, and how it moves through the workflow. That would probably be one of the main areas I would tell them to put some energy into the Kanban side of the tool. If they did that, then they would have pretty much the complete solution. They are losing a lot of business to Trello.

There are performance issues that nag the product. I would like them to build out a more robust Kanban workflow methodology system. Then, I would open up the APIs more. I would allow for third-party solutions to be able to plug in easier. There's a little bit of work that they'd need to do.

There's a couple areas where that they can make significant improvements, and I'm sure they're working on it.

Stability is very good. The solution rarely goes down. When it does go down, we make a couple of phone calls and we get a really clear estimate of when it'll be back up. We get e-mail alerts when things aren't going too well. The biggest issue that the product needs is to improve is performance.

Ever since the Agile Central package (formerly Rally) came out, performance has always been an issue. It lags behind, at times, especially when generating large reports. That's probably the number one area for improvement. They know that. I'm telling them nothing haven't heard before. If they can get performance at a much better level, I think the product would be really well received for other companies, who tend to shy away from it from a performance perspective.

One of its main competitors, AgileCraft, is a high performing product. It's got really good performance. They really need to be competitive with some of the other products on the market. I have used it extensively. It's a great product. Its premier focus is being a safe solution, where Rally tends to be a Swiss Army Knife. It's more for all encompassing type of Agile work. Whether you're doing SAFE, standard Scrum, Test Driven Development (TDD), Feature Driven Development (FDD), these are all areas for which Rally can be utilized. That's what makes it a very multiverse tool and allows you to work holistically across an organization, where AgileCraft has a very specific, narrow focus.

Scalability is very good. No problem there. It will scale as you need it to. That's not a problem.

I personally haven't used technical support. My interaction has been through our consultant. We have a dedicated team of consultants with whom we work. If we ever run into an issue, we usually just pick up the phone, call our consultant, and explain what's going on. We do have support through a Cisco support group. They're extremely responsive. When we run into a problem, they usually solve it within about an hour or so.

Vendors who were on our shortlist were JIRA (Atlassian) and AgileCraft. At the end of the day, we chose Agile Central, mainly for its robust capabilities and the ability to talk to other database systems. For example, I can bring in all those JIRA defects or issues, into the CA central product, because of the open API architecture. Using the SOAP API codebase, I can then have one of their consultants write me a custom hook that allows me to bring in all the data from those other databases. The other two solutions didn't have that open-ended modular framework that allowed me to pull in information from older systems, whether it's coming out of Excel spreadsheets, or older systems, like JIRA. That's one of the big things that we look at.

When making a decision to switch products, I consult others on tool choice based on the number of departments they have. I went in as the Agile coach to Cisco and recommended that they move to this solution. One team I was working with used JIRA. It's an option that Cisco allows some of their departments to use. I got them out of JIRA into Rally, mainly because JIRA is older technology, and it's too lightweight for a major corporation such as Cisco.

This tool allows you to talk to the rest of Cisco. If you've got one group running one solution and you've got another group running another solution, they can't speak to each other. They can't share data. They can't assign issues to each other. By moving one off one platform and moving them onto Rally, or to Agile Central, we can now holistically start to work across organizations, and see each other's problems.

The only other big issue is their workspaces need to talk to each other. That's another area for improvement that would be good. There are a few areas they had to work on, but cross-workspace communication is the main one. If they could solve that problem, that would be amazing. I would be so happy. Even in my own group for which I'm providing consulting services, we have multiple workspaces and we can't talk to each other. That can get a little crazy. We have to create this third solution that we all feed into. Obviously, nobody pays attention to it, because everybody is so focused on their own lane.

In terms of selecting a vendor, I look for the responsiveness to quality concerns. Whenever you've got an issue, the timeliness that they'll come back to you to resolve those technical issues is important. I also look at whether or not they have consulting services themselves for customization work The other part of it is just overall “solutioning”. I want to know if they have a complete suite of products, or if it is just a standalone, a one-off. If it is, then I have to go bring in three or four other additional products to augment the single product. Then you've got multiple bids and you're talking across multiple vendors, and that can be a headache. I just want to do one-stop shopping.

That's what CA provides holistically across the entire platform. They're going to give me everything that I need. Another factor is with one vendor, you work on better pricing structures and a better deal. Whether it's in service, or getting a discount on other products, you can weave all that in as an opportunity going to one vendor.

My advice to other is take a test drive. They have a sampling system that you can demo. They'll give you a space to put your product in and try to go through the whole workflow process. Make sure you go through the whole workflow process. Really see and understand exactly the functionality that the solution has to offer. A lot of people stop at the very top level, the one-inch level. Go underneath the wave and dig down into the solution. There's a lot of great opportunity there.

One of the neatest opportunities, because of its HTML capability with its apps, is the ability to embed a lot of my Smartsheets right into the solution. I can take team rosters and embed them. I can track monthly performance reports and a number of different functionalities that are available to me via the Smartsheet. I can update my Smartsheet, and it'll automatically be reflected in Rally. That is huge in the CA Central product. That's significant for me.

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.