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.

The most valuable feature is that it follows the agile methodology more than ALM or JIRA. However, I know companies using more than one tool, separating test management and requirements, which I agree to.

Currently, I would prefer to use QAComplete by SmartBear to track test cases, since CA Agile Central doesn’t work well with reporting on that level or for that matter on any level.

One of the jobs that I adopted was to design procedures using CA Agile Central. In the beginning, without a procedure (not sure if the online help has much “method” suggestions, which it should), it does allow the agile process to be followed easily from features > user stories > team capacity > sprint sizing > test management and defect management. If properly used, it can be an amazing tool relaying to scrum masters, project managers and for all management levels to show exactly how a sprint is going. I will say the CA Agile Central Excel plugin is great for real-time extraction of data, i.e., if you know how to use it correctly, and out-of-the-box you will not know the hidden tricks that I have learned. But, CA Agile Central Support is actually very good.

On the test case level, I feel there are a couple fields missing, i.e., I cannot easily create a day-over-day report. I cannot find out what is planned for the QA team, as I cannot track what is “ready”, or as to the day when it’s planned to execute.

I have been using this solution for one and a half years now.

No outages have yet been experienced.

There are always latency issues when accessing anything in CA Agile Central Portfolio Manager; it takes a good 10 seconds to load. This isn’t only due to concurrent users, it can be the case at 1 AM when no one is on. It hasn’t been that much of a nuisance.

I would rate the technical support a 10/10. The funny thing is that I didn’t care much for the CA Online Support. I didn’t know there was a ticket support system. However, once I did, my goodness they were great in returning answers.

We did previously use HPE ALM. HPE ALM didn’t produce much of good reporting, yet neither does CA Agile Central. Plus, the agile process was all wrapped up in CA Agile Central, so we decided in our department not to maintain two tools. Other departments and UHG do use both tools, and some HPE ALM still.

The setup was very simple; it was probably easier than HPE ALM.

One major problem when obtaining CA Agile Central is ensuring the framework is exactly what you want. Many don’t look at this aspect and later realize that they have lost traceability and that they should have created a dropdown menu instead of free text (i.e., there is a defect found in the free text field – this should be a code drop version, adaptable by iteration). Yet, I’m still not sure at the moment what is and what isn’t adjustable since I’m not an admin. However, from what I did hear is, when something changes, it may change the enterprise and not just the project; not sure about that yet though.

Count the cost! Find out what you have in place and how much longer you are charged for and then compare this to your budget. I find it a big waste in having too many tools, but it really matters as to what you want to see and how much you want to maintain. For example: With the SOP that I created for using CA Agile Central, I can create almost perfect reports from Excel. However, the problem here lies in Excel! You need manual intervention to formulate and macro out the data, thus involving more costs.

Only afterwards did I evaluate other options, since I was not a decision-maker; they already owned HPE ALM and CA Agile. SmartBear QAComplete is a great tool and probably my number 1 choice, i.e., if I had the choice. It also works with SoapUI, XML, Selenium and manual scripts.

I would consider it highly. Be sure what you want to accomplish; it’s not reporting-friendly. It is good with team burndown and sizing.

Although, it’s agile-based, it’s not like HPE ALM that informs you via emails when something changes, i.e., even if you enable notifications, it’s fluky, as you get more emails than needed. CA Agile Central has a dashboard per user feature, as to when logged in that must be viewed.

The key thing is process! You must know how it works and how you want to use it, before you implement it. To be honest, there is only one way to use it that I have identified above.

The portfolio manager add-in is very valuable for our company, because it allows our business partners to create their road maps, and then link their road map to their user stories, that our engineering teams then work on. They can roll up the progress and see that at the portfolio hierarchy level. That's a very powerful aspect to the tool.

Also, all of their reporting, the dashboards, the custom apps, everything that you can create within the tool, makes it very powerful for us as an organization, as well.

The benefits of the solution are the collaboration and transparency. We encourage everyone across the organization to have an ID and to log in to the tool – daily or weekly, whatever their needs are – to see the data. They log in to the tool to see the real-time data. We have really pushed back on teams that would still want to do external reporting, where the data is old and stagnant. I would say that real-time transparency is one of the most valuable aspects for us.

One of our main challenges right now is that we have not deployed our value streams yet. We still have an organizational hierarchy within the tool. We have the need to be able to report from different levels of the hierarchy. We really need to be able to have a virtual project hierarchy within the tool. I'm looking forward to seeing it. I know that the company's working on a slightly different approach to solve that issue, and we're working with them on those user needs and we'll be working with them on the beta as well.

We're on the SaaS platform; it is very stable. One of my favorite things about being on SaaS is that, when there's an issue, I don't have to panic and try to work internally with a support team to try to bring the tool back up. I reach out to my technical account manager, she gives me updates, and it's usually back up, relatively quickly.

I love technical support. They have a personal touch. When you start to work with someone, they stay on your case. Even if it's a long-term case, you get to stick with that person that knows what you're working on. I've been working with someone for months on a rollout of a new piece of functionality and he's stuck with me the whole time; he'll check in with me. I would say that that's a very valuable aspect.

