Rally Software Reviews

It's mainly about test cases and automation of data. I, as a test automation architect, collect all that data and show the metrics.

We were using Quality Center, Application Lifecycle Management, from Micro Focus. That is hosted on an Oracle Database, whereas Agile Central is completely built on web services. If I have to create some metrics, I can do it via simple web services. Web services can be used to pull the metrics and this is much faster. I don't have to write SQL queries to do so. It definitely saves time, perhaps something like 30 percent.

Also, if I had to track multiple teams in Quality Center, I needed to go through different containers. With this solution, I can just add all of them and see them together.

Also, the data is more granular when it comes to tasks, iterations, sprints, and releases.

Some of the services are open so that we can plug in some other tools as well. If I need to do some metrics I can use those services and a simple "get" request from them.

Reporting is much easier and faster than Micro Focus ALM, with CA AC built on web services.

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.

The stability is good. I haven't faced any problems up until now. It has never hung. The Quality Center tool would hang. It has some client installation components but Agile Central is all on the server side. So it is much faster.

The scalability is definitely good because for a company like ours, with a huge amount of data month over month and year over year - with every release the data piles up. We are not going to delete any of the historical data. So far the scalability is good.

I have not contacted technical support.

But there is a voting option available for customizations. If I need an additional field or something needs to be enabled, if more than 60 percent of users vote for it, the CA team will enable that. They have responded well to these types of requests so far.

We were using Quality Center, Application Lifecycle Management. The reason for the switch is a decision taken by our leadership team and I don't have any insights into it. Perhaps it was licensing cost.

If you compare Quality Center vs Agile Central, the latter is much better.

It has helped save time, especially when it comes to testing. Uploading a bulk of test cases is much faster. And if the leadership team wants to get any insight from the metrics, pulling in metrics is not so difficult. That is something which I, personally, feel is great when compared with our previous tool, Quality Center.

This solution will be of benefit to somebody who has knowledge of and understands web services, as it is built on web services - Representational State Transfer (REST). 

In our organization, we have about 400-plus users of Agile Central. It is used by the development managers, QA managers, architects, delivery managers, and scrum masters. These are all stakeholders in it.

Across our organization, everyone, including the development team, is following the Agile methodology. We are yet to get into DevOps. Agile Central is the tool which even other departments, like testing, are using.

Overall, I would rate Agile Central as an eight out of ten because of its performance. It doesn't get a ten because of the dependency issue which they need to resolve. And, on the whole, the tool needs to have more of a holistic approach for everything, such as CI/CD and a test management tool. As of now, it is still confined to being only a test management tool.

• Logging user stories
• Listing tasks
• Estimating and tracking work in progress (WIP) for each project

These features are most valuable to me because they are useful for my job functions. I’m a software developer and I use these features more than any other features of this tool.

It helps us to track work in progress for each project and for each user story. We can also learn project details from a high level.

The search feature may need some improvements. Sometimes it is hard to pull a specific user story just by adding the user story number. It is not straightforward to search for a specific user story using its ID number.

My suggestion would be to add a search button. In this way, the user could search for a specific user story based on a given user story ID number, or on the user story description.

I don’t think that I’ve seen this option. Even if it is there already, it is not intuitive to the end user.

I have used this solution for around two and a half years.

There were no stability issues. However, I have not used this tool extensively enough to comment on this topic.

There were no scalability issues. However, I have not used this tool extensively enough to comment on this topic.

Initially, we were using an internal tool within our company.

• Sprint tracking + Kanban board (Iteration Status app): Informs me how well we are doing in our sprint, and what is the next part to work on.
• Burn-down graph.
• List of stories sorted in priority order.
• Kanban Board to visualize work in progress.
• Sprint planning (Iteration Planning app): Helps me draft plans based on my team’s velocity, and visualize my team’s roadmap for feedback on my team’s priorities for the upcoming sprints (user story level).
• Team sprint capacity management (Team Status app): Useful app to elicit the conversation of how much capacity does each team member have for the upcoming sprint, and calculate whether we are stretching our team members too thin. In addition, we can easily trade tasks from one user to another, as needed.
• Release planning (Release Planning app): Helps me draft plans based on my team’s velocity and visualize my team’s roadmap for feedback on my team’s priorities for the upcoming months or quarters (feature level).
• Portfolio hierarchy (Portfolio Items app): Allows me to define the epic, feature, story breakdown of my team’s work. Also, it allows me to visualize the dependencies between teams.

It provides teams the ability to define, prioritize, and monitor the progress of both their operational and project work. The big win is the fact that we are using the same tool outside of IT. It’s a huge win when your internal customers are also using the same platform for defining, tracking, monitoring progress on their objectives. The non-IT departments that have teams using the tool are marketing, operations, training, and human resources.

