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.

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.

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.

As a requirements engineer, most valuable is user story writing/editing/reviewing with peers.

It is supposed to shorten the project’s lifecycle. I do not have proof of this.

The text editor is for sure an area with room for improvement. Under IE 11, the Backspace key is not functioning as expected; it deletes and also inserts empty rows. If you continue, you end up with a lot of empty rows that you do not want. The DEL key, as well. Formatting is difficult.

A CR (carriage return) always creates a new paragraph. But sometimes you just want to stress something in relation to previous statement, but you do not want it in a new paragraph.

Pasting text from Word can create a lot of formatting issues, mostly in cases when the font is not recognized. Also, features such as graphics and tables are supported but only if coming from Word. So, if you want to eliminate a column or a row, you need to go back into Word, make the update, and then past back in the editor. In fact, if you want to come back to a text and edit it, it is very difficult to maintain the initial format.

These issues slowed down my work.

My comments are meant to help improve the product, not criticize it.

I have used Agile Central for five years.

We have not had stability issues.

We have not had scalability issues.

Technical support is very good.

This is our first solution for agile projects.

Setup was somehow difficult until all folders had been created and the rules on how to use them were set up. This has nothing to do with the product itself.

I had no involvement in this, so no advice.

It was a company decision. I just adopted the company decision.

Be very clear in agile and then “map” your knowledge into the product setup.

The most valuable feature of this solution is the Kanban board. The team board that you can see, and enables you to capture the working agreements as well as the date and stage. Because that feature is not available in Jira, I found it useful. In terms of metrics, Rally assists you with capture, allowing you to better understand cycle time and lead time metrics. Those are the features of Rally that I really enjoy.

Rally has the ability to improve the features. We would like to see progress made against the features, probably in the form of a dashboard, where when teams complete stories, the features upload, and the stories are completed, and the feature about them gets updated with the progress. This is available in Jira but not in Rally.

That's something I would like to see because the management wants to see how far we have come with the epics and the features. They want a dashboard that would allow Rally to provide a picture to the leadership of the progress made on the epics and features.

There should also be an automation feature. When the last story in the feature is finished, the feature's status should be automatically updated.

The user interface can be improved. I still don't think the UI is as impressive as Azure DevOps or Jira.

The performance can still be improved.

Rally Software should develop an OKR framework that will allow OKRs to be recorded in Rally. That would be a win-win situation because there would be changes for Rally Software because there are other tools that are attempting to provide, the OKR option, and the tool to this Rally integration is difficult. Rally will be more successful if they can enable the OKR capturing or recording process.

We want Rally to generate OKRs, to allow teams to record the OKRs, and then the OKRs can be mapped to the epics and there is organizational alignment. The organization can execute those objectives using the team's backlog.

I have been working with Rally Software for the last three years.

Rally Software, is a stable solution.

Rally Software is scalable but could be better.

When we try to generate some reports, it takes a long time to load due to the increased number of users.

We did not contact Broadcom directly because everything is handled by the admin team. Whenever we have an issue, we contact the admin team, who then communicates with Broadcom's technical support.

I'm a co-chair and I don't get involved with fixing Rally issues. We explained the Rally issues to the admin team, and they will most likely interact with Rally support to get it resolved.

We also have experience in Jira.

I am not involved with the initial setup. Once we have been given access it is easy to navigate.

There is a Rally admin team that will set it up for us and grant access.

I understand it's a little more expensive. That is why many people prefer Jira.

If they want to compete in this market, they have to price their products reasonably, they must understand the competitive pricing of licenses. I believe it is on the high side.

Given the industry and what is happening in the industry with more organizations attempting to become product-centric, Rally Software is definitely attempting to accommodate a lot of changes.

They should adopt the OKR.  In my company, for my client, we are attempting to implement OKR.

I would rate Rally Software a seven out of ten.

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.