I was talking to someone at a recent CA conference. They don't use Agile Central yet and she asked me, "What should we do?" I told them that they should take advantage of CA’s transformation consulting group, to come in and provide that entire solution from start to finish, so they don't get stuck like we did and not having their value streams identified, not having the tool set up and the best way to make them effective.

It's a partial solution. It's a big problem for us right now.

Most valuable to us is being able to communicate without everybody having to be in the same room. Also the ability to capture information and distribute it to team members. We have people overseas or people working from home or in a different office building and they can all communicate via Agile Central.

I think it is an excellent tool for tracking agile scrum activities. It's one of the best tools on the market, if not the best.

Primarily, it has given us a more structured approach than doing some kind of scrum using white boards and other manual methods. It's a very helpful tool. The push for Agile Central came when we asked the company to go agile and do scrum. This required us to go ahead and purchase a tool to unify us across the company.

My personal agile maturity is about medium. Company-wide, some facets are medium to high and others are just starting. Our scrum masters also use it for coaching. Some of the best practices we use are keeping the tool updates timely and making sure stories are well defined and broken down in the right unit of work.

I would like to see greater ability to manage common teams that are working across projects and how that common team has tasks to do in both projects or in multiple other projects. I want to see more common services.

The project might require common services, but if I'm a common services team and I have tasks in all of these other projects, it’s better to manage the common services team itself and their tasks; because they have tasks in multiple other Agile Central projects.

As far as I can tell, it has good stability.

I can't comment about scalability.

I have not used technical support personally. I haven't had to, so that's good.

I was not involved in the initial setup.

I know of some people that were trying to use JIRA, but I don't believe that had near the capabilities that this does.

I would advise potential users to get in touch with CA and have a representative sit down and show them the tool and how they can use it.

We use it at the enterprise level, from the leadership to managers to teams, and everyone can use the same software easily.

It's very user friendly and intuitive as the information can be viewed and customized easily.

It's the first software that allows everyone to use the same software that is actually user friendly.

An improvement would be if at the leadership level, they want to view certain teams, it’s easy to break down. For example, if a portfolio is 60 teams, as a director, I can filter and easily see only my teams and the stats I want.

Also, the defect-management cycle needs work. It's already there, but the functionality isn't all the way through.

It could offer more functionality and spread those functionalities to individual users in a way they can understand. That would make it more intuitive, but I understand that doing so is a challenge.

We've been using it for over five years.

We haven’t had any stability issues.

It’s meant for scaling and that’s the top functionality.

They were great. Never any issues.

It was already in place when I joined.

I've performed installations in other organizations, and it was very intuitive.

We also looked at products that have good scalability because of the size of our enterprise.

My advice would be to use it. As with any tool it has advantages and disadvantages.

When we started to go to the agile model from the waterfall one, it was a big challenge for us. We had couple of folks move from Paypal to us, and they gave us a success story in a meeting. When they were looking at tools, they came across Rally, and it was introduced to us by the CA team. We had a couple of training sessions on Rally.

The immediate impact of that was when we started using Rally, we didn't even know that we could do agile. But because of Rally, we were able to track all the users' codices, track all the features, track the capacity so that we could plan, and find out as a team what the capacity is as a team to deliver in a two-week sprint.

As an application developer, I can speak only based on what the developer and app teams can do, and this has helped a lot. We were trying to go strictly agile, and I think Rally is helping us big time.

When we started using Rally, we used the user interface pretty often. It was very informative and everyone was comfortable with it. But there were challenges with product backlog and how to track the capacity planning. Everyday you needed to update the status. There were a couple of questions about, what is the capacity of every developer or a QA engineer for this sprint.

It has been stable for us.

As far as I know, there are 16-17 people using it, and since I'm relatively new with the company, I'm not sure what the plans are in terms of scaling its use.

I haven't used Rally technical support yet, but we have a 1-year subscription.

It was straightforward. We didn't have to do a lot. We just went to Rally 101 training, and there was some agile coach for us on site. She trained us on how to use the Rally tool to update our social studies tasks.

I would say Rally is the way to go.

Most of our development teams are Agile, meaning they do development in two-week sprints. So they use Agile Central for the input of all of their user stories, all of their test cases. We just recently moved to Planview Enterprise so that we can actually start doing dependency mapping across features. 

But it's mainly a way for all of the individual teams to define all our user stories and keep up with the overall tracking of how they're doing, sprint by sprint. 

It's a good platform to keep track of all the user stories across all projects. So rather than having one off Excel spreadsheets with all of the requirements, it is a good place to have all of that. 

I think where we as an organization can get better - and this may be something that is out there in the functionality now, and we're just not using it - is better mapping across projects and having that cross-project dependency mapping.

It's good, you don't have everybody in separate emails and Excel spreadsheets with all their various stuff and requirements, but we're still filing within the projects and not keeping track of everything across.

The main ways that I used it when I was in it day to day was keeping up with the burn rate within the teams. Also, to track at the feature level too, as far as how we were doing with actually being able to deliver that feature. So a lot of the in app features, where you can set up your dashboard; that's where I used it a lot.

