Rally Software Reviews

We use it move projects through the software development lifecycle.

It performs pretty well. It's nice that everybody throughout the whole process has access and is shown the relevant information to their part of the job, their part of the SDLC.

It really does help everything just flow through the cycle better; everybody just worrying about their small piece of the pie. And then the project managers can have a bigger overview of it. I like how it moves things. It moves development through the whole lifecycle. 

The most useful part is how it breaks down tasks into parents and children, manageable tasks. It has a whole project as an initiative, and then it breaks it down further and further. And then you get to actual user stories and tasks that you can sit and develop. You don't have to worry about the whole big picture. It's nice how it breaks everything down into chunks.

I think the interface could be a little bit more visual and less wordy. Right now, it seems like it's just a lot of text on the page. In other ticketing systems where it's more visual, you can see more of a flow. But in this one it's more just a list of tasks. I would like to see that a little bit better, especially considering it has so many great organizational features, like child tasks, different artifacts. It would be great to see it presented more appropriately.

Very stable. I can't think of any down time we've ever had with it, to be honest.

I don't think we've had to worry about scalability too much yet. We just use it for one piece of software still, right now. So it's still very small, we're almost kind of piloting it right now.

I don't think we've needed to use tech support. Honestly, if we did, it wouldn't have been my job in our company. We have a relationship manager that I'm sure would take care of that.

We were using Waterfall, which worked for decades, but it's definitely showing its age. I think they just wanted to switch to the Agile methodology and Rally was probably the best software to do that with.

It just came to us and all of a sudden, management said, "Hey we're going to use Agile and Rally, and good luck." So we've been trying to learn it for the last year. 

I wasn't involved in the initial setup. but they put it out pretty fast, and I have seen changes in it being made fairly quickly. So I would say it's pretty straightforward.

The most important criterion when selecting a vendor is support. I know as a team lead for a developer team, I've personally worked with other third-party softwares that we integrate with. They've assigned people specifically to our account, which I'm sure happens at a lot of Fortune 200 companies working very big accounts. So the personalization is nice. We can have a weekly meeting with the same person, the same point of contact. If anything goes down, if we need assistance with anything, that person is available. Don't take the people out of IT. We work with computers so much it's easy to get out of touch, so keeping a personal touch is probably the best thing.

I would rate it a "high eight" out of 10. It's a very capable software. Like I said, I just would like to see it presented a little bit more visually. It's definitely got some power but everything's got room for improvement. 

Try to put yourself in the mind a developer and try and use it and see how you think it would flow. Really, it's a whole team collaboration. I'm not in the project support aspect, but I can empathize with them and think how they'd want to see things. Just try using it. See how you can move a project through it.

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. 

The entire application lifecycle from user story to the quality assurance for the testing. It has performed great. It has a great set of features which address the whole process. 

It has streamlined the entire process of development from getting the requirement for the application, supporting all the testing processes, and reporting all the defects back to development.

Its integration of support of the quality assurance process. It has allowed the quality assurance team to keep all information in sync with the application requirements and user stories for our general development.

We would like maybe to have more integration with test automation. As it is right now, it does not support automation of the quality assurance process. It just supports manual testing. 

It is very stable. It has been on the market a long time.

It scales very well. It improves in technology constantly and gets up to speed with the latest and greatest. Basically, all the functionality. 

We use the technical support once in a while. They are very responsive and knowledgeable.

The initial setup was fairly streamlined.

If you are looking for a stable ALM that supports the agile process, this is the solution to go with.

Most important criteria when selecting a vendor: functionality and stability. So, for it to be a stable technology with a solid road map.

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. 

We use Agile Central to record all our user stories, features, and then to track down the burndown, velocity, defects.

My launch. How soon or how fast can I go to production, is what this helps me design.

From a solution perspective ,we use the Burndown to see whether the velocity for the entire sprint is okay or not. Am I going, did I pass? Do I need to prioritize? How many impediments do I have? What does my backlog look like? Have I taken up enough in that given sprint? Will I be able to deliver all that? It helps me track that down.

Primarily, producing more meaningful dashboards is what we have given to them, saying "customizable." 

Customized reporting, so that rather than going to them, if I can produce my own UI, that would be meaningful.

The solution is stable. 

Scalability is good. Based on what we have done so far, it is scalable. No problems faced so far.

We have a solution group as well, Testing Services within our organization. If we are looking for any modification within the tool, we can go to them saying, "Okay, when the tool came in it had a particular layout of, say, 100 fields. But based on my requirements, I want to improvise that, I don't need them. Eighty fields are good, but the remaining 20 fields I want to change over to this, make it more meaningful, more for my own organization. Customization.

So when we go to the Testing Services group, they take their time to have it implemented on Agile Central and then we pull a report. For example, the Defect Dashboard. Now, the Defect Dashboard came with some basic things. My anticipation regarding the Defect Dashboard is, I need to see more details, like what was the root cause, sub-root cause. I track it down to that level. So that customization we can easily do. That makes it helpful.

As I said, we have a Testing Services group, so we just give our requirements to them. If they needed to contact CA for any sort of modifications the would have done that. We don't know.

We don't directly interact with the CA technical team. We talk to our technical team and they might internally talk to them.

What we used to do in, say, HPE Quality Center, is now getting done Agile Central.

As a Scrum Master, helping the product group define feature stories, and portfolio management, and helping manage the teams, their scrum backlogs, their performance, and velocity.

It has performed well.

