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 work with our business units and they hand over a project to me. Then, I break it down and dissect it at the project level and break out all the features. Then, for each one of the features, I write all the user stories. Then, I coordinate with my software development team to get the work done for all of the user stories.

We take it through the entire process from the conceptual stage to the business of getting the work done and showing the business that we got it done.

I guess the main thing is that it allows us to pull all of our user stories and manage our agile process together for our agile team.

It enables us to document our epics and features and user stories all the way down to a fine level.

I'd say that there are a few things to improve.

On the main screen, I think it's called the Team Planning screen, it should be able to run a backlog. For example, if I have 300 stories in my backlog, it would be nice to be able to filter those out by project because that's the main place that I look at them and my team looks at them, and you get 300 stories out there for numerous projects for our team, because we work on 85 different applications. There are five or six primary ones, but the rest are back-end components.

We've got some technical stories for back-end stuff and we've got some continuous improvement items for our assisting applications. Within that backlog, to be able to have some type of filtering mechanism so that if I want to see all of the stories for a certain project, I can pull them out and view them, would be useful.

Right now, I have to scroll down through 300 stories and try to group them all together and find them and then, by the time I go and group them together, somebody's going to ask me to group them another way. Then somebody's going to say, "All right, well, can we prioritize them in that backlog?" Well we can, but then I've got to change all my groupings.

All this takes time. Basically, what I end up doing is just pulling those out, either copying, pasting or exporting them into a spreadsheet and then I'm back to managing them on a spreadsheet rather than in the tool and it's just time consuming.

There are certain things that I think I would like to add that would make my job or my function easier. One example is that they have different levels of access within the system and I do not have the highest access, so there are certain things that I can't do. There are other people within our organization that can modify the system or make certain changes, but I can't.

Also, for each one of the user stories, you can throw different tags on them so you can do searches or filters by those tags. Everybody can add a tag, and you can create new ones, but I'd like the ability to go in and modify and clean up those tags.
I've asked to get that access and they said I don't have the right level of security so then, it's a matter of working with somebody back and forth to try to get everything cleaned up.

For example, we have an internal system that we do a lot of work on. It's called Service Desktop. Well, there are about 10 different tags out there for Service Desktop; one of them is "Service Desktop", another one is "SD", another is "SERV D", etc.

Because we have multiple people working on this and they've created their own tags for their own stories on different things but they all mean the same thing, so, to me, it makes sense to have only one so that everybody is on the same page with that same one.

I would like to get it all cleaned up, so that when I do some sorting or filtering or running different reports and I'm basing it on a tag, I want to make sure that I've got everything and I don't even know all the different tags that are out there for Service Desktop.

If I had those abilities to make these changes or create some of the modifications or to build some of the panes and windows that I would like to see, I guess I would probably give the solution a higher rating.

I have not encountered any stability issues.

I have not encountered any scalability issues. We typically pull in 15 to 25 user stories every sprint so maybe 100, 125 stories for a specific PSI, and it has no issues meanwhile.

I have never called the technical support in over three years.

We switched because in my organization we have multiple teams. I'm just on one team, we probably have another 12 to 15 teams that are working on projects, and this is just one centralized repository across our organization.

We have multiple sites, so everybody could use the same thing to put their work efforts into rather than individual spreadsheets where nobody could get access to them.

When we originally got the product, I basically had to take my workload and transfer it into CA Agile Central at the beginning and that took me a few days to get done, but after that, we just built everything right from there.

At my level, I didn't do the evaluating. One of our staff within the organization did. I had no idea if they looked at other options or not but I think they chose CA Agile Central because of the versatility and the ability to handle multiple teams in multiple locations. It seemed to work out to help all of us transform to the agile methodology.

Have a good plan, an overall plan, of the goals that you're trying to achieve. For those organizations that are going into CA Agile Central or going into agile or if you're currently doing agile, then do the following.

1. Go through a process of learning the system or having a handful of people learn the system so that they know it well.
2. Get the system customized because that's one of the strong aspects of CA Agile Central. We have a couple of CA experts within our organization and they connect directly with the folks at CA and make changes from time to time within the system.
3. Get all of your modifications and everything done up front and then start inputting the details and all of your teams and individuals and work efforts.
4. Just start using it!

To me, it was very simple. A very simple type of tool to use.

As a Product Owner/Product Manager on an application team, it was my job to create, prioritize, manage, and accept portfolio capabilities, features, and user stories. The portfolio views and reports were the tools I used the most to do that.

The Agile process my team follows anticipates that requirements and priorities will change from sprint to sprint. Having a real-time view of what has been accomplished, what is in progress, and our backlog, that is easily accessible to all stakeholders, (customers, executives, implementation members, and delivery leads, as well as our staff of multi-discipline Product Owners and Managers) is critical to building and creating a high quality and viable product.

