Rally Software Reviews

The most valuable features are the team-level interactions tracking of stories, features, and sprint. We do all of our budget tracking with it and CA PPM, and then our teams are working through Rally, so for me it's really easy to go in there and be able to see what is going on. I can see where things are assigned and where I should be worried about risks. For example, I can very easily see that a team has 10 stories on a feature and all of them are assigned future sprints, so I feel good about that.

It's also a very simple tool to use. I find it easy to go up and down the hierarchies -- going from initiative to element features all the way down to a story level. I think it navigates pretty well.

Then reporting is probably the other thing that I like about it. It's got a good reporting engine with it.

Lots of customizability. I know we created a few of our own reports and then a lot of the out-of-the-box reports are pretty useful as well.

I think it got everyone aligned. I would say that's probably the most helpful thing, whereas before that I think that teams were just managing backlogs of spreadsheets or whatever they had or whatever they were doing beforehand. I'm not quite sure. I came in right after we started implementing it so I didn't really see what was there beforehand. I do know that just from when I first started to today, everyone is more aligned and has a better understanding of all of the work that is happening, not just pieces of it. It has an API that connects it with CA PPM.

I know you connect CA PPM to other agile tools as well, not just routers. I know a lot of people are hoping for that and a portfolio RPM are kind of pieces of it, but I don't think it's quite there yet. I would like to see it be a little more integrated going forward.

The portfolio side of it needs improving, especially integration into CA PPM. It would be nice to hopefully see some of those have a little bit more connections.

I know we do a lot of high level planning and it seems like there are a lot of duplicate features back and forth, and it's kind of like, pick one or the other at this point. It would be nice if they talked a little bit more. For example, we'd really like a better integration with Rally.

I don't use it daily, but there seems to be no stability issues.

We ran into some problems with archiving some old stuff but we created a separate tree and that's where we put all the archive stuff. It's still there, it's still accessible but it's not messing with the reports of your enterprise.

I've just used our internal technical support.

I wasn't involved in the setup.

Make sure you understand your processes and just know that it's not the tool. It's more about the process and how you work with it right. I know we did our last upgrade with Clarity and we didn't have our processes all the way defined. We started implementing things in the tool only to find they broke later, so we didn't have that process defined. Make sure you understand what you need before you start.

It has improved our ability to focus on less work, but do that work better and at a higher quality, than we were able to before. 

The main value that we get out of Agile Central is the transparency it allows us to provide, both from the team level all the way through the executive level within the company and the work that we are doing. 

We have been talking about improvements in the quality section of Agile Central. The quality section does allow you to do test cases and test sets, and all these things, but it does not integrate very well with the portfolio and feature side, which causes some challenges. 

We have not had any issues. 

We have had no scaling issues with Agile Central. We have worked anywhere from a couple of teams up to about 15 to 20 teams on Agile Central.

Technical support is very good, considering we have very rarely had to use it. The product has been very stable for us. We have not had a lot of technical support issues even to reach out and ask about.

The upgrades are very simple and straightforward. They generally get pushed out, and you choose whether or not you want to accept that upgrade early, or whether you are going to wait for the general release. 

As far as the initial setup, it can be challenging. There are a lot of options. There is a lot of configuration. There are a lot of decisions that you have to make on how you want Agile Central to work for your company. Those decisions can impact your flexibility in the future. With the initial setup, there is some thought that really needs to go into how you want to do it.

I would give it probably in the seven to eight range. In order to improve beyond that, I think there would need to be some simplification. The team-level side can be challenging and complicated. However, its ability to scale to portfolio and executive-level solutions really drives it up to that seven to eight score. It is something that I don't think there is a lot of other projects out there that allow you to take that from a team to an executive-level view.

Most important criteria when selecting a vendor: First and foremost, we are buying a product, but we are buying also the people and support. Probably the best thing we have had with Agile Central is not only the tool, but the people that support that tool, and the relationships we have been able to build there in order for us to further our Agile journey.

Primary use case is agile development and Mode 2 development.

It has performed really well. We have taken some teams that were non-Agile and tried to do a combined approach. This eliminated some of the heavy documentation that we were used to with waterfall. We have been able to deliver our integration between CA and HPE ALM in a period of time that is about half of where we were before. 

It documents stories in a way where we do not have to be heavy on front-end requirements, front-end documentation, and front-end workflows. We are able to create those stories in a more of a just-in time approach. Since we are doing combine and not scrum, we want to get those stories on as we think of them and immediately work on them instead of waiting for a time box. So, it was the ability to adapt quickly. 

We are very new on agile and Mode 2 devolvement. It has really allowed us to experiment with approaches that we would have been a bit afraid to experience before. So, it has allowed us to try new things and to take risks. 

When you copy a story, I would like the attachment to copy with it. This is a big one for us. We do requirements in one sprint, then do development in the next, which still is a little bit of waterfall. So when we copy those requirement stories and they become development stories, the attachment does not come with it. So, it is a lot of manual effort to do that. It would save us a lot of time. 

We did submit an enhancement request. I think a lot of teams that do very large scale products have the same issue. They just do not realize it would help them. 

Also, there are a few things in the way things trickle up from category to theme to feature that I do not really like. I wish there would be some enhancements there.

It is very stable. It was purchased by CA from Rally, which I was familiar with beforehand. It has gotten better since CA has taken over, adding some new features, but it is a very stable platform. 

Since we are more of a Waterfall shop, as we bring new teams into the agile approach, I think it is quite scalable for us. However, it will probably be a more longer term poll. 

