Rally Software Reviews

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.

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

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

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

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

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

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

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

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

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

Primary use case is agile development and Mode 2 development.

It has performed really well. We have taken some teams that were non-Agile and tried to do a combined approach. This eliminated some of the heavy documentation that we were used to with waterfall. We have been able to deliver our integration between CA and HPE ALM in a period of time that is about half of where we were before. 

It documents stories in a way where we do not have to be heavy on front-end requirements, front-end documentation, and front-end workflows. We are able to create those stories in a more of a just-in time approach. Since we are doing combine and not scrum, we want to get those stories on as we think of them and immediately work on them instead of waiting for a time box. So, it was the ability to adapt quickly. 

We are very new on agile and Mode 2 devolvement. It has really allowed us to experiment with approaches that we would have been a bit afraid to experience before. So, it has allowed us to try new things and to take risks. 

When you copy a story, I would like the attachment to copy with it. This is a big one for us. We do requirements in one sprint, then do development in the next, which still is a little bit of waterfall. So when we copy those requirement stories and they become development stories, the attachment does not come with it. So, it is a lot of manual effort to do that. It would save us a lot of time. 

We did submit an enhancement request. I think a lot of teams that do very large scale products have the same issue. They just do not realize it would help them. 

Also, there are a few things in the way things trickle up from category to theme to feature that I do not really like. I wish there would be some enhancements there.

It is very stable. It was purchased by CA from Rally, which I was familiar with beforehand. It has gotten better since CA has taken over, adding some new features, but it is a very stable platform. 

Since we are more of a Waterfall shop, as we bring new teams into the agile approach, I think it is quite scalable for us. However, it will probably be a more longer term poll. 

We have used them quite a bit. They have been very responsive. We use a competitor's tool for our waterfall approach. I won't say which competitor it is. However, we have been very happy with the speed and the availability of CA's technical resources.

Our issues have been lower scale problems, but we do not have a support staff to manage Agile Central. What we found was technical support was not only giving us the ability to get help, but also helped us evolve our support team into a team that can be managed well on its own. So, I have felt they have helped us in a lot of ways.

We did not have a solution in place. We were looking at Mode 2 and agile teams and we knew we needed something. Putting post-its on the board was not going to work anymore for a company of our size. While we still do some post-it exercises, it all ends up in Agile Central and we knew we needed something to manage this. We still have PM's who want to see portfolio management, so we knew it had to be digital. It could not be paper anymore.

We took our instance and revamped it from the beginning, which was very straightforward.

We were. We were looking at a few. Not sure if I can say which.

They were not providing a solution that was mature and developed. They were providing solutions that they wanted us to be like a test customer on.

They still feel like a small tech company. The support we have gotten and the way they have managed or accepted some of our enhancement requests. They still treat it like a small company, like Rally was before they purchased Agile Central. They still have that feel, knowing how big they are and seeing how they can act small. It is really nice.

Make sure your agile processes are really well-defined before you go out into the market and look for a tool. Tools do things differently, they call things a feature in one and a subfeature in another. Make sure your processes are defined, and once you have that, look for your tool after that. Do not look for your tool first.

Most important criteria when selecting a vendor: We have price, which I would not say is our most important. We are looking for more of a fit and finish to our process, though price is really important to us. One of the things that we look at is: We want to create a really good process, then find a tool that fits that process. I think a lot of customers do it the other way. So, if our process is mature and we like it, the tool really needs to fit that.

It is easier to:

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

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

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

I have been using this solution for about a year.

There were no stability issues.

There were no scalability issues.

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

The setup was quite straightforward.

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

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

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

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

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

RALLY costs around $60/month/user seat

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

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

I have been using Agile Central for two years.

It has good availability.

We did not have scalability issues.

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

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

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

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

We evaluated JIRA and others.

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

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

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

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

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

I have used this solution for six months.

I have not encountered any stability issues.

I have not encountered any scalability issues.

I have not used it personally.

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

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

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

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

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

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

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

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

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

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

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

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

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

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