Rally Software Reviews

It is used to track any enhancements or new integrations. We have integrations from mainframe systems to RESTful services. We also have a few SOAP integrations. Essentially, we use the feature level of Rally to document what the interface is and then the engineers make the user stories within the feature to represent the tasks that they need to do to complete the interface, which includes everything from making the design document to the activities that they do in IIB, such as deploying the code to production. Our version has probably been updated within the last three months.

It is kind of set up for Scrum or Agile, but we sort of use it more in a kind of hybrid way. It does help build accountability because, during stand-up, you have to see what everybody is doing, why certain things are in red, and why someone is not where he or she is supposed to be.

We use the roadmap features, and we're getting better at using dates to use the roadmap so that we can see if we're on target for work. 

What I don't like about it is that it is really hard to find old work to reference information and use the reporting section of the application in terms of trying to analyze trends. If I am trying to find out which interfaces took this long and I want to compare and measure improvement from one quarter to another quarter, the reporting mechanism within Rally is very troublesome. They have an Excel plugin that you're supposed to use, but you literally have to pull the raw data out before you can do the analysis. You can't do it within Rally, and if you can, it is a secret, and I don't know how to do it. It should have better, easier, and user-friendly reporting without having to use the Excel add-in.

It is very clunky. There is a lot of data in there, but it is not organized in such a way that makes it intuitive. You really have to kind of look for where do you put your documentation or dates. Some customization is available, but it is not plug-and-play like Jira. When I switched from TFS to Jira, I just went and started using Jira, whereas with Rally, you kind of have to really get in and figure out what you need to do before you set stuff up, or you're going to get yourself stuck. You can just start using Jira and be successful.

It is kind of hit and miss. Sometimes, it is really reliable. I'm not sure if the delays that we see intermittently when it hangs up are because we've all gone remote now, and there are different people with different types of remote devices. I don't know if they are because of Rally.

Different teams that I've been with in the same organization use different tools. I have used TFS and Jira. I would go back to Jira or TFS in a minute. I don't find Rally good for scaling what we're doing. A good percentage of this part of my organization does use Rally, but I don't find it conducive to building transparency across the organization. We should either have TFS, Jira, or Rally. However, because of the lack of reporting, Rally won't be suitable and scalable for the whole organization. People want to see and measure what teams are able to do, and if they can't do that quickly, senior leadership is not going to be on board. If every team had to dig as much as I have to dig, it is not scalable.

In terms of users, we have implementation consultants, which is kind of a hybrid role between a BA, a PM, and a QA. We also have engineers, application developers, business analysts, managers, project managers, and directors. We have senior leadership, like AVPs, who periodically go in there and look at stuff randomly, but for the most part, it is usually used by managers and frontline staff like myself. About 80% of teams in our business unit are using Rally. My team has 15, but the number is easily more than that.

I have not had to deal with them.

I would advise others to make sure that they have full training in terms of the connection between features, user stories, and epics. They should also fully understand how to configure it in terms of providing visibility across teams that have to work with each other.

I would rate Rally Software a six 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.

Software development and infrastructure.

Sprint planning and overall work management of the stories and the project lifecycle.

Sprint planning is valuable because it keeps our teams all in the same place in terms of where information is stored. We always know what the status of a project is and anybody can see it.

• Ease of use
• Visibility

As a PMO Manager, I need to be able to look and see what the project status at any time without having to go ask somebody or look for a status report. So, I could go there and see exactly what percentage is complete, what the blockers might be, and just see who is assigned to what, so I can look at resourcing.

It has made our company more organized and it is helping us be more true to the agile principle. When I came to the company, we did not have any agile practices in place. So, it has helped us, because it gives us a framework to put the agile practices in place. 

The integrations with the PPM tool and making sure those two work well together. 

Improved engagement with TFS, because we still used TFS for code management. There is an API between the two. I think that the APR could be easier to set up and the API could be a little more fluid in terms of when the code is checked in. It really relates to how a project is updated based on that.

Stability is better. A couple years ago before CA bought it, we had a lot of problems. Now, we do not have as many problems. So, it has been good.

Scalability is getting better. It used to not be as good, but they are adding some features that make it easier to build portfolio items in.

The problem before was that there were just a lot of little bugs where you create a project in one place and it would not continue to exist in another. Also, there were not very good templates or anything. So, they are improving on that. 

I have not really used the technical support.

We did not have a solution when I started. I picked it because I was familiar with it from a previous company. I actually used it for a couple years before that, as well. I just knew we needed something that we could hit the ground running with pretty quickly.

I was involved in the initial setup and subsequent upgrades. 

I am not really sure how it is now to set up. If you are putting into a GreenField brand new product, I do not know how that would work now. Previously, it was just figuring it out on your own.

Upgrading was pretty straightforward, especially if you are used to using any of the agile tools in the agile practices. Once you get used to some of the unique namings for Agile Central, or formerly Rally, it is pretty straightforward. It is a like-for-like, in terms of what you have learned, in terms of being agile in what you learned on what you are doing on a day-to-day basis. 