We have used them quite a bit. They have been very responsive. We use a competitor's tool for our waterfall approach. I won't say which competitor it is. However, we have been very happy with the speed and the availability of CA's technical resources.

Our issues have been lower scale problems, but we do not have a support staff to manage Agile Central. What we found was technical support was not only giving us the ability to get help, but also helped us evolve our support team into a team that can be managed well on its own. So, I have felt they have helped us in a lot of ways.

We did not have a solution in place. We were looking at Mode 2 and agile teams and we knew we needed something. Putting post-its on the board was not going to work anymore for a company of our size. While we still do some post-it exercises, it all ends up in Agile Central and we knew we needed something to manage this. We still have PM's who want to see portfolio management, so we knew it had to be digital. It could not be paper anymore.

We took our instance and revamped it from the beginning, which was very straightforward.

We were. We were looking at a few. Not sure if I can say which.

They were not providing a solution that was mature and developed. They were providing solutions that they wanted us to be like a test customer on.

They still feel like a small tech company. The support we have gotten and the way they have managed or accepted some of our enhancement requests. They still treat it like a small company, like Rally was before they purchased Agile Central. They still have that feel, knowing how big they are and seeing how they can act small. It is really nice.

Make sure your agile processes are really well-defined before you go out into the market and look for a tool. Tools do things differently, they call things a feature in one and a subfeature in another. Make sure your processes are defined, and once you have that, look for your tool after that. Do not look for your tool first.

Most important criteria when selecting a vendor: We have price, which I would not say is our most important. We are looking for more of a fit and finish to our process, though price is really important to us. One of the things that we look at is: We want to create a really good process, then find a tool that fits that process. I think a lot of customers do it the other way. So, if our process is mature and we like it, the tool really needs to fit that.

Defect management is most valuable, since I am on the QA side. It's a very good tracker.

We have centralized all our agile process on it, so it's been our agile central during the project.

Based on my experience and the level of use, I think this tool fits everything we need.

I’ve been using Agile Central for 1.5 years.

Sometimes the app freezes when creating either user stories or defects in Safari. The performance, in terms of response time when creating elements, is not as expected.

I have not seen any scalability problems.

I have never requested for support before.

I had the chance to work with Atlassian JIRA in a prior project. When I arrived at my current project, it was the first time I worked with Agile Central and I am still using it.

The rampup was very straightforward.

Pricing and licensing it is not my responsibility. I am an end user only.

Choosing the tool was not my responsibility. However, I was using another tool and the rampup with this one was very straightforward.

I would recommend using it without any doubt. I think it fits perfectly with the agile processes.

The most valuable feature of the solution is that we are able to identify individual teams, and those teams can then break down their work, and watch it flow through their process. The benefit is that it provides transparency into the work that teams are doing.

It has brought a lot of light to the differences in the way our teams process the work through. They may be doing the same set of work, but Team A is doing it completely differently from team B. We've identified some of those differences; and we're now starting to align the process.

Our biggest struggle right now is that we're a SaaS customer, and that we don't have access to the database behind the scenes. So we're being asked by our Scrum masters and teams to provide data and reporting that we're not able to get to using the tool.

The stability has been very good. Although, this year and last year, we did notice problems on Monday, just as CA World started. I think it's very coincidental. It was just kind of odd.

I think the scalability is there for our organization. We are not in a position to take advantage of any of that yet.

There have been a couple of cases where we've asked questions, and the answer has been, "Here, go read this site." That's been a little frustrating; but, for the most part, all of the cases have been resolved, timely, and with good results.

We were previously using a different solution, and it was not suiting our needs. We had teams circumventing the process and using spreadsheets, or wall-based paper models, which is good; but we wanted a way to report and review all the work that was being done. So we went with CA Agile Central when we converted. It's been much better and there has been a lot more adaption of this tool than the previous one.

It was very straightforward. We didn't have any trouble rolling it out into our organization. The issues we had were internal in adaption.

We did a side-by-side demo and evaluation with two vendors. At that time, it was CA Agile Central and Version One. We chose CA Agile Central over VersionOne because of the reporting features and ease of use.

The only solutions I've experienced are CA Agile Central and VersionOne, and obviously, we chose CA Agile Central. There was also Serena Agile Planner, which was not ideal. Of those three options, I would way that CA Agile Central is excellent. Among those three, we were very happy with it. We are able to incorporate it into our environment. That is the most important thing for us. We're pretty rigid in the way we do things.

My advice is that they need to understand their environment and what they need. Then look for that in the tools that are provided. CA Agile Central was very flexible. You can configure it without customizing it. That was one of the things we really liked.

Being able to control the requirements through the change request lifecycle is one of the most valuable features.

It optimizes the time to market of the requirements.

There should be different ways to decide on the requirements, not only by using a flow chart. There should be more than one way; maybe with use cases or another more graphical way to represent the business requirements.

I wish there was a way to maintain the documentation, the knowledge management of the development team; and to keep a live version.

The stability is very good. There are no crashes.

The scalability is very good. We are planning to complete the whole lifecycle of development activities.

We use technical support a lot. We have our partner, and we use support with them. Technical support is excellent.

We considered IBM Rational.

We have a lot of requirements. We have lot of business areas that continuously places demands on the IT group. We need strong tools that help us keep correctly the requirements in the lifecycle. It's important. It's not enough to do things better. You need to have a better tools. We have a lot of delays that we want to mitigate. We don't have a good time to market. Agile management helps us.

Technical support, knowledge, and productivity are the most important factors when we chose CA as a vendor.

Make sure that everybody in the company and team know the importance of the change.

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. 

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.