Rally Software Reviews

Previously, we had an in-house solution that was very difficult to update and customize. Thus, when we had acquired new businesses that we were working with, we weren't able to add the right type of information that we needed or get the right type of support and customers. We weren't recording half of all our new work that was coming in through my team because we couldn't do it. So, when we started using CA Agile Central, those changes could be made in a day or two and we had better data integrity, than my team had ever had before.

Since we went through a series of work changes in the last two years, the most valuable feature is how easy it is to customize it. The ability to customize and change the processes really quickly, so as to respond to what the changes of the organization and processes, were the most helpful.

It takes a very long time to load and, if you make some small changes, then the whole page has to reload. I know that's a major frustration for a lot of people using the tool.

I know that they're constantly updating and providing new features. As I have mentioned elsewhere, I set it up for two different teams. By using it in it's most standard and straightforward route, it is definitely a ten out of ten. However, working at the portfolio feature level, which is what my main team did, there were some functionalities that were missing and over the last two years, I've seen more and more of it come along the way. I would have liked to have the same development support at the portfolio feature level as well, that I was seeing at the user story level.

We are facing some stability issues. This is a pretty regular occurrence, especially when using custom reports.

I've not necessarily put the scalability factor to test yet, but the nice thing is once you have a small handful of people using it, the number of people and information in it has tripled over the last couple of years. So, it was scalable for us in that sense and then, also in terms of the number and diversity of customers, as I mentioned. It's been good in the sense, that we've needed it but I don't think we've really put it to the test.

I had a question when looking into custom scrums and I think, the overall community for CA Agile Central is incredible. Not only does our organization have people here, but there's a wealth of information online as well. When we reached out for technical support via the CA Agile Central team at our organization, when we had some particular requests, they were absolutely incredible. We really liked the tool because it's really easy to learn and there's a really good community.

As I have mentioned eslewhere, we had an in-house solution and before that, it was all managed via Excel spreadsheets. Excel was the worst of it all. The in-house solution was only good enough maybe for the first couple of months, until one or two or more changes came along, that we couldn't afford to keep up with. That's definitely one of the main reasons as to why we switched, since we couldn't keep up with the updates. If we say that CA Agile has stability issues, that again are not poor, but it just takes a while to load, then, our in-house tool was significantly worse.

I thought that the setup was very straightforward, but we also had people on the side of our organization, i.e., a dedicated team, to help get everything set up smoothly. My team intended to change a few things about how you would traditionally use the product. I set it up for two different teams. When I used everything in the straightforward way, it was very easy. When we were modifying and customizing some things for my team, then it got a bit more complicated; just to get my head around the rules and then, having to manipulate them. So, the setup is very easy when the product is being used as it's meant to. When we were manipulating things, it got a little more complex. However, we were able to work through it relatively easily, because of the support that we had.

I evaluated about half a dozen of the other vendors out there and one of them was JIRA, for portfolio management. JIRA was the other top competitor, although we did evaluate other small vendors as well. CA Agile Central was much better. We actually had a relationship on JIRA's side, but I was the first one to venture into the CA side, as we didn't have the relationship in my team. However, CA Agile was just a far more superior product, as compared to what JIRA was able to offer then.

It is important to truly understand it! In order to use it the best way that you can, you really have to understand your process, terminology and the way that CA Agile Central is meant to be used. We had a lot of issues with the terminology; for example, at what level should we be, does this count as a user story, does this count as a feature, etc. So, it is crucial to really do all that work in the beginning and to map out everything meticulously, so as to make sure that the definitions are clear. After that, setting up of the process becomes much easier; but, if there's a lot of back-and-forth in terms of the definition, the setup and adoption will be much more difficult.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.