The vendors on the shortlist would be TFS's Project Management through Microsoft, ServiceNow's Project Management, and JIRA.

Earlier on, we went a little faster and we did not do a full software evaluation. We actually are doing a tools assessment now. We are going to be looking at replacing CA, possibly, because we want to make sure we have the right tools. We want to make sure that they flow between all the different tool sets that we have. 

It has performed well so far. It has improved over the past couple of years.

For any product, do a full software evaluation and make sure you actually test them side-by-side with like-for-like test cases. Then you know exactly what you are getting yourself into. Otherwise, you build out and realize it might not be the right product for you. So, a full software analysis is important.

Most important criteria when selecting a vendor: Initial support is always important. It is always great when you can have a few free hours to have somebody to come in and help you understand the idiosyncrasies of any software, figuring out exactly what the best way is for it to be set up. Otherwise, you are just trying by trial by error. So, that is important. Also, stability is important.

It's designed around Agile, so it has all of the pieces that match up with the process. For us, at the portfolio management level, we can see everything at one glance, all of the projects, where they're at; and, at the iteration level, we’re able to populate the iteration, and view progress reports on it. We've recently moved all of our defect tracking onto it also - it's nice to be able to pull defects right into sprint plans.

• We're using it to manage the training content development we're doing, so it's kind of a one-off case. It's not your typical agile project, but so far it's working well, and we're able to incorporate most of the agile methodology into our processes. We get all of the transparency that comes with the tool; so we have a clear view of what's happening with all of our projects, what state they're in, and where all the pieces are. Blockers stand out, so they're getting more attention. It's become our single location for project information. Although there's been a bit of a learning curve for the team (more around the processes we're using than with complexity in the product), I've had several team members tell me that it's a good product that they enjoy working with.

I'd like to be able to color code timeboxes, so I have an easy visual way to track the success of sprints. Workflow is not a strength, we've cobbled together our own workflows around changes in State and Ownership.

About a year now. What we're doing in CA Agile Central is pretty stable now, although we still tweak our own internal processes from time to time. Still exploring and learning the wonderful world of Agile.

We weren't involved in it.

It's been extremely stable for as long as we've been using it.

I see no problems with scalability. In addition to what we're doing, I know our Services team and Product Development team are using the product, so I expect scaling is not an issue.

Haven't really used it.

Haven't really used it. Which I like.

Spreadsheets and MS Project. CA Agile Central is designed around Agile methodology, so it was a perfect fit for the processes we wanted to put in place. We couldn't do the things we're doing now with the previous products.

I wasn't involved in setting up the product itself. I jumped in after it was already in use.

Wasn't involved.

The decision to use it came from our development team. The whole development team is using it. Our Services team has been using it for years.

If you're focusing on agile, this is the right product to use. It's built around it. I've tried to do things with MS Project and that sort of thing, and you just can't manage it the same way. It's just not built for the same kind of cycle.

It is a well thought-out solution. It's a great centerpiece for Agile methodology. It works.

I like it because I have several projects, and it keeps me on track for each one. So, I can track each iteration of each project, and see where I'm at and where other people are at, visually. I guess maybe the iteration planning and tracking status is the most valuable feature.

It has helped a great deal in the fact that we are able to take small chunks of data and get them actually moved forward end to end. Previously, we had to wait several months before something would actually be available for the end user. This has helped us to break that and to move forward quickly.

I think I'd like to be able to color-code the words more easily, not just the side. You can change the color on the side, but to actually change the font color would be useful.

Currently, I use an HTML color font to change the title of a user's story or something. If, instead of having to put in the HTML version of it, to make it change the color of the font, and I could easily change the color of the fonts, it would be a lot better.

I have been using the solution for two years.

I think occasionally it will slow down, particularly when we have a lot of users on the same project, especially around stand-up time or whatever, because we're spread out across the country, so we usually do it by phone. So when everybody is on the project at the exact same time, it will slow down a little bit.

Also, if I make a change and somebody else makes a change, you can't retain both changes. It doesn't accept both. The first one who finishes, who hits Enter, Save, Done or whatever, will get the change.

Then, it will warn you. It will say, "Do you want to keep your changes or the other person's changes?" But you don't know what they are changing, and they don't know what you're changing!

It slows down a little bit if you have a lot of information in there. It seems to work really well, however.

I like the personalization of the home screen because I may not want to look at everything, i.e., the same things that other people want to look at. So it's nice to be able to personalize my home screen. I have a lot of stuff on my home screen, and it seems to be able to handle it just fine.

We have an administrator, and I've had to have people added back in because they don't go in there and use it, and get suspended. Then they ask, "How come my name's not in here?" So you have to respond: "Because you never use it."

I haven't really had any help from technical support.

We previously used a different solution. We switched to be able to move more quickly to a resolution. Because the industry changes quickly, we can't still be in development stages on a product that needs to be out in the consumer's hands today. That's why we moved on to something like this where we can actually get things out there quicker.

The setup is very straightforward.

I have no input as far as the cost is concerned. That goes further up the chain than me.

I would definitely say it's a very good solution to have for a company, yes.

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

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.