Rally Software Reviews

When we went into Scaled Agile Framework, we could not have done it without the use of Agile Central. So for us, it allows us to scale our Scrum teams, and it also enables us when we do our remote big room plannings.

Agile Central allows us to log one hundred percent of the work we do and it allows for no hidden work, so teams can't go under the radar with what they're working on.

Let's look at the portfolio level. Let's take a look at what capabilities are needed to scale our teams and really add them to the tool.

The stability of the product is pretty solid, and the tech support that we get with it is phenomenal. We don't talk to anybody because we don't need to. We use the web application for all of our support management.

For scaling, we look for Agile Central to be the leader for the software that's going to get us to the next 4.5 Scaled Agile Framework.

I'm a proud user of Rally and Agile Central for the last six years and the ease of use - I don't even know when a new release is coming and I don't need to because it's so easy to use what's new.

When we go out and look for a vendor, we're looking for a partnership. So we're not looking for a vendor, we're looking for a partner.

On a scale of on to 10, I would give it a solid 9.9.

I use Agile Center mostly to do two things: 

1. To manage my requirements and I have hundreds of thousands of requirements. 
2. My teams uses it for their daily agile management. They describe their user stories and track the progress of their projects.

We are a former customer before it was acquired by CA. In that time, we were using just a fraction of what was there. This year, we started having more implementation and moving into the newest version. This has allowed us to use some of the high-end features like the label hierarchy, and it is good so far.

The effect of these kind of tools drives the way you organize things. You have to adopt yourself to the kind of workflow that it comes with. It helps you shape the way you flow.

Right now, it is the idea of having everything in place for both information and my project in a single network. Everybody who has different kind of users take advantage of the go through from the development guys to the project managers to management staff. Everybody has such great perspective of what is going on. It is very helpful.

There was some evolution, and as we have this old on-premise, it does takes longer. However, this complex requirement management, having different perspectives and different ways to organize the hierarchy of things, that is something that we value. It looks like the tool is at the beginning of having this new kind of approach, and we expecting different things from it.

It could improve by being self-organizing: user stories, different hierarchies, and different perspectives. Not just as a single hierarchical structure, but something that can be multidimensional.

The stability is pretty good. I do not have any complaints about the abilities of on-premise version.

I do not have a bunch of users. I have not tried scaling it.

I use more the sales consultants than the technical support. The consultants are very knowledgeable. They should be more frequently available. I would like to have more of their presence, but their technical expertise and their willingness to help me is pretty good.

We were not using a previous solution.

I was not involved in the initial setup.

No, I am not thinking about changing. I need to have a lot of pain to start making changes.

There is an ongoing change that is happening. CA has implemented with Rally, so they are still in the early emerging process. I think the evolution and integration of the two with product solutions will come after it.

A solution is not more than a solution. It is a tool. It does not solve your problem. It is fixed by the tool. It is important to think about the problem that you are trying to solve to work with the consultants to come up with the right solution. The tool by itself could not solve your product issues.

Most important criteria when selecting a vendor: partnership. That is the most important thing. To be there when I need someone to be connected with the evolution of my processes when I have difficulty, both technical or on the business side. That kind of partnership is what I value the most.

Organizing all of our Agile work load, and projects that we have in the pipeline.

It's been good. I don't know that it's best suited for Kanban which is the Agile style that we're using. It seems a little more focused on Scrum. So having some more Kanban methodology built into the product would be nice, but it does allow us to move our stories along the board, and have a good visualization of where everything is in process. 

It probably would be mostly the visualization of what's in flight, and being able to move the cards across the board, and plan our releases based on completed work, which really is the goal of Kanban.

The most valuable feature is actually creating a field within there for architectural review. So when teams are struggling or have questions on the architecture or strategy that they take, they can actually flag that particular story, release, or project. Those can then be reviewed by the architecture team and the teams actually get additional information on how to course-correct, build on the architecture that we're trying to build throughout the organization, and get over road blocks much quicker.

I would like to see more Kanban support. As it stands, it doesn't seem to have the features or the layouts that the teams really need to be able to execute their tasks. It almost tries to force you into more of a Scrum style.

Stability is great. We rarely have problems with it.

The scalability is fine. We don't have a huge development team, so it doesn't really need to scale that big.

We were doing everything Waterfall at the time.

We were looking at two different products, CA Agile and JIRA, and it seemed like there was less customizability for CA Agile, and that was important because we didn't want to have all the teams doing different things. So the lack of customization was a selling point for us.

Also, the reporting, and being able to roll that up across the verticals, was an important selling point for us.

The most important criteria when selecting a vendor are 

• the support that we can get
• the ease of upgrades
• just having software that works. 

Even though it's not part of our core business, a lot of the supporting tools need to work for us.

Having the right tools is important, but more important than that is actually the culture, the people, and the processes. Take a look at your culture, your people, your processes. Make sure that those are what you need them to be and then select a tool that is going to work well with those objectives in mind.

I have a couple of individuals on my team that help manage the utilization of CA Agile Central to make sure that we are being as mature as we possibly can for Agile practices.

Performance has been good. It allows for a lot of customization, which has been very helpful, because we pull key metrics, report up to our unit CIO on certain areas.

The benefit of the solution is enhanced visibility, that is probably the key one. And it provides data points to enable continuous improvement.

The ability, for example, to use the deep export report, and pivot tables and that kind of thing in Excel, has helped us out a lot.

It drives the conversation behind some of the pain points the teams have, based on the data that we're able to pull out of the system. As a result of that, we're able to make better decisions, to become better as a whole.

