Rally Software Reviews

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.

My company uses it for managers, project management, and all the release management team.

It helps us to track and manage the way we work. We follow the Agile method and it really helps us to manage things and divide up tasks. It is quite a good tool.

I am pretty much happy with the use of the solution. I want to recommend it to other people. The way we work, get the reports, and check on things is very clean. I can customize things from my dashboard. I would like to see better scalability.

We have used this for almost four years.

I guess if it can give more integration, something like Outlook, and more automated instead of manual entries, then scalability would be OK. We have around five thousand people using the tool.

I guess I am good with the level of technical support.

I didn't use any other solutions. I came to know about this program management solution from working at my company.

In terms of the setup, there was one thing that was a little difficult. I got to change it very quickly, and the team was helpful.

I would recommend it. It is a very good product, very helpful in managing, and pretty good at checking things. The way we manage our projects and the way we work with it is pretty good.

What I like the most about Agile Central is that it is the only system I need to have full control and visibility of our entire body of work plus the activities and processes required to deliver it. This visibility is particularly good from a high-level portfolio view to individual tasks, staff.

There are few customisation options. For instance, the workflow for story cards cannot be changed out of the box from the standard (Defined, In-Progress, Completed and Accepted). However, this will not be a big problem for most organisations that follow a standard scrum framework.

The issue is mostly relevant to team using Kanban boards with customised workflows. A very common flow for instance is: To Do - > Analysis -> Development -> Testing -> Completed. So teams wanting to bring that kind of workflow to Rally will not be able to our of the box. And Rally will rightly discourage that kind of workflow.

And I’ve seen teams doing Scrum that have added additional columns to their workflows such is “Waiting” or “Blocked” and other not having the “Accepted” column.

Rally of course offers other options to manage blocked stories/tasks so perhaps the “improvement” tag might not be entirely fair. They do offer the functionality so what I was referring to was the ability to customise that functionality to more personal preferences.

I have used Agile Central for close to one year.

We have not had any stability issues. The system is web-based and hosted by CA. There is very good communication around system maintenance and upgrades.

We haven’t had any issues with scalability. We have increased our user base seamlessly.

We haven’t really required much technical help as things have worked as expected. The CA Agile Central website provides updates on maintenance schedules or any other unplanned outage. When we have required help on how to use the tool, the CA Agile Central team has been quick to respond with solutions or suggestions.

Team Foundation Server (TFS) was quite suitable for us when we started to use agile as a delivery methodology, but as our maturity increased, the need arose for a more sophisticated tool to give us better visibility and control and CA Agile Central has certainly given us that.

Setup was very simple actually. There is some work required upfront to define standards, best practices and governance on how to use the tool but CA Agile Central itself was very straightforward to set up. Everything is web-based and very intuitive. We had a CA Agile Central coach here for a few days and that was enough for us to get started.

Licensing depends on a few things. The assessment starts by looking at your portfolio of work, number of projects, resource profiles, etc. Then you need to assess the level of maturity the organisation has around agile. Teams should not be forced to start using agile methodologies if they are not willing and ready, so you might want to start with a small pilot.

We evaluated JIRA and also looked at the TFS roadmap for future improvements and upcoming features.

The most important thing is to have very clear requirements as an organisation. That includes having all the internal processes, governance and ways of working well understood so that the selected tool can be assessed against those requirements with confidence.

The most valuable feature is the ability to track projects; not so much the reporting, but what you enter and the use of the product, and that's for tracking purposes. That's why it's important to me.

It allows us to better scrum and Kanban. It allows us the opportunity to not need a board and physically co-locate it. We can do it online.

Building custom reports is difficult and cumbersome. Trying to find the correct field name to test is only part of the problem. The field name and qualification changes depending on what level I am trying to report.

When reporting at the task level, the story needs the story qualification whereas when reporting at the story level, the qualification is not needed. When reporting at the task level, I cannot qualify based on Feature Group. This limits my ability to programmatically limit my results. The syntax of the reporting is also cumbersome. The help is only limited help and is not written for non-programmers.

Solution: Provide a query help that actually lists all of the fields at each level. Even when selecting “To see a list of all fields available for each type of work item, check your Web Services API documentation

It is easy to put information into Rally but it is all overhead without an easier way to get the data back out. I have team members who continue to double entry the Rally data into a spreadsheet just so they can more easily produce the reports that are helpful to them.

I have used it for about three years.

Over the last couple of years, it's had moments of slowness, but it seems like they've resolved that, and every so often it goes down, but that just seems like it's a few minutes, so that's more like a support type of thing. So, it's not a big stability problem.

It is very hierarchical in structure, rather than relational. Maybe if it was built on a more relational database concept, it might be a little bit easier to manage.

I don't see any scalability problems.

I've talked with tech support but mostly about reporting and trying to get the information back out of it that we need. I use internal support teams, so it's Comcast employees that are supporting me.

It was a corporate direction to switch. The tool that we were using before was very poor at accomplishing what it needed to accomplish, so anything would have been better.

I wasn't involved in the setup; I was a consumer.

