Rally Software Reviews

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.

It is a very complete solution. It provides a full solution for us, which is extremely essential.

The principal is because they listen and that helps a lot and the business, this is very important to us.

So far it seems to be doing everything we need it to. We don’t require any improvements at this stage.

So far it seems reliable and we are happy with this product

We are not sure so far on this as we haven’t used it long enough but we hope it will be scalable

They are smart people, knowledgeable and helpful.

It was time to get a product like this in house, previously we were using a local software and it was time to upgrade. For us it is all about the support of the company, and we really like this from CA, they have been very helpful.

It has been a straightforward partnership so far. We are in the initial stages, but all looks good.

I think that you should do some research but ultimately go for someone that addresses what you need and who is able to provide great support.

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.

We have many teams that work on different modules and every team can follow what the other team is doing at the moment, so as to take a decision about taking the user story into the sprint or wait, till the dependent team finishes its work. So, it suits distributed and big projects.

The most valuable features of this product are

• Creating, updating and deleting (CRUD) operations.
• Search for the user stories, defects and test cases (I simple search by the ID and do not often use the Advanced Search option).

These functions are valuable for me, because I do use them every working day.

Probably, the user story history details could include the candidate. Now, it is ugly looking and is not informative. I would prefer to use it to restore details.

I did experience stability issues. 

Sometimes, it has short hanging periods during a planning session, i.e., when you discuss the user story, without the screen displaying the acceptance criteria, mockups and so on.

As usual, there were some scalability issues. If you have many items on the screen, it becomes a bit slow.

Sometimes, the UI is not intuitively understandable.

Make it user-friendly. 

Probably, you can add some UI templates such as a combination of filters/functions, etc.

It helps us organize our projects so that we can get down to really detailed work items; really granular, busting up a task, a feature, and parsing it out so that we really understand what's needed. We can put it into small, bite-sized pieces that can be addressed quickly. If somehow there's a misunderstanding or miscommunication, it can be adjusted and corrected fast and easy.

I'm the subscription administrator. I rarely use it as a user. I generally only use it as a user to troubleshoot. So to me, as an administrator, the most important tool is looking up the subscriptions of my customers to see if they had logged in recently.

To me, the biggest thing I see that needs improvement is the navigation. When somebody's using more than one workspace, it's not obvious how to go from one workspace to another. It's simple enough once you know, but is you're looking at the screen, you don't notice it.

I actually have to write documentation, and I sent it out often to tell people how to navigate from one workspace to another when they're on more than one workspace; in a sense, more than one project, though a workspace is a bigger bite of a project. If you're really just on a different project, and they're all on the same workspace, it’s not a big deal. But when they have to switch from workspace to workspace, it's not obvious. So, that's where I see they could improve in their navigation. Make it more intuitive.

For the most part, stability has been good. They did go through a small shaky patch when CA bought them (Rally) and they decided to move data centers. It seemed like there were some outages, but that has been fine since. It can be a little slow at times, but as far as up time, it seems to be quite good.

I don't know about scalability. From my understanding, we're medium to small in the grand scheme of things. There are much bigger shops than us. But we're not small either. We're in the hundreds. So, it seems like there's plenty of scalability.

I have to say, since CA bought it, support has actually improved; which I'm very surprised about. I found in the past, when it was wholly owned by Rally, they forced you to always go through their website first, search their knowledge base, and then post a case. And then they'd contact you within a day or so. It was okay, but it was less satisfying when that's the only way to contact them; and I always had to go that way.

The technical support seems to have improved quite a bit since CA bought them, which, again, I was very surprised that it has improved instead of get worse. It seemed to be able to handle phone calls better and are even more responsive. I'm very happy.

I wasn't part of the discussion to buy initially. It was already here when I started. It seems that we have grown, though, and switched from other tools. It just seems like the granularity it provides and being able to really be good for development teams and really focus on their needs, and that is why we use it so much and it's growing.

Setup seems relatively straightforward. It was easy to learn. Most teams teach themselves how to use the tool and new teams generally hire somebody who understands the concepts, so just a cursory show them the fields and the setup, and they're good to go. There's nice three- to five-minute videos that CA provides from their website that helps teams understand the concepts and the usage.

Just be open and take advantage of the videos to see if they understand what the product is and to reach out to the vendor and ask them questions. They seem very willing to help without necessarily charging. If they feel that you're a potential customer, they're happy to talk to you and give you some guidance. If you need a lot of help, then of course, then they have programs to actually send experts.

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.

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.

I am from the QA team and am using this especially for test automation. We have so many test scripts and this would take some time. Earlier, we used to have a different tracking system, but the difference is that, if there are any new changes, then it was very hard for us to get them into the system. However, with the CA Agile tool, we were able to have two-week scrums and two-week sprints. After each sprint, we were able to pull any new tricks that came up and we could easily prioritize, prior to the two-week period, instead of having to wait for a long time. We were able to easily create and track the user stories. We were able to understand the graph as to how the trend is going, so all this was really helpful.

