Rally Software Reviews

Managing our development life cycle. In the ways in which we use it, it has been adequate.

We have gotten away from so much paper, which is more dynamic. It allows us to work in a more dynamic fashion and track more of the development lifecycle. 

Essentially, we are replacing TeamTrack. TeamTrack was more of a waterfall type of process and documentation for us. In fact, I have tried to go back and look for some of those old projects and it is not possible to find them. Although with this product, searching for historical information or the evolution of the requirement, detecting conflict between projects has helped a lot.

Better requirements. As the story is developed, there is not so much time devoted to clarification of requirement. It helps us get a better product to production.

It is a more detailed process for a lifecycle. We go from requirements to implementation. I use it with my teams for time management as well, time reporting and management.

We are not on the most current version, so it may have been addressed, I have not really seen the new product yet. 

I would like to see more in the way of capitalization. I spend a lot of time on capitalization. Working out capitalization, it is largely manual work, where it does not have to be. The tool, I think can support it. When it is a story, capitalization in the current version of the solution we are using, occurs at the task level. I would like to see it roll up a little better to the story level, then up to the feature.

I have not had any issues with stability at all.

It requires better scalability for the implementation of the whole suite. We do not use it in that fashion, and visibility is sometimes a problem.

We are housed with our business units and we are a Fortune 200 company, but not all the elements of the business units can always see an aspect of a project or stories. They can't get those stories, which are not necessarily visible. I happen to manage development on a product that has impact across all business units, across all business departments. So, I have to do some housekeeping, and maintenance in trying to broadcast what we are changing about the software to those other units that do not necessarily have the ability to see those changes, or awareness that those changes are happening.

I have not used technical support. I work with a person in-house who liaises with CA.

We underwent a philosophical change, if you will. We consciously chose to move away from waterfall as a development mechanism to more of an agile framework. We are not a traditional agile approach, because of the nature of our business. I would really like to see more flexibility, flexibility in adopting hybrid approaches. 

I did not find it to be complex. I find the methodology to be more complex than the tool.

One of my development teams was one of the first teams to use and embrace it. It was a new team, so it was an easier transition for that team to begin using this product over the other tools that we use.

Have a clear vision of where you want to go, and make sure the elements of the tool accommodate that vision.

Most important criteria when selecting a vendor: 

• Cost
• How well we can adapt the practices of the vendor to have some pretty clear direction on where we want to be, not necessarily how to get there. It has to be a partnership. 

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 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.

There are a couple things that our company found really good. One is that it’s scalable, and a lot of the other products on the market for us don't scale. We have close to 20,000 people using Agile Central. So that was one of the keys. Within the company developers, they all have their preferences. So some like JIRA, while some like Agile Central. But from a backend environment standpoint, Agile Central can actually scale for the whole business.

Agile Central helps in terms of Agile management, especially with our scrum teams. It's designed to be used from an Agile standpoint, so I think the teams that have struggled with it are the ones that aren't really set up for Agile. Agile Central is really founded as an Agile tool, so if you're not doing Agile, the tool doesn't work all that well for you.

Our company is large and we've got a very wide gamut of Agile maturity. We have some teams that are very expert in Agile and we have others that are still Waterfall. It's a 100+ plus year old company, so it runs the full gamut. Personally, I have been using Agile for a couple of years, so I'd say I'm pretty familiar with it at this point.

We've been asking for a couple of things. A big one for us has been on the administrative side. Again, I'm coming from a very large company so these are the things that are, at that scale, very important to us, such as access. How do we get access to people? How do you move a large number of people?

The other big one that we've been requesting for years is the ability to move people between workspaces. For us, that's really important. Every time we've had to do this, we have to get technical support involved and it's just a big pain in the butt. Within Agile Central, each workspace is very independent and one workspace can't talk to another workspace.

We have multiple workspaces set up and when a team wants move from one to the other it's very difficult to do. For instance, with a big organization you're always going to have organizational changes. So you may have set the things up perfectly when you first set it up, but things change. Now when they go and change, since we can't move workspaces easily, the new teams that are together can't collaborate because they're in different workspaces. There's no easy, functional way of doing it.