Provides portfolio, department, and program managers the ability to define, prioritize, and monitor progress on larger initiatives being delivered by multiple teams.

Make it easier to export information outside the tool for additional data visualizations and metrics. The tool does have a REST API, but that requires us to use a developer. The tool does have CSV exports for everything, but that’s a manual step.

Make it easier to share CA Agile Central information to non-CA Agile Central users. Not everyone in our organization is a licensed CA Agile Central user. Those users who are not licensed and provide work to the users on our platform, have a hard time tracking their work requests.

Provide the ability for team members to customize their custom fields/custom workflows without needing a tool administrator to set it up for them.

Mobile friendliness: It would be nice if we had the ability to view and change the state on assigned tasks from a phone.

CA Agile Central integration is great! Currently, everyone who has an CA Agile Central license has a Flowdock license. Unfortunately, it costs a lot of money to add non-CA Agile Central users to Flowdock. And a messaging platform is useless if you can’t message all your stakeholders within the organization.

There is no ability to easily create a work intake portal where a stakeholder can enter new work, have it routed to the appropriate team, and be able to track the work status. You can buy an integration engine that syncs your ticketing system with CA Agile Central, but again, that’s more money.

I’ve used CA Agile Central for four years.

Once in a while, it has performance problems. Nothing terrible and nothing we have not seen with other SaaS vendors.

We have not had any issues with scalability.

Technical support is fine. They assign a customer success coach that we use for tools training and tips. We are pretty self-sufficient now that we do not have to lean on them very often.

We did have other tools before CA Agile Central and we currently still use other vendors for managing other types of work. The best tool for the job really depends on the type of work you do, the work management methodology the team uses to get work done, and who the team’s stakeholders are.

Setup was easy for team-level usage. It gets more complex as you try to scale up your agile practice. Scaling up only happens when teams agree to portfolio standards such as your work hierarchy and planning cadence.

It is an expensive tool. Bring in a good negotiator. The money is worth it when you are trying to do agile at scale.

We evaluated:

• VersionOne
• JIRA
• Trello
• Smartsheet
• Taiga.io
• Tuleap

The nirvana for all organizations is to implement end-to-end enterprise business agility. It’s a lot easier to do that when you have a tool that allows you to capture all the data you need and systemically roll that up for your enterprise portfolio reporting. CA Agile Central is a tool that enables you to do that. BUT, in order for data to be entered consistently, you really do need an enterprise coach. If you are not implementing agile at scale, I would recommend a cheaper tool that is also mobile-friendly. CA Agile Central is a tool that solves the agile-at-scale challenge, and is still user friendly enough to handle non-IT work loads.

The features I view as most beneficial are:

• The ability to search at different levels and views
• Having tabs in an opened user story so that one can jump to a tab and check the details without leaving the user story
• Being able to sort on any element in the column headers
• Being able to add new elements to a page type
• Being able to move user stories to different sprints or backlogs easily
• Being able to add content or select a different drop down and have it saved automatically while still working on a user story
• Being able to get to help-rich tool pages and videos
• Having a community for this tool
• Having a dashboard that can be customized to a user
• Being able to write program code to generate a unique report
• Being able to click on maintenance wheel thumbnails to do such things as delete a particular attachment
• Having tool level tabs to select a different view page in the drop-down
• Being able to “split” a user story for tasks that have not been completed

That is just a starter list.

When there are disparate locations in cross-area teams, it is difficult to locate all of the documentation that one needs.

Having the CA Agile Central tool allows for there to be one place that contains all the information on teams and sprint by having features to add and update notes, attachments, and data element values to user stories and tasks.

This encourages team members to make updates as a way for others to learn the challenges and developments that are occurring during sprints and to communicate statuses on where we are now regarding tasks that are in-progress or completed.

I think that the product use of the user-story-split feature that creates child user stories can be abused by users for being so easy to do. It will require one to drill down to the grandchild, or great-grandchild, etc., to see the progression or what happened before now.

Also, it will look messy when seeing a list of nested user stories. Using this feature, a waterfall view is being promoted. Instead, having predecessors and successors as part of the split will allow us to track this “legacy” user story better, which should have been created as smaller user stories to begin with.

In a sense, completion of a user story in a sprint would have been reinforced by not seeing parent and children. Predecessor user stories would not contain unfinished tasks.

I have been using CA Agile Central for one year.

We haven’t had any stability issues, but at times there are IE browser stalls for those who use IE in meeting presentations. I, for one, use Firefox as my browser, so I do not experience issues.

I have not had scalability issues at all.

I have not had a chance to work with technical support yet.

I have not used a different tool, because we did not have one.

Setup was done on my behalf, so I cannot comment.

I think that there is a trial period for this tool, so I would say to try it. However, some training is needed first.

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.

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.

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.

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.