The product itself seems to have a lot of bugs. One issue is that it sometimes allows people to modify data inappropriately. For example, team members can change numbers at will. While we have a mechanism to track changes, people can still alter numbers, create or delete tasks, and create or delete high-level activities without proper controls. This causes problems when we try to generate reports, as we may not get an accurate picture at a specific time. Certain activities should be subject to more managerial control. We have some control, but team members have too much discretion in creating and modifying tasks. They might put in unrealistic numbers for how long an activity will take. Sometimes, they change numbers during meetings and then change them again afterwards. I suggest implementing a better locking mechanism and improving the security aspects of the tool. Currently, if I create a task, someone else can open it and make changes. This can cause issues when multiple team members are working on different tasks. What we need is a system where only the owner of a task can modify it. If a task needs to be split between two people, it should be possible to break it down and assign parts to different members. But the access control needs to be more vigilant.
The interface isn't very good. The integration with other tools is quite complex to understand, and the reporting wasn't great. At least for me as a QA, the test coverage and test management on a release basis weren't ideal. I like visualization that gives me a clear picture rather than going through numbers. Octane gives me the flexibility to customize my reports and provides me with a different set of reports that are helpful for me to find or analyze project details. It also has some because we have integrated our Jenkins pipeline into Octane, and we have the option to trigger automatic reports to the organization. So it has us reporting as well. We have had a lot of issues using it.
Dev Ops Engineer at a insurance company with 5,001-10,000 employees
Real User
Top 20
2023-12-22T18:50:50Z
Dec 22, 2023
It is hard to track the changes. For example, we're in sprint 25, and then we have 26, 27, 28, and 29. Throughout that whole time, we're developing pipelines in Azure, moving to GitHub, creating pipelines, and working with teams. But sometimes, we need to revisit specific decisions made in previous sprints, like pipeline details. Maybe it's in our Azure Wiki, GitHub, or Teams, but it's not always consistent. I wish I could search for all tasks or stories related to that particular effort without needing to know everyone's individual stories or features. So, I would like to see a tag system with prefixes like KBI for knowledge-based information or JC for Java Core to search and find relevant items easily. It would be so much easier to search for everything related to KBI or the actual feature itself. I could even search within my group using a shared scrum team name, like "Snoopy's Developers," and then find everything related to JC or Java code. Another pain point for us is managing our limited number of licenses with contractors coming and going. It's a constant struggle to figure out who's still active. We have to run reports to find people who haven't used Rally for x months, like logged in or whatever. As an admin, wouldn't it be great if we could have an automated report emailed to someone, say another admin, highlighting users who haven't logged in for, like 12 months? That way, we could easily go in and deactivate or revoke the licenses. If someone hasn't logged in for eight months, why not have Rally automatically disable them? So, easier license tracking would definitely be beneficial. Those are my two main wish-list items. With the Description field, it can work for them; it's free. But they have to be diligent enough to remember to tag things there. And even then, it's not always clear during stand-ups unless you specifically look at it. Someone is working on "admin" or "accessories" or whatever that "digital transformation" tag is. That kind of thing helps track progress at a glance.
Sr Engineering Manager - Design Engineering at Baker Hughes
Real User
Top 20
2023-04-20T10:43:00Z
Apr 20, 2023
I don't have any specific suggestions for improvement regarding the solution because we are currently satisfied with all aspects. Our usage requirements are relatively straightforward, and we haven't encountered any significant challenges or complexities. Therefore, I don't have any valuable suggestions to provide at this time. I hear from some people that it could be customized, but they don't have details on how. Customization is possibly a desirable feature, and I don't know if it is available in the system. Customization features may not be exposed or unavailable, so people may be looking for them. So, customization is an area people have told me is more desirable.
Agile Delivery Transformation at Transparent Change
Real User
Top 20
2023-04-19T19:28:00Z
Apr 19, 2023
Rally Software is highly complex, and it takes some effort to get everything tied together. But once you do, it's a satisfying experience, and the result looks beautiful. Azure, ServiceNow, and Jira do not have all the features that Rally Software provides in one place, making it an exceptional tool for project management. It was either Optum or Rally Software that had a significant number of connections and workflows that were challenging to comprehend. As a result, the visualization was lacking, which was frustrating. One feature of Jira that I admire is the ability to view the workflows for user stories, for instance, by going into the user story settings for my team. You can see where the story is heading and what the workflows are. Unfortunately, Rally Software does not offer this visual representation, although it does have all the connections. However, to utilize it correctly, you must be aware of how to set it up correctly, and Rally Software could do a better job of splitting up workflows.
The big problem with Rally Software is migration. If I were to migrate from Microsoft Azure DevOps to Rally Software, it would require more effort because in Microsoft Azure DevOps, every time you create a project, you have Git for each project you create. My current company has the pipeline and virtual machine for compiling code in the project, so if I migrate that, it would mean that I have to put in extra effort to evaluate the pipeline in Rally Software, so that's a big problem for me. In Rally Software, the connection with GitLab and GitHub needs improvement because every time I evaluate Rally Software, there's an issue. When I have a lot of team members and push the code in Git, I track the requirement and the code. Rally Software needs to improve in that area because I'm a person who understands the requirement. However, I still have to evaluate the code, virtual machine, and pipeline despite my knowledge. I don't have this problem with Microsoft Azure DevOps, only with Rally Software, so this is an area for improvement. In future releases of Rally Software, I want it to have GitHub and GitLab connectors. If it has existing connectors, then the connectors should be better.
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.
Rally has the ability to improve the features. We would like to see progress made against the features, probably in the form of a dashboard, where when teams complete stories, the features upload, and the stories are completed, and the feature about them gets updated with the progress. This is available in Jira but not in Rally. That's something I would like to see because the management wants to see how far we have come with the epics and the features. They want a dashboard that would allow Rally to provide a picture to the leadership of the progress made on the epics and features. There should also be an automation feature. When the last story in the feature is finished, the feature's status should be automatically updated. The user interface can be improved. I still don't think the UI is as impressive as Azure DevOps or Jira. The performance can still be improved. Rally Software should develop an OKR framework that will allow OKRs to be recorded in Rally. That would be a win-win situation because there would be changes for Rally Software because there are other tools that are attempting to provide, the OKR option, and the tool to this Rally integration is difficult. Rally will be more successful if they can enable the OKR capturing or recording process. We want Rally to generate OKRs, to allow teams to record the OKRs, and then the OKRs can be mapped to the epics and there is organizational alignment. The organization can execute those objectives using the team's backlog.
Implementation Consultant at a healthcare company with 201-500 employees
Consultant
2021-05-03T19:47:01Z
May 3, 2021
What I don't like about it is that it is really hard to find old work to reference information and use the reporting section of the application in terms of trying to analyze trends. If I am trying to find out which interfaces took this long and I want to compare and measure improvement from one quarter to another quarter, the reporting mechanism within Rally is very troublesome. They have an Excel plugin that you're supposed to use, but you literally have to pull the raw data out before you can do the analysis. You can't do it within Rally, and if you can, it is a secret, and I don't know how to do it. It should have better, easier, and user-friendly reporting without having to use the Excel add-in. It is very clunky. There is a lot of data in there, but it is not organized in such a way that makes it intuitive. You really have to kind of look for where do you put your documentation or dates. Some customization is available, but it is not plug-and-play like Jira. When I switched from TFS to Jira, I just went and started using Jira, whereas with Rally, you kind of have to really get in and figure out what you need to do before you set stuff up, or you're going to get yourself stuck. You can just start using Jira and be successful.
Senior Manager - Business Intelligence at a healthcare company with 10,001+ employees
Real User
2021-02-08T10:58:10Z
Feb 8, 2021
The scalability may need to be improved. We'll see within the next three to six months, as we test it. The product needs to have more integration capabilities.
One problem I see is that if there is a dependent user story - for example, if my team is working on one thing and there is a dependent user story from another team - we can have a dependency created but we don't know if there is a change of status from the other team. That is something which is very important for Agile Central to look into so that if the other team makes any changes we will be notified as well. As of now, we get an email alert but that's not sufficient. We can overlook it. What I'm suggesting is that they have something which populates on the team level so Team One and Team Two can communicate on dependent user stories. That would be really helpful. In addition, reports are confined to teams. For example, I have five to six teams under me, if I have to pull a report, it will be mapped to a single team. I have to pull five teams' reports and then consolidate them to see what the metrics are. I don't have an option to actually add multiple teams to one report. Finally, it's not capable of some things such as CI/CD. Agile Central is still not there. For CI/CD you need a separate tool and a separate repository called a GitLab. Then you need to run that through a continuous integration called Jenkins. I want to see a holistic approach when you're going with DevOps. There should be just one enterprise tool which is capable of all these things. As of now, Agile Central is just a test management tool.
Scrum Master for a Big International Bank in Belgium at a financial services firm with 5,001-10,000 employees
Real User
2019-01-08T10:53:00Z
Jan 8, 2019
I think there is a missing link with the development activity. Some developers are pushing in new versions of the code, but you cannot make the link from the user story to a specific application version.
Not as user friendly as VersionOne. At first I liked VersionOne better and was very disappointed in the switch. However, after a month or so I was quite happy with CA Agile.
What I have learned is that a lot of features that I am looking for, in many cases, are part of a different tool set that CA offers. Really it is more learning about which features and tool, those features would be in. A lot of the features that we would be looking to add, I am learning may not be within Agile Central, but part of another CA tool set. It is about learning which tool that would be and how to integrate it. It would be nice if CA had those tools as part of a package rather than having to try and find multiple tools to integrate together. Some of the additional features that we are looking at would be better roadmapping capabilities and increased robustness around permissions. More of a view into the overall lifecycle of the portfolio items, so post acceptance of a story through the pipeline. Those are some of the key things that I would like to see.
With Rally Software, you can plan, prioritize, manage, track, and continuously improve your work so that you can deliver the value that your customers need with speed, quality, and efficiency. Our enterprise-class Application Lifecycle Management (ALM) SaaS platform provides visibility into progress, roadblocks, and dependencies across multiple teams, projects, and programs. This allows you to align to your strategic goals and create better business results, and...
The product itself seems to have a lot of bugs. One issue is that it sometimes allows people to modify data inappropriately. For example, team members can change numbers at will. While we have a mechanism to track changes, people can still alter numbers, create or delete tasks, and create or delete high-level activities without proper controls. This causes problems when we try to generate reports, as we may not get an accurate picture at a specific time. Certain activities should be subject to more managerial control. We have some control, but team members have too much discretion in creating and modifying tasks. They might put in unrealistic numbers for how long an activity will take. Sometimes, they change numbers during meetings and then change them again afterwards. I suggest implementing a better locking mechanism and improving the security aspects of the tool. Currently, if I create a task, someone else can open it and make changes. This can cause issues when multiple team members are working on different tasks. What we need is a system where only the owner of a task can modify it. If a task needs to be split between two people, it should be possible to break it down and assign parts to different members. But the access control needs to be more vigilant.
The interface isn't very good. The integration with other tools is quite complex to understand, and the reporting wasn't great. At least for me as a QA, the test coverage and test management on a release basis weren't ideal. I like visualization that gives me a clear picture rather than going through numbers. Octane gives me the flexibility to customize my reports and provides me with a different set of reports that are helpful for me to find or analyze project details. It also has some because we have integrated our Jenkins pipeline into Octane, and we have the option to trigger automatic reports to the organization. So it has us reporting as well. We have had a lot of issues using it.
It is hard to track the changes. For example, we're in sprint 25, and then we have 26, 27, 28, and 29. Throughout that whole time, we're developing pipelines in Azure, moving to GitHub, creating pipelines, and working with teams. But sometimes, we need to revisit specific decisions made in previous sprints, like pipeline details. Maybe it's in our Azure Wiki, GitHub, or Teams, but it's not always consistent. I wish I could search for all tasks or stories related to that particular effort without needing to know everyone's individual stories or features. So, I would like to see a tag system with prefixes like KBI for knowledge-based information or JC for Java Core to search and find relevant items easily. It would be so much easier to search for everything related to KBI or the actual feature itself. I could even search within my group using a shared scrum team name, like "Snoopy's Developers," and then find everything related to JC or Java code. Another pain point for us is managing our limited number of licenses with contractors coming and going. It's a constant struggle to figure out who's still active. We have to run reports to find people who haven't used Rally for x months, like logged in or whatever. As an admin, wouldn't it be great if we could have an automated report emailed to someone, say another admin, highlighting users who haven't logged in for, like 12 months? That way, we could easily go in and deactivate or revoke the licenses. If someone hasn't logged in for eight months, why not have Rally automatically disable them? So, easier license tracking would definitely be beneficial. Those are my two main wish-list items. With the Description field, it can work for them; it's free. But they have to be diligent enough to remember to tag things there. And even then, it's not always clear during stand-ups unless you specifically look at it. Someone is working on "admin" or "accessories" or whatever that "digital transformation" tag is. That kind of thing helps track progress at a glance.
I don't have any specific suggestions for improvement regarding the solution because we are currently satisfied with all aspects. Our usage requirements are relatively straightforward, and we haven't encountered any significant challenges or complexities. Therefore, I don't have any valuable suggestions to provide at this time. I hear from some people that it could be customized, but they don't have details on how. Customization is possibly a desirable feature, and I don't know if it is available in the system. Customization features may not be exposed or unavailable, so people may be looking for them. So, customization is an area people have told me is more desirable.
Rally Software is highly complex, and it takes some effort to get everything tied together. But once you do, it's a satisfying experience, and the result looks beautiful. Azure, ServiceNow, and Jira do not have all the features that Rally Software provides in one place, making it an exceptional tool for project management. It was either Optum or Rally Software that had a significant number of connections and workflows that were challenging to comprehend. As a result, the visualization was lacking, which was frustrating. One feature of Jira that I admire is the ability to view the workflows for user stories, for instance, by going into the user story settings for my team. You can see where the story is heading and what the workflows are. Unfortunately, Rally Software does not offer this visual representation, although it does have all the connections. However, to utilize it correctly, you must be aware of how to set it up correctly, and Rally Software could do a better job of splitting up workflows.
The big problem with Rally Software is migration. If I were to migrate from Microsoft Azure DevOps to Rally Software, it would require more effort because in Microsoft Azure DevOps, every time you create a project, you have Git for each project you create. My current company has the pipeline and virtual machine for compiling code in the project, so if I migrate that, it would mean that I have to put in extra effort to evaluate the pipeline in Rally Software, so that's a big problem for me. In Rally Software, the connection with GitLab and GitHub needs improvement because every time I evaluate Rally Software, there's an issue. When I have a lot of team members and push the code in Git, I track the requirement and the code. Rally Software needs to improve in that area because I'm a person who understands the requirement. However, I still have to evaluate the code, virtual machine, and pipeline despite my knowledge. I don't have this problem with Microsoft Azure DevOps, only with Rally Software, so this is an area for improvement. In future releases of Rally Software, I want it to have GitHub and GitLab connectors. If it has existing connectors, then the connectors should be better.
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.
Rally has the ability to improve the features. We would like to see progress made against the features, probably in the form of a dashboard, where when teams complete stories, the features upload, and the stories are completed, and the feature about them gets updated with the progress. This is available in Jira but not in Rally. That's something I would like to see because the management wants to see how far we have come with the epics and the features. They want a dashboard that would allow Rally to provide a picture to the leadership of the progress made on the epics and features. There should also be an automation feature. When the last story in the feature is finished, the feature's status should be automatically updated. The user interface can be improved. I still don't think the UI is as impressive as Azure DevOps or Jira. The performance can still be improved. Rally Software should develop an OKR framework that will allow OKRs to be recorded in Rally. That would be a win-win situation because there would be changes for Rally Software because there are other tools that are attempting to provide, the OKR option, and the tool to this Rally integration is difficult. Rally will be more successful if they can enable the OKR capturing or recording process. We want Rally to generate OKRs, to allow teams to record the OKRs, and then the OKRs can be mapped to the epics and there is organizational alignment. The organization can execute those objectives using the team's backlog.
What I don't like about it is that it is really hard to find old work to reference information and use the reporting section of the application in terms of trying to analyze trends. If I am trying to find out which interfaces took this long and I want to compare and measure improvement from one quarter to another quarter, the reporting mechanism within Rally is very troublesome. They have an Excel plugin that you're supposed to use, but you literally have to pull the raw data out before you can do the analysis. You can't do it within Rally, and if you can, it is a secret, and I don't know how to do it. It should have better, easier, and user-friendly reporting without having to use the Excel add-in. It is very clunky. There is a lot of data in there, but it is not organized in such a way that makes it intuitive. You really have to kind of look for where do you put your documentation or dates. Some customization is available, but it is not plug-and-play like Jira. When I switched from TFS to Jira, I just went and started using Jira, whereas with Rally, you kind of have to really get in and figure out what you need to do before you set stuff up, or you're going to get yourself stuck. You can just start using Jira and be successful.
The scalability may need to be improved. We'll see within the next three to six months, as we test it. The product needs to have more integration capabilities.
One problem I see is that if there is a dependent user story - for example, if my team is working on one thing and there is a dependent user story from another team - we can have a dependency created but we don't know if there is a change of status from the other team. That is something which is very important for Agile Central to look into so that if the other team makes any changes we will be notified as well. As of now, we get an email alert but that's not sufficient. We can overlook it. What I'm suggesting is that they have something which populates on the team level so Team One and Team Two can communicate on dependent user stories. That would be really helpful. In addition, reports are confined to teams. For example, I have five to six teams under me, if I have to pull a report, it will be mapped to a single team. I have to pull five teams' reports and then consolidate them to see what the metrics are. I don't have an option to actually add multiple teams to one report. Finally, it's not capable of some things such as CI/CD. Agile Central is still not there. For CI/CD you need a separate tool and a separate repository called a GitLab. Then you need to run that through a continuous integration called Jenkins. I want to see a holistic approach when you're going with DevOps. There should be just one enterprise tool which is capable of all these things. As of now, Agile Central is just a test management tool.
I think there is a missing link with the development activity. Some developers are pushing in new versions of the code, but you cannot make the link from the user story to a specific application version.
CA Agile Central does not have a workflow tool included. If possible, it may be necessary for some companies that this type of feature be included.
Not as user friendly as VersionOne. At first I liked VersionOne better and was very disappointed in the switch. However, after a month or so I was quite happy with CA Agile.
What I have learned is that a lot of features that I am looking for, in many cases, are part of a different tool set that CA offers. Really it is more learning about which features and tool, those features would be in. A lot of the features that we would be looking to add, I am learning may not be within Agile Central, but part of another CA tool set. It is about learning which tool that would be and how to integrate it. It would be nice if CA had those tools as part of a package rather than having to try and find multiple tools to integrate together. Some of the additional features that we are looking at would be better roadmapping capabilities and increased robustness around permissions. More of a view into the overall lifecycle of the portfolio items, so post acceptance of a story through the pipeline. Those are some of the key things that I would like to see.