The customization and the dashboarding that is available. We utilize some of the customization we put into play to help the business see inputs versus outputs, because we obviously use Clarity as well as CA Agile Central. Just being able to correlate the amount of hours someone is working versus what work they're getting out of Rally has been helpful.

More customization capabilities would be helpful. Providing a little bit more structure around how the system should be set up in terms of the hierarchy structure might be helpful as well.

The stability has been good. I don't think we've really had any problems. There have been a couple of issues, but they've been on our side in terms of Okta, the single sign-on solution we use.

Scalability has been good. Again, the reporting, helps with it.

A couple of my direct-reports have used tech support, and it's been fairly useful. If we don't have the solution developed at the point of time when we ask, they are more than willing to help us get to that solution, from a customized perspective.

This was the solution that we had in place when I joined American Express - I'm a year into Amex. Seeing how teams utilized the solution when I initially joined, it wasn't streamlined, it wasn't something that we put much thought into. Creating a process to rally behind was, I think, a key aspect.

I wasn't involved in the initial setup, but the upgrade, yes. I think the upgrade itself was straightforward. The rolling out across the organization was the complex part. Communicating the new benefits of the upgrade, and that kind of stuff, has proved to be difficult.

When selecting a vendor to work with, the most important criteria are the scalability and the availability of the data to us, to be able look at in the reporting aspects.

You need to have a good strategy in terms of rolling the product out, if its something that you're getting into the first time. Make sure you have a strategy surrounding how the team should use the product, what it should be used for. Some of the benefits, some of the sign posts for success, need to be set up along the way, as well.

Planning for the scrum team.

It has performed excellently.

It's the ability to bring visibility to the work. Previously we had another tool. Actually, it's a tool that I built, but it was limited in its ability to provide that start-to-finish visibility. And the traceability, from inception of the project to final test and deployment. Agile Central provides us that, not directly, but with its integrations to other tools in our tool chain, so that's a great help.

The visibility it brings to the plan, the ability to capture tasks, and trace them all the way through the life cycle. Providing that visibility helps both me and the team, or teams, to be able to understand where we are in the development process.

The navigation within the tool sometimes is a little tricky for me. I'm sure with more use, more practice, I'll become accustomed to it, but some of the things just aren't intuitive.

The tool is much more stable that I am. It's very stable. We've had no problems.

Scalability hasn't been an issue. I wish it were, but so far the adoption has been good. We have a ways to go before I would imagine that there would be any scalability issue.

I have not used tech support. We have an application administrator and he handles all that.

Although I wasn't involved in the initial setup, I do know that there was some complexity to it. But not terribly complex. It was not hard to do, because it is a SaaS solution. It was basically: Give us the URL and point us to the training, and that was it.

No, Agile Central, had been on our radar for quite a while.

For me, the most important criterion when selecting a vendor is finding a partner, versus just a vendor who's going to deliver a piece of software and wait for the money to come in.

Don't think just about the tool, but think about the entire lifecycle of the tool, or the lifecycle of your application development. That's very helpful.

We use it to track all of our work. We also manage our portfolio in it.

It works. It's a bit cumbersome to manage the Project Picker. As we sunset teams or projects close out - but we still have test cases tied to those teams or projects that are being used in other spaces - we have this monstrous list in the Project Picker that becomes really difficult to manage and find, and we can't clean that up ourselves. It would be nice if it was easier to do that and not lose your history.

There's familiarity. The teams have been using it for a while. Leadership is comfortable with it. That's huge. And from a price point, it's a cost effective solution for our needs.

Visibility of the data. If teams are tracking correctly and entering their information correctly, it's really easy to see where you're at, within your release, and whether you're on track or not. For our business model, we can't get everything out of the box, but we're a unique business so I understand that, but we know how to massage the reports to get what we need out of it. And so far it's done the best job for us.

I would like for workspace admins to be able to hide projects in the Project Picker and not lose any historical data; make them invisible to certain users, visible to certain users, depending on permission sets. That would be lovely. 

I'd like the ability to customize reports without having to incur Professional Services, or having to write my own code GitHub and then implement that as a custom report. That's untenable. It's not sustainable.

I think it's relatively stable. I've had very few instances where I've had an issue. I think CA is really good about communicating outages. Any troubles we've incurred generally haven't been on CA's side, it has been teams or functional managers not assessing impacts to anything they have in process that could be related to the outage that was communicated.

Scalability works well for us.

I've had pretty good responses with them. If I need help or we run into something that we believe may be a defect, I just open a ticket on the support site and I usually get resolution really quickly. 

There was one issue that we had where I was going to be out of town, and I'm the point of contact for our company, so I had to leave a person in the gap to get it to "done." And within a business day it was resolved. I was really happy with that because I was a little concerned.

When selecting a vendor the most important criteria are:

• It's got to work.
• It's got to be stable. 
• Cost, to be honest, is a huge factor. It's top three. It needs to be reasonable and affordable. I need to be able to make a business case and sell it to leadership, give them a reason why it's going to work better than what is currently in place. 
• We need reliable support.

I rate it a seven out of 10. I don't rate it higher because of the things I said I needed more autonomy in being able to change. And while I have really good results and feedback from CA Support, I wish that Accounts were as responsive to my needs as the Support side is. And I get that we're probably a small fish in their pond of Accounts, but we still need help getting our work done.

If I were to advise a colleague looking into similar solutions I would say it's a good tool. I'd want to talk to them more about what it is they're trying to accomplish to find out whether this is the best fit or if they want to use something a little different. Agile Central will cover a lot of needs for you, but maybe it's too much for what you need. So I would want to dig down deeper into their requirements to make sure it's the best fit.

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.