I find that tracking of all the user stories feature is extremely beneficial, because I can know in terms of the user stories, how much work is completed and how much is still pending in the backlog.

During the last four years, there were four projects in there, that I was handling. However, one of the issues that I am facing is how to remove the old projects, as one of the projects is over. Although, CA Agile is still showing me all of those four projects and I don't want that information now. So, there should be a way to remove that project.

I am not sure whether CA has their own bug tracking tools. However, if there are some tools like that, then it will be very much helpful, i.e., to have one integrated system, where the configuration management as well as this bug tracking tool are integrated. Bug tracking we have with NetApp's internal tools, but I don't think we are able to do the integration between CA Agile Central and what we have.

So, it would be good to have one single complete solution for complete development, such as for tracking agile work, the bug tracking tool, and Perforce management, the version control system. Thus, an integrated system would be very much useful, I think.

I am not sure if CA has the integration tool part, currently or not; however, I am unaware of that. Hence for me, the integration between other tools will be a very useful add-on feature. In the market, there are other tools that are available as a complete solution, providing tracking tools, bug tracking features and necessary support as a package. If CA Agile Central could also provide that kind of integration such as the bug tracking, a version control control system as a single solution, then it will be very much helpful.

Sometimes, we have noticed that our CA admin sends out an email, maybe that could be in regards to the maintenance work that is internal to the NetApp.

There weren't any scalability issues. For my work, it is perfectly suitable as of now, so I don't see any scalability related issues, for my work as of now.

If we experience any issues, then we have the NetApp internal support and will basically reach out to them. Thus, we don't directly contact CA Agile Center support, as we have enough people internally to get NetApp support. I would give them a 8/10 rating.

Initially, I was using Microsoft Project. Since it was not compatible with the agile environment and we then started using the agile methodology in our project, we started using this solution. Also, NetApp is providing support for this tool.

The setup was simple but I also remember that the one thing that is missing in CA Agile Central is the integration of data, as when you compare it with Atlassian JIRA or similar tools.

I did not evaluate other options because my company is providing the tool. I believe that before choosing it, my company may have done some kind of comparison with other tools, and then selected this one.

More than a team or a manager decision, this was a company-wide decision.

This is a very helpful solution, especially for those who are planning to switch over to the agile environment. Although I have not evaluated any other tools, I do have experience with other tools as well, but I have never compared both of them.

This is a great solution, especially in terms of the graphs and how the trend is going on. That is the one of the main features, which is helping me a lot. During a two-week sprint, if I look into it, I can exactly know where the trend is going or whether all the work is getting completed or not. Thus, it provides a good forecast as to how much of your work is getting done or is still pending. This is a good positive aspect to suggest to others.

I don't know which feature would be more specifically valuable. I guess the portfolio items would be the ones I use the most, but I also am very familiar with the quality module as well.

Some of the reporting stuff would probably rank right up there as well. Those are probably my top three.

I think what it's helped with in general is that we've learned a lot about how to break things down a little more in detail. Going from primarily a waterfall organization into an agile organization, the tool has been very helpful to help people make that transition.

It's a relatively slow process, unfortunately, as it's a large organization we're dealing with, and everybody interprets things a little bit differently. We've had some people that have really spent a lot of time with the CA resources, who really understand the product and help the users use the tool effectively.

I think one of the things that we stumble upon is how to organize the teams. We have one overall workspace, but outside of that workspace we have many, many teams underneath it. I think you can organize them in two different directions. You can organize them by leadership or organizations, or you can organize them by, for lack a better term, product. And those two don't sync together, because you have many organizations contributing to a product that don't roll up to the same leadership level.

So from a reporting aspect, for different things, we struggle trying to get that balance; to get the reporting for the leadership side, and then get reporting for the product side. That is one aspect. It's not necessarily a hierarchical issue, it's a flexibility issue, if you ask me. If you put it in one direction, you can't get it to the other. So you need to be able to balance it both ways. That would be something I think that could be worked on.

I have been using the solution for more than three years.

I personally haven't had any stability issues. The only time that it's been a problem for me is when I've extracted data around test and defect information. The extraction process has to be broken up; you can't do it all at one time. It's not impossible; it's just a little more work. Whether it's just because of the amount of volume we're talking about, or if it's just that there would be no way to fix that, I don't know.

Specifically, in our case, we're getting very close to the millionth test case written in the 3+ years that we've been doing this, and that's a lot of data. But you can't extract it all at one time; you have to break it up into chunks.

I personally have not encountered any scalability issues.

I would rate the technical support at 9/10. That's a very, very strong nine. We work very closely with some of the technical support people, and have for a very long time, and they are great partners.