I was never part of the pricing and licensing. Training definitely; everybody that's using it should go through some training, but a lot of the training was very generic in terms of using CA Agile Central and it wasn't specific to the team's application.

The tool actually includes a lot of things that most teams don't do. That information was included in the training, but was never applied, and yet some of the things that we needed to do weren't covered in detail in the training like they should have been, so it was a lot of groundwork to come up to speed on that.

My advice would be to make sure that you're implementing it in conjunction with agile methodology. If you implement this tool with waterfall, you will see that it's very oriented towards agile, and it's set up and structured to support agile and not set up and structured to support waterfall methodology.

I think that it isn't that flexible for helping with teams to migrate to agile; it's not very flexible with customizing for my team. There are a lot of pieces of data that my team needs, and we're having to use non-ideal fields for those. I know that that's the way that it's installed in our application, but a lot of the customization that's available in CA Agile Central isn't available to me to do. So, I would say that it would need to trickle down to the group admins, the ability to be a little bit customized, to be able to customize it to the team.

The valuable features are:

• User story tracking and team status management, including capacity and burn down
• Allows for the creation and scheduling of detailed user stories including attachments, assigned tasks, discussions, child stories, and revision history
• Allows for the association of defects and test cases. (I have not used these features as we use HPE Quality Center for that purpose.)

Some of the improvements to my organization are as follows:

• Helps my team organize our planning and testing activities.
• Removes the need to have separate products for tracking the various ancillary records for our user stories.
• Helped us to organize team effort and keep the team on track by providing a burndown chart and team status breakdown at the task level.
• The ability to create child stories and track discussions throughout the lifetime of a user story and its children removes the need to maintain additional external documentation.

The following are areas for improvement:

• The UI can be slow to respond at times and difficult to navigate initially.
• The home dashboard can be very slow to load.
• Individual user stories can be slow to respond when navigating from the Iteration Status page.
• The tool can be slow to respond when estimates or statuses are updated.
• The difficulty in navigation relates to the learning curve of the application.
• There is a help page with a great deal of information about the various features and processes, which helps to demystify the application a bit. However, even that page can be cumbersome to navigate.

This application is rarely unstable. Scheduled maintenance is conducted with ample warning.

There have not been any scalability issues.

Good estimates give the burndown chart value. If your burndown looks bad, first look at your estimates for team capacity and user story/task effort estimates, and then look at the members of your team.

A lot of the reporting is very valuable to us. We really need to control certain releases and milestones, and so on. Being able to report and get statistics on all of that stuff is one of the features we really like, especially now that they're expanding that as well. We like that.

Honestly, it keeps us more organized. We have a lot of products and we ship them pretty fast. CA Agile Central is great for us because we can categorize all these different things. It really gives our top-level leadership visibility into what we're doing so that they don't pound down our door every two seconds. They can actually go into CA Agile Central and figure things out for themselves. They can make better decisions without really needing us.

I use it a lot. I don’t really have any complaints. There are a lot of alternatives out there. They are also useful, but I have no complaints with CA Agile Central or with CA in general. I don't find myself saying, “I wish it did this,” or ”It's really killing me here”. It has been a good experience.

As a release manager, what they’re coming out with now in terms of release automation is going to be very valuable to me. I think that with CI (continuous integration), as much as it is expanding and taking over most software shops anyway, I think that's the way to go. I think they're doing it right. As a release manager, I'm happy. CA is coming out with a lot of CI-type things, which is good.

It is stable. There are no issues there.

It is scalable. There are no issues there.

The customer support at CA is good; however, we haven’t had to use it, which is good. It's always there if we need it. That's also good.

I don’t believe we’ve needed technical support. It has been pretty stable. It fits our needs for what we need so far.

My company has been using CA Agile Central for as long as I’ve been there.

I've been at other companies where they're using different tools, like JIRA and stuff like that; but CA Agile Central is fine. At one of those companies, we weren’t using JIRA all the time. It was really too convoluted for what we needed.; so we didn’t use them. Sometimes you needed to dig for certain things that were not necessarily laid out flat like CA Agile Central is. Even though, in JIRA, you can kind of organize them in different ways; but only if you use them. Like I said, CA Agile Central fits our needs pretty well.

Our top reason for selecting an agile platform was needing to ship as fast as possible. Waterfall is good for new products coming out, but we have a lot of long-standing applications that have been out on the market for awhile. Getting releases together and shipping them as fast as possible is what we needed. It was kind of a no-brainer for us.

I would say our agile maturity is intermediate. We're still learning. There's so much you can do. Like I said, we are even coming out with new products, so we have to use waterfall sometimes; but we're still learning about it. We're trying to integrate as much as possible and tailor it to our company.

When we evaluate vendors, are most important criteria are the customer support, scalability, and availability. We've had problems in the past with some other vendors whose products’ availability was not what we needed. They would go down quite a bit, more times than you would think, honestly. That's a big deal for us, especially whenever we put so much into it. If a system goes down, the entire development department basically stops working. That's a big thing for us, especially as we keep putting more and more into CA Agile Central.

If a colleague of mine was evaluating this solution, I would advise them to keep it small. Simple is better.