My scrum masters walked through the analysis, development, and testing tasks every day with team members, using the Team Status page to ask each team member (onshore, nearshore and offshore) for status on the prior day’s work and plans for today. As a Product Owner, I monitor User Story status via a Ready To Accept app on my Dashboard for User Stories that are ready to be accepted because all the required tasks are completed.

By using the Portfolio Items page I can adjust priorities and accept completed features from a single page.

It is used as a source of truth on workstream, workstream progress and issue management.

• Bulk priority change of portfolio items
• Portfolio feature
• Dependency reports

In our project, when a feature is completed, we mark it as completed but then don’t want to have it show at the top of the priority list and don’t want to constantly add filters to filter out completed items. So we put the completed items at the bottom of the backlog by changing the priority. There’s no way to do this except one at a time. With thousands of features, this is cumbersome.

There is no good way to get an overall view of feature dependencies except to go to one feature at a time and look at its specific dependencies. The team could have made great use of a report/dashboard of some kind (I failed at coding my own) that gave a larger view of feature inter-dependencies.

We have been using the solution for two years.

Generally, we did not encounter any issues with stability.

There was some slowness noticeable on days of heavy usage by many users (peak usage impact).

I did not use the technical support.

We did not previously use a different solution.

Use relational database concepts to relate items together instead of continuing to use old location-based organization concepts.

• It is easy to use.
• The flexible manner data is entered/viewed.
• Good technical and company support.
• Good range of out-of-the-box reports and easy-to-construct customized reports.

Parts of our business use Agile Central to deliver in an agile and features-based method. It is a much more user-friendly product compared to other products in market.

Pricing could be improved. Compared to JIRA, it is not cost effective for a large user base (1000 user plus). User licenses should be a group level within the company, rather than company level.

Jira is more cost effective once set up – no cost per user seat.

RALLY costs around $60/month/user seat