I also think the UI could use some improvement. I believe they're working on it. Also, it's not the most developer-friendly tool. So while management tends to like it, I don't know if developers are huge fans of it, at least in my business, from what I've seen.

I think stability has been fairly good. I don't know whether to attribute the issues that we've had to Agile Central or to our own network. And we have had issues, but they've been pretty quick to respond and try to come to the root cause of what's going on.

We've had some scalability issues but, to be honest, because it's a SaaS product, I'm not sure if it's a function of our network or Agile Central. Sometimes it's difficult to tell, because we've got a lot of internal networking that we're doing in terms of security, etc., that slows things down. So when we have had complaints about it, a lot of times it may be us that's at fault and not so much Agile Central. But, an important factor in choosing Agile Central was scalability.

We actually offer both JIRA and Agile Central within the company. So we try to somewhat make it a user choice as well. What we typically recommend is that if it's a very small project and it's a quick turnaround, JIRA's probably your best bet. If you have something longer term, Agile Central is probably going to be an easier tool for you to use.

I wasn’t involved in the initial setup.

We didn't evaluate anything other than JIRA and Agile Central.

I think you have to think through how you're going to organize, especially if you have a large company. We've struggled with the structure of our teams and the way they're set up. So that's something you need to consider. And I don't know if they've done a great job of it. They actually call teams “projects”, which is a bit of a naming issue.

You definitely need to have some foresight when you set it up in terms of how that's going to work. You also need to think about how you're going to do workspaces, because there's no functionality there to change it once it's set up. You've got to get that right from the get-go or you're going to have a lot of trouble going forward.

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.

Rally Software is typically used for dealing with all the scrum and agile principles and work orders. It keeps track of whatever workers do in the application development lifecycle before release.

The most valuable features of Rally Software are the executive dashboards, ease of use, and many other features. They have encapsulated everything that a GI can do, such as monitoring, maintaining, and then releasing. It's continuous integration and development. 

I have been using Rally Software for approximately six years.

Rally Software is stable.

The scalability of Rally Software is easy to do.

Our team typically handles all of the support for Rally Software. Only when there are some difficulties is when I come in to give assistance.

We have used Jira and Microsoft Excel previously.

I found Jira and Rally Software similar in functionality.

The initial setup of Rally Software is straightforward. In the beginning, there was more hands-on attention needed but after that, we were in operation.

We are always looking for a discount, if the solution was less expensive it would be a benefit.

My advice to others is when you use Rally Software every day, they must be more hands-on. The employees have to have a level of maturity for gaining knowledge of the software. They need to know what it can do, what it can't do, knowing the ins and outs of the software are important.

I rate Rally Software an eight out of ten.

We primarily use this solution for agile project management. We use it to work on some of the challenges we have, including test management. 

The product has excellent customizable reports. There are some custom lists that are deployed in the recent version as well, which have proven to be useful to our organization.

The solution is very stable. We haven't had any performance issues in that regard.

We have all the features we need. It's a good product in that sense.

The pricing, for the most part, is reasonable.

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.

I've been using the solution for six or seven years or so. It's been a while.

The stability of the solution has been very good so far. We haven't dealt with bugs or glitches. It doesn't crash or freeze. It's very reliable.

I can't really comment on scalability. It seems to be suitable for our needs, however, we haven't tried to scale the product and therefore wouldn't really be able to comment on its capabilities.

We do plan to potentially scale in the next three to six months. At that point, we'll have a better sense of how it will handle an expansion.

I'm not sure how many users are actually on the solution at this time.

I, unfortunately, did not handle the initial setup of the product. Therefore, it would be hard for me to comment on if it was complex or straightforward. I don't have any direct knowledge.

The pricing of the solution is okay. It's reasonable. However, the licensing does increase according to the number of modules. Therefore, it can get expensive.

We are currently using the latest version of the solution right now.

I would rate the solution at a ten out of ten. We've been largely very pleased with its capabilities.