It helps us not to have to use any sticky notes. We project up every day, on a daily standup using the iteration planning part of it, and using the post-it portion of it in the Kanban, to communicate daily with the team on how things are going. 

It helps me to have a dashboard where I can see what things are not being worked on, what things are blocked, for instance. It helps me evaluate teams' historical performance using velocity charts. 

Capacity planning and release planning for the next PI help me figure out what the potential velocity is for each of the teams. It rolls it up, so that across teams we can figure out how many features we think we can get in for the next PI. 

And we've actually used it for virtual PI planning as well. We have teams in different locations, and we actually virtually do PI planning, big-room planning, using the tools so it's been really helpful there.

I like all the features of it, especially the Team Planning board, and the Release Tracking. It helps us track the features and stories that line up with those features. I like it for the most part, and how it works.

I can't think of any off the top of my head.

I have found it to be fairly stable. I know there have been a couple performance issues when we're all on it, but I think that was maybe about six months ago, maybe when we went to the cloud. But since then I haven't experienced any performance issues. I think that's really gone down.

It scales well in terms of setting up the workspaces and the hierarchy, we find that that works really well.

We've used tech support very little. But we're satisfied with the support we've received.

We were using Team Foundation Server (TFS). But some people were using JIRA, so there really wasn't a consistency there. We switched because it was really determined that it was probably the best tool out there to use.

It was actually pretty straightforward, and it did seem more intuitive than what we were using, which was TFS from Microsoft.

When our company is looking for new products, and new vendors, the criteria is more of a consensus, or global acceptance across the board, and executive support. I'm sure price tag comes into play.

I give it an eight out of 10. I tend not to give anything a 9 or a 10, because I always think there is probably room for improvement on it, not that I can't think of anything right now. It's not perfect, but it's definitely very good.

I would tell colleagues looking for a similar solution that Agile Central is very easy to use, and it's easy to build dashboards. It's very intuitive. I'd recommend it.

To manage our work in a common way.

In terms of performance, we're just getting started on it. No issues so far.

It helps me plan the work. Also helps me plan an estimate of how soon or how far out we'll be able to deliver something. Those are big things.

• Visibility across the team
• Ability to see the team's capacity - how much free time, how many deliverables

It could use some templates and patterns that we can follow. There's a lot of support for Scrum and Agile, but something for the Kanban side, I'd really appreciate that.

I don't have a comment on this because we've just started to use it. From what I've heard from other users, it seems like a good, stable product.

We were looking for a tool to support our work, to support our process, especially in the Kanban area. Without that, we started to use Excel, we started to use SharePoint but, really, they were not giving us value, the visibility. Then we started to look for something which is specifically made for supporting this kind of process.

When our company is looking for a new vendor we float an RFP; there is a set of criteria, we get together, list down all the requirements that we have. Any tool that we look for we look for, we typically look at four different vendors, four different tools, and try and compare them.

I would recommend CA Agile, certainly, but it all depends on what processes you have and whether it's a fit for them. 

Release planning, test case writing.

It's performed plenty, I'm happy with the performance.

I get to see what we have, what test cases we need to deliver, per release.

It gives us the visibility into what we're doing and how we're doing on a day to day basis, to see if we need to refocus or to try to change things before it gets down into the negative. The daily iterative working part of it is what I like. And I get to see the visuals of what's going on.

The Defect feature. In one view you can see all your defects and you can push them into the different releases.

I also like the Release view, where you can select different user stories and just dump them into the releases you want them to be in.

I also like the reporting. I can see my Burndown, my Burnup, and other reports that we use to see if we're delivering on time.

One thing that my team struggles with is when they have so many user stories. You have the parent's story, and then you have a child of a child of a child and it goes "down into the drain." Sometimes it's hard for them to quickly search for a user story. I know there is a part where you can just type the user story number, but that's if you know it. 

I wish there was a view, like the Kanban view, where you could see the parent, and see all the children visually, so you could drag and drop where you want it to go. Something like that might help.

It's been around for a while so it's pretty stable. 

I'm assuming it's our infrastructure, but since its web-based, at certain times of the day, it's slow. At certain times of the day I've noticed it takes a while for the page to come up and for updates and the like. Sometimes you have to shut it down and restart.

I opened up a ticket with CA about it. I don't think I got a response back. It's been a while, I didn't look back into it, and nobody contacted me about it.

It scales.

Generally I'm satisfied with the tech support I get from CA.

I wasn't involved in the setup with my current company; my previous company, yes, I was. I think it depends on who you're working with. With the person I was working with in my old company, it was straightforward.

We had that one on one relationship with CA, and they were on site to help us out. If we had to be on a call for anything they were there.

At my old company we had a demo for VersionOne, then Rally (now Agile Central), and one other tool. One of the reasons we went with Rally is it was easier to use than VersionOne. The reporting was great, it was what we were looking for. And at that time it had another feature called Timesheet, that became the Timesheet in Agile Central.

When selecting a vendor, what's important to me is that the product be user friendly. It also has to be able to produce. My bottom line is the outcome, so I want to see that it can help deliver correctly, on time, within the budget. Also resource planning, resource management, those are the kinds of things I'll put into consideration if I'm looking for a tool to use.

I think CA has been consistent in trying to improve Agile Central, but they also still have room for improvement, so I give them seven out of 10.

I would tell colleagues to try Agile Central because of the features I noted above. And then, I don't know about VersionOne, but the support for Agile Central is also great.