If you then multiply this cost by the number of users (let's say 2000 – 5000 users), it's a very large amount of money, not effective from a price point of view.

If we could get an Enterprise license at a reasonable price then, management's view of the product may change.

I have been using Agile Central for two years.

It has good availability.

We did not have scalability issues.

Technical support is good. A local resource is always available, is knowledgeable and visits us on site when needed.

Excel sheets were previously used, prior to moving to an agile-based delivery.

Setup was easy in conjunction with technical/local support to discuss the method of working in our company.

There is good pricing for a small number of user licenses (i.e., 50 to 200) for outcome (effective usage including reporting).

We evaluated JIRA and others.

The ability to integrate to the HPE Quality Center is a powerful feature although we haven't used it yet and won't be doing it.

The test case organiser is another useful utility which could help users still using waterfall methods of working if they intend to use it for a while. This functionality is not inbuilt but was showcased by one of their support guys from CA who are happy to share it with customers.

Another notable feature is reporting at Portfolio level, and an organised business area which is set up from scratch with this tool can benefit from this feature. A senior manager will have more visibility as to what is happening in various projects and teams.

It needs to become more mature for large organisations with better integration required to DevOps. 

It has the capacity to let you integrate if you have in-house development capability but not out of the box. 

Solutions are available to integrate it with development tools or Atlassian tools but they are expensive.

I believe Excel imports and the ability to modify workflows are two important improvements which will enhance its competitiveness in the market. 

I believe the feature to use Excel to import issues, tasks, test cases or any other relevant data will be a useful functionality which is missing and many teams are willing to have such a feature. Also, the ability to modify workflows to support custom requirements will increase acceptability of the tool. Currently it has a slightly rigid response to users wanting to tailor the project for their need.

I have used this product for less than a year.

It's a SaaS solution so no involvement in building it up. 

For a large organisation, whether a bank or retail outlet, it has some challenges to integrate with the company's authentication methods. 

Data integrity holds a challenge as data needs to be made secure which takes effort to achieve.

For a large organisation, whether a bank or retail outlet, it has some challenges to integrate with the company's authentication methods. 

Data integrity holds a challenge as data needs to be made secure which takes effort to achieve.

Customer service is 7/10.

I don't know the price but it's certainly cheaper than others.

Atlassian JIRA and HPE Quality Center: They are market-leading tools and still quite competitive with more features to support both waterfall and agile models.

I would suggest to do a comparison chart for your organisation's needs and look at least 5 years ahead for the functionality and budget you are looking for in a tool. Not only the tool cost is relevant but also the resources to maintain it. For a very small organisation, I could certainly recommend a SaaS solution but for an organisation with more than 500 concurrent users, a standalone solution would be more apt, in my opinion.

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.

The tools are not overly complex for Agile. It appears that CA has recognized that. They're not just building the connector for Rally, but they are also allowing other groups to build connectors from JIRA into CA PPM and from other tools to CA PPM.

If you are looking at open source products, why isn't somebody building an open source product so that it could actually do this interface? I build open source interfaces that allow me to get to use different products.

In terms of the APIs, you have consulting companies that are building other products that you buy and you pay for maintenance

In the open source community, they are attempting to tie the old to the new, or they are just looking at the new. In the open source community, there's a lot of need for tying the old to the new. (The old refers to CA PPM.)That's the old way to do project management, which involves governing and controlling.

The new way is Agile. While you still have to do some governance and control, Agile allows you to get away with a lot of things that CA PPM doesn't allow you to get away with.

There is a need to connect these two elements. What I'm seeing in the open source community is more of a focus on the new products.

There is a lot old stuff out here that has to be connected to the new. You can't just ignore it.

The Agile release management is ready to go. When I take this function and try to run it as a discreet element, the other function of the system is rendered as a separate sprint.

All the other vendors wrap around this core. They interface with SharePoint and Clarity. They will also interface JIRA to Clarity. It is a methodology. It is basically taking the Agile methodology, doing some things, and not redefining the whole process. It is, rather, adding some additional components to it, so you can understand what you can do with it, and what cannot be done with it.

PPM: Has administrative overhead associated with the waterfall approach and a lot of DTL tracking.

JIRA: The scrum masters have a lot of flexibility in the sprints in terms of how they actually track work. In financial organizations, or in organizations that are regulated, you need to be able to have that governance component that PPM provides. You also need to provide the flexibility, which is what JIRA or Rally provides. JIRA has been around for a long time. It is open source, so a lot of people have moved to JIRA. It is a suite of products and not just one piece. It is not just about Agile development. It can also do incident management, work configuration, and a lot of other different things.

We have adopted JIRA, as well as Rational. Connecting both PPMs is important, because you still need the governance.

However, we haven't found anything as compelling as Rally. If we didn't have JIRA, and we didn't have other tools, Rally would probably be a strong consideration. However, we already have teams that are familiar with the other tools.

You have intake and change management, which is part of PPM, but you can also tie into it. You have release management and testing.

It would really be interesting to see an open source community that actually focused on how we build the connectors from the old to the new, and then make that transition possible.  Once you build those connectors, you transition the old into open source, so the old goes away.

I was just looking at a small company and their release management. It felt like it was very close to this, but it's the opposite end of the spectrum. They tie in to CA PPM and they do the development and the project management. 

They are doing Agile this way, but they have these other components that they have to put in front of it and behind it, to make it tie into release and change management.

Agile comes at this development piece of work. It's now production ready and I put it on the shelf. Most systems don't allow that. I put it on the shelf. Somebody else develops another piece of work. My piece of work has to come back off the shelf. 

They interact with one another, so I can't just say this one is ready for production, and then that one is ready for production. I have to go into a system test mode, and not just the function test mode. Agile generally doesn't look at it that way. Agile is really built to run on building services.

The velocity of work that we were doing prior to using CA Agile Central, was not quantitative, i.e., we were not able to quantify how many user story points we had delivered or how much work, we were doing.

By using the CA Agile Central tool organization-wide, it gives us a clear picture of how many user stories we can pick and the capacity of the entire team. It is a very good tool; we can see the capacity and the entire velocity of the team. So, this is how it has improved our deliverables. Earlier, we used to deliver in around an 8-week sprint. Now, since our company is using it for about two to three years, the team has matured on the process. They have really improved deliverables and reduced it to a 5-week sprint, that we are giving to the clients.

One of the features that I like is the discussion thread, that we can subscribe to, if at all, someone wants to discuss something. It has to be in that particular feature or the user story itself, rather than in an email. Thus, one can subscribe to know whatever discussion is taking place. So, you can get an email regarding what is new and what has been added to that discussion, which is a great feature.

Another feature that is valuable, since I have used JIRA as well, is in regards to the BQ score, that we are giving after having the grooming sessions. This gives us an important way to evaluate whether a team has understood the requirement completely or not. So, the scaling part as to how the team is doing, is really a good feature.

I can be assured in terms of the rating. Initially, I got a 3 star rating, as my teammates were not clear with most of the things. However, when I gave them some clarification and they are good with it, then they changed the rating to around 4 or 5. This gives me confidence to do a release plan, as my team is very confident and have given me a higher rating. This is a great thing.

The product is really good and there is very little space, as to what needs to improve.

The only thing that I can think of is to improve the section of the acceptance criteria, that is located far below the user story description. Sometimes, what happens is that people who are looking at the user story are not looking at the acceptance criteria, because they need to scroll down to look at it. It would be better to display it on the top, where you can see the user story, without having to scroll down; perhaps, by having another screen where you can see the acceptance criteria field.

For example, from what I have seen often is that, instead of our developers going to the acceptance criteria field after the user story, instead they come to me and ask me where it is. That means, they haven't gone through the entire user story until the bottom of the page. The practice that I have asked them to follow is to read the notes right at the bottom of the user story, so as to access the acceptance criteria field. So, if one is looking at the laptop screen, then there should be a button aligned somewhere on the topmost part, that will immediately prompt as to where the acceptance criteria field is located, i.e., somewhere within the description box itself. So, no one will have to scroll up or down to look for it. This is the only thing that I found that needs improvement; rest of the stuff is great.

We have experienced some crashing instances.

Sometimes, I enter my password; however, then something gets downloaded on my desktop and it asks me to put my password in again for the CA Agile Central tool. Within a two-year framework, this has caused me to log in and change my CA Agile Central password around three to four times. It doesn't give me any notification that the product is down or undergoing maintenance. There are some caution notes displayed as well, such as "This is scheduled maintenance time and CA Agile won't be available currently". However, there have been various instances where people are not getting any notifications as such, and they are being logged out off their accounts.

Sometimes, there are minor stability issues, such as when inserting your password and getting a message that you have to insert it again. We have had some instances where the users are logged out of their accounts.

We have two workspaces and while switching from workspace 1 to workspace 2, recently, we have seen some of the records getting lost, i.e., it was either in the recycle bin or orphaned. This has been noticed for the first time, while migrating workspaces.

Most of the times, to get a report, we are going to user stories and grabbing the columns into one particular view, which we then export to Excel. From there, we get a pivot table, so as to extract the exact data that we need. For example, sometimes, we need to perform a matrix analysis, in order to know how many defects have been encountered in a particular release. In this case, we cannot simply make a comparison matrix chart and but if we need to search it by a particular criteria, we can do that. However, if we want to do a graphical representation/chart of the data, then it will not show that.

I wrote a user story before my PA planning; after my PA planning, 2 got deleted and 3 got added. We want to know from the previous user stories as to how many got deleted or were newly added, in a graphical chart. This is something from the matrix side.

Thus, matrix is an area if CA can improve it, i.e., without having to export data from Excel, we will be able to get the information easily.

Although, it is a manual task, we can get the data easily in a table format. Since it is a manual process, it is not straightforward. However, we do have a large number of users, who are doing this kind of matrix analysis. We have around 52 to 55 product owners, who are managing up to three scrum teams each. Thus, you can take an average of around two scrum teams. At the end of every release/sprint, we are pulling up this data matrix, to know what has happened exactly during this particular release, i.e., where we were good or not. There are charts, where we can do burnup/burndown and have all those variations between accepting the user stories, until the time it is completed.

We need some similar type of matrix for other criteria as well, such as how many defects are there or the BQ scores that have been given to the user stories. For example, if my release plan comprises 30 user stories, then how can I identify out of my release plan, how many user stories are not created well, due to issues such as the requirements were not clear enough or they were too big or did they have architectural insignificance or not. Thus, if we get this type of matrix, then we have the justification for it. However, if we have to pull out the data manually and if, we haven't grabbed the correct parameters, then we can miss out on some of the criteria, for this 30-point user story. We won't be able to pinpoint exactly as to why the release plan has not been carried out correctly.

I would rate the technical support at around 9/10. They were very aggressive in terms of looking at the issue and providing the correct guidance. So, I appreciate them.

In my current company, from the very beginning, they have been using the CA Agile Central solution.

At my previous company, I was using Microsoft Team Foundation Server (TFS) for similar purposes. It was not too friendly. For example, if you are in their UI, there is a big chance that you are going to get lost somewhere and you won't know how to come back to the point where you started. This wasn't very good. Probably, they are not matured yet.

Since I started using CA Agile Central, I found it to be very good in those terms. We have feature descriptions, detailed user stories, attachments, discussions and we can even see the revisions. So, having those features in different tabs gives us a kind of flexibility to look at what is going on and who did what to change it. They could add a tag to see if the user story is of architectural significance or UX significance.

This tool is most productive in my day-to-day job.

The setup is not very complex. As soon as you log in, the dashboard we see is really cool. One would really like to see the graphs and charts. So, that is very nice.

There are many tools in the market out there. I have worked both with JIRA and Microsoft TFS, so it can be seen clearly that the CA Agile Central tool is entirely developed. There is a timebox and a sprint-based UI, as well, in it; it is very easy.

When I used TFS, it was very clumsy and you can't see yourself, returning to the very first point. But, here you have everything; it is very flexible, very simple and decent. You can start anywhere and can return to the very same point, again at the end.

I would suggest for most of the product development companies, if they want to have tracking of their user stories, then use a very simple tool like the CA Agile Central solution. It gives you a number a functionalities, along with a very decent UI. The UI is not very fancy, but it is going to give you a very nice picture of the status, as to what is going on with the features and user stories. So, my recommendation would be to go with the CA Agile solution. It is a very good tool.