I think what they do today, especially with their tech support side and the relationship we have with them, they are very open, they listen, and we understand that we're not the only client. We know what our users come to us and ask for. We take that information in and compile it, and have conversations with CA Agile Central, saying, "Here's what we've come across," and they've actually been very responsive to some of the things that we propose.

We know we can't get it all, because they have to make the tool useful to all their clients. So we'll present what we think is viable, and it's just like anything else. Some of it makes it, some of it doesn't. I really can't ask for anything more than what they do. They're very open, they will listen, and they will do it if they can. That's fine by me.

This was the first Agile Central tool that we used on a grander scale. Again, we switched from a waterfall organization to an agile organization, and this tool doesn't support waterfall.

I wasn't involved in the setup process.

I am not involved in the pricing and licensing side of the operation.

I wasn't involved in any such evaluation.

I have had some experience with one of the other tools out there and personally, I like this one better, so I'm a little bit biased around that aspect. If somebody were to ask me, "I'm looking between this and that ...", if I know the tool, I would have my biases towards CA Agile Central, for sure. I think it's a pretty good tool.

Previously, we had an in-house solution that was very difficult to update and customize. Thus, when we had acquired new businesses that we were working with, we weren't able to add the right type of information that we needed or get the right type of support and customers. We weren't recording half of all our new work that was coming in through my team because we couldn't do it. So, when we started using CA Agile Central, those changes could be made in a day or two and we had better data integrity, than my team had ever had before.

Since we went through a series of work changes in the last two years, the most valuable feature is how easy it is to customize it. The ability to customize and change the processes really quickly, so as to respond to what the changes of the organization and processes, were the most helpful.

It takes a very long time to load and, if you make some small changes, then the whole page has to reload. I know that's a major frustration for a lot of people using the tool.

I know that they're constantly updating and providing new features. As I have mentioned elsewhere, I set it up for two different teams. By using it in it's most standard and straightforward route, it is definitely a ten out of ten. However, working at the portfolio feature level, which is what my main team did, there were some functionalities that were missing and over the last two years, I've seen more and more of it come along the way. I would have liked to have the same development support at the portfolio feature level as well, that I was seeing at the user story level.

We are facing some stability issues. This is a pretty regular occurrence, especially when using custom reports.

I've not necessarily put the scalability factor to test yet, but the nice thing is once you have a small handful of people using it, the number of people and information in it has tripled over the last couple of years. So, it was scalable for us in that sense and then, also in terms of the number and diversity of customers, as I mentioned. It's been good in the sense, that we've needed it but I don't think we've really put it to the test.

I had a question when looking into custom scrums and I think, the overall community for CA Agile Central is incredible. Not only does our organization have people here, but there's a wealth of information online as well. When we reached out for technical support via the CA Agile Central team at our organization, when we had some particular requests, they were absolutely incredible. We really liked the tool because it's really easy to learn and there's a really good community.

As I have mentioned eslewhere, we had an in-house solution and before that, it was all managed via Excel spreadsheets. Excel was the worst of it all. The in-house solution was only good enough maybe for the first couple of months, until one or two or more changes came along, that we couldn't afford to keep up with. That's definitely one of the main reasons as to why we switched, since we couldn't keep up with the updates. If we say that CA Agile has stability issues, that again are not poor, but it just takes a while to load, then, our in-house tool was significantly worse.

I thought that the setup was very straightforward, but we also had people on the side of our organization, i.e., a dedicated team, to help get everything set up smoothly. My team intended to change a few things about how you would traditionally use the product. I set it up for two different teams. When I used everything in the straightforward way, it was very easy. When we were modifying and customizing some things for my team, then it got a bit more complicated; just to get my head around the rules and then, having to manipulate them. So, the setup is very easy when the product is being used as it's meant to. When we were manipulating things, it got a little more complex. However, we were able to work through it relatively easily, because of the support that we had.

I evaluated about half a dozen of the other vendors out there and one of them was JIRA, for portfolio management. JIRA was the other top competitor, although we did evaluate other small vendors as well. CA Agile Central was much better. We actually had a relationship on JIRA's side, but I was the first one to venture into the CA side, as we didn't have the relationship in my team. However, CA Agile was just a far more superior product, as compared to what JIRA was able to offer then.

It is important to truly understand it! In order to use it the best way that you can, you really have to understand your process, terminology and the way that CA Agile Central is meant to be used. We had a lot of issues with the terminology; for example, at what level should we be, does this count as a user story, does this count as a feature, etc. So, it is crucial to really do all that work in the beginning and to map out everything meticulously, so as to make sure that the definitions are clear. After that, setting up of the process becomes much easier; but, if there's a lot of back-and-forth in terms of the definition, the setup and adoption will be much more difficult.