Rally Software Reviews

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. 

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.