I don't know that I can answer this, because I'm not using it day to day. I'm using CA PPM now, and I know we're looking to integrate Agile Central into CA PPM, which I believe is an option. 

When I used it before I would say the stronger CA can get on dependency mapping the better. That's the biggest hiccup. As you're setting up your features, they should make it easier to flag the dependencies, either across features or across projects. Then you're more set up for success.

I think it's been fine. We used Agile Central when it was Rally and we were actually in the beta, the first version, without really having any problems with it being down or not running. I would assume the SLA is somewhere in the 98, 99 percentile. That seems to be the case.

Regarding scalability, I don't know. I only know how we're using it as a company. Like I said, I think there's probably more that we could be doing. We're just not quite there yet.

I haven't had to use tech support, myself. I don't know if the direct teams have. But, like I said, we haven't really had any issues with the tool.

We had a guy who was an Agile coach come work with several of the teams. So we've kind of had onsite support from a coaching perspective; not necessarily the ins and outs of the tool. I think he was able to provide some technical support as needed to get the teams up to speed.

I can't remember what we were using previously. It wasn't JIRA. There were some teams using another user story repository before they started using Rally, now Agile Central.

We decided to move to the Agile development framework. Based on that it was clear that to do so you need a platform for your user stories. And I think it was just one of those next steps in the evolution of moving to the Agile development framework.

We switched because we wanted everybody in the same platform. I'm sure money was somewhat involved, as well.

I wasn't involved in the inital setup from a technical perspective. That happened on our technology side. But I was one of the first ones to use it, five or six years ago.

In terms of it being complex or straightforward to learn, the team that I worked with had training on it. So once we had training on it, it was very easy to understand. I don't know I if you could just come in and use the tool without any training on it.

I think in order to use the tool you have to understand what the Agile development platform is. You have to understand what a user story is. You have to understand how that connects to the test cases. You have to understand the background of why you'd be using the tool before you can use the tool. You couldn't just sit someone down and say, "Go." There has to be a little bit of training on why use the tool before you use the tool.

There hasn't been anything surprising within Agile Central. As CA has taken in Clarity, which is now CA PPM, what I'm learning here at the CA World conference is the full breadth of everything we can do better under the CA umbrella. I don't know if there's anything particularly surprising about Agile Central. There's JIRA. They're all fairly similar. So there's nothing that wowed me there.

When it comes to the most important criteria in selecting vendors, budget always plays into, but I think it's also the breadth of the solution. I think that's one of the reasons we've stuck with CA, because now we're using several of their tools.

I rate Agile Central six to seven out of 10. For it's core functionality, it works. I think when you get into the details, there are some improvements that could be made as far as being able to better track across. There is dependency functionality now that you can use, but I think there are always improvements that can be made. But for it's core functionality, it works.

In terms of advice to a colleague who is researching a similar solution, I think most people who are developing in an Agile way are familiar with it now. I might give some tips on dashboards that I've set up. If you're familiar with Agile you're familiar with Agile Central, really. The tips and tricks that I've given my colleagues are more around how to build out dashboards to be able to see, in that first glance when you walk in, your view for the day. So it would be around the dashboards. 

As a Scrum Master, helping the product group define feature stories, and portfolio management, and helping manage the teams, their scrum backlogs, their performance, and velocity.

It has performed well.

It helps us not to have to use any sticky notes. We project up every day, on a daily standup using the iteration planning part of it, and using the post-it portion of it in the Kanban, to communicate daily with the team on how things are going. 

It helps me to have a dashboard where I can see what things are not being worked on, what things are blocked, for instance. It helps me evaluate teams' historical performance using velocity charts. 

Capacity planning and release planning for the next PI help me figure out what the potential velocity is for each of the teams. It rolls it up, so that across teams we can figure out how many features we think we can get in for the next PI. 

And we've actually used it for virtual PI planning as well. We have teams in different locations, and we actually virtually do PI planning, big-room planning, using the tools so it's been really helpful there.

I like all the features of it, especially the Team Planning board, and the Release Tracking. It helps us track the features and stories that line up with those features. I like it for the most part, and how it works.

I can't think of any off the top of my head.

I have found it to be fairly stable. I know there have been a couple performance issues when we're all on it, but I think that was maybe about six months ago, maybe when we went to the cloud. But since then I haven't experienced any performance issues. I think that's really gone down.

It scales well in terms of setting up the workspaces and the hierarchy, we find that that works really well.

We've used tech support very little. But we're satisfied with the support we've received.

We were using Team Foundation Server (TFS). But some people were using JIRA, so there really wasn't a consistency there. We switched because it was really determined that it was probably the best tool out there to use.

It was actually pretty straightforward, and it did seem more intuitive than what we were using, which was TFS from Microsoft.

When our company is looking for new products, and new vendors, the criteria is more of a consensus, or global acceptance across the board, and executive support. I'm sure price tag comes into play.

I give it an eight out of 10. I tend not to give anything a 9 or a 10, because I always think there is probably room for improvement on it, not that I can't think of anything right now. It's not perfect, but it's definitely very good.

I would tell colleagues looking for a similar solution that Agile Central is very easy to use, and it's easy to build dashboards. It's very intuitive. I'd recommend it.