What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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 needs improvement?
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.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
I have not had to deal with them.
What other advice do I have?
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.
Which deployment model are you using for this solution?