Rally Software Reviews

The Portfolio is the most valuable feature that I found, because it allows us to drive our requirements along with planning at an enterprise level. That helps a lot. Along with this, there are other valuable features, such as Timebox. It provides proper cadences based on the Timebox that we work with. Those are the two features I find most valuable.

Agile Central is an enterprise tool, so it allows our teams to work together. Individual teams don’t work in a silo. Agile Central allows us to drive all the metrics at an enterprise level. We can then discover what needs to improve at the enterprise level, instead of looking at it on the team level. We are using it for our Agile project delivery.

As I've mentioned elsewhere, Kanban needs to mature a little more. The product itself is focused more on the scrum, but they need to go forward. Also, they did a pretty good job on the scaling side, but they could improve.

Stability is pretty good. It's improved from the past. Ten years ago, I was using this product. As a product, it got better over time.

Scalability, is good, but needs some improvements on some other aspects of the framework, such as Portfolio Kanban. It requires a little bit of work, but we can make it happen. It’s the best tool.

We have ASP service with CA Agile Central. It is kind of technical support, but it is personalized support that we could get for the company.

Our business has been using Agile Central for five years, but I have been using it for almost 10 years. I see the evolution of the features that have come along, as well as the product overall, making this an option that allows me to take it to the next level.

The most important criteria when selecting a vendor are the sustainability of the product, their reputation in the market, and pricing.

I have been part of Agile Central since the get go. Initial setup is straightforward. It is software as a service, so it is very easy for us to set it up; the project and initiative.

The tool is amazing. If you want organized, overall delivery at the enterprise level, this tool allows you to do it for sure.

There are a couple things that our company found really good. One is that it’s scalable, and a lot of the other products on the market for us don't scale. We have close to 20,000 people using Agile Central. So that was one of the keys. Within the company developers, they all have their preferences. So some like JIRA, while some like Agile Central. But from a backend environment standpoint, Agile Central can actually scale for the whole business.

Agile Central helps in terms of Agile management, especially with our scrum teams. It's designed to be used from an Agile standpoint, so I think the teams that have struggled with it are the ones that aren't really set up for Agile. Agile Central is really founded as an Agile tool, so if you're not doing Agile, the tool doesn't work all that well for you.

Our company is large and we've got a very wide gamut of Agile maturity. We have some teams that are very expert in Agile and we have others that are still Waterfall. It's a 100+ plus year old company, so it runs the full gamut. Personally, I have been using Agile for a couple of years, so I'd say I'm pretty familiar with it at this point.

We've been asking for a couple of things. A big one for us has been on the administrative side. Again, I'm coming from a very large company so these are the things that are, at that scale, very important to us, such as access. How do we get access to people? How do you move a large number of people?

The other big one that we've been requesting for years is the ability to move people between workspaces. For us, that's really important. Every time we've had to do this, we have to get technical support involved and it's just a big pain in the butt. Within Agile Central, each workspace is very independent and one workspace can't talk to another workspace.

We have multiple workspaces set up and when a team wants move from one to the other it's very difficult to do. For instance, with a big organization you're always going to have organizational changes. So you may have set the things up perfectly when you first set it up, but things change. Now when they go and change, since we can't move workspaces easily, the new teams that are together can't collaborate because they're in different workspaces. There's no easy, functional way of doing it.

I also think the UI could use some improvement. I believe they're working on it. Also, it's not the most developer-friendly tool. So while management tends to like it, I don't know if developers are huge fans of it, at least in my business, from what I've seen.

I think stability has been fairly good. I don't know whether to attribute the issues that we've had to Agile Central or to our own network. And we have had issues, but they've been pretty quick to respond and try to come to the root cause of what's going on.

We've had some scalability issues but, to be honest, because it's a SaaS product, I'm not sure if it's a function of our network or Agile Central. Sometimes it's difficult to tell, because we've got a lot of internal networking that we're doing in terms of security, etc., that slows things down. So when we have had complaints about it, a lot of times it may be us that's at fault and not so much Agile Central. But, an important factor in choosing Agile Central was scalability.

We actually offer both JIRA and Agile Central within the company. So we try to somewhat make it a user choice as well. What we typically recommend is that if it's a very small project and it's a quick turnaround, JIRA's probably your best bet. If you have something longer term, Agile Central is probably going to be an easier tool for you to use.

I wasn’t involved in the initial setup.

We didn't evaluate anything other than JIRA and Agile Central.

I think you have to think through how you're going to organize, especially if you have a large company. We've struggled with the structure of our teams and the way they're set up. So that's something you need to consider. And I don't know if they've done a great job of it. They actually call teams “projects”, which is a bit of a naming issue.

You definitely need to have some foresight when you set it up in terms of how that's going to work. You also need to think about how you're going to do workspaces, because there's no functionality there to change it once it's set up. You've got to get that right from the get-go or you're going to have a lot of trouble going forward.

The best feature for our company is that it's easy to use, and it integrates with our other solutions, such as the code warehouse, the test solution, and the deploy solution. We wanted an ALM product that was easily integrated, because we have 170,000 users in my company. We need a strong solution to support us. We must have:

• Ease-of-use
• Easy to integrate with other solutions
• Good stability

I don’t know this product well enough yet to offer suggestions for new features. I recently went to a conference to learn about CA Agent Manager as well.

See below regarding stability.

Stability of the product is not good. It is critical for us to make the solution stable.

CA Agile Central scales very well. We have 170,000 users.

We have not used technical support. We bought the product and were ready to work with it.

Initial setup was easy for me. A consultant came to our company to sit with our people.

The ability to extract data to provide feature and release metrics for our executives and our customer stakeholders is very important. It provides reports on the cycle time from the time that feature requirements are initially defined to when they are available for release. Release in this case does not mean production, because it does not include that capability.

For me, it's important that it supports both an agile scrum and a Kanban implementation. I've had responsibilities for operations in the past in which people were trying to force the operations team into a scrum implementation or methodology, that doesn't work in an interrupt-driven world that you have sometimes have in production when you have to deal with production issues. 
 

• By using this extracted data, it provides a real picture, instead of a perceived picture, of the amount of work the team is doing, the time it's taking to get new changes out, ready to put into a user acceptance test area, and production, which is really where our problems are. It's not solving those problems right now; but it is providing data that I use to present data on the deployment delays. For example, we can see that we’re finished at point A, but we're not actually deploying it to a production environment until point B, which is sometimes only three months later. So there is a delay in getting the features that customers want to production. This is because we lack a DevOps culture. CA Agile Central is giving me real data to show that for many features. 
• Our company implemented the scaled agile framework. I believe they've created a heavyweight bureaucratic implementation, and I think they have some work to do there. It’s putting wear and tear on our team. We just did a total pivot. With scaled agile, we work in three-month program increments. I'm actually used to planning out that long, but we had a business situation that came up in which our whole department did an immediate pivot; so we are pretty agile. I just think that we have some work to do on the wear and tear on the team.
• I think I have a great handle on agile methodology, but I haven't done any portfolio management using agile tools. 
• Our team’s agile knowledge is intermediate, but they're learning; and they're learning on their own now. They actually understand their limitations. When I started, they had been doing the whole methodology for a couple of years, but they didn't realize where they had opportunity to grow, which is one of the reasons why I was brought in. Before, they just needed to be directed.
• For people outside my team, we created a scrum master guild, and we use that all the time. One of our best practices is that we created agreements across all of our teams regarding how those specific teams work. Those agreements are not the same on every team, which I think is exactly the right way to go. It is definitely a positive change for the organization now that each team can provide information transparently to executive management. Everybody seems to think that’s a good thing.
• We also do a retrospective across our teams, which I think is very open. That's pretty refreshing to see.

• I would like them to give me back the fields I used to have. We lost the release field because they mentored our scaled agile framework trainer to actually use the release field as what I would call a program increment.
• We're releasing every two weeks, so it's pretty hard. They also should put a product field in there. We have work areas. Our work area is our team, it's not our product. So my team actually supports four different products. I'm doing name mangling that I then have to write code around to understand how to get metrics out. That is challenging.
• The other thing is that I think I can pull out data from the release, but we're not using all of the CA Agile Central projects. For example, we're not using the testing part of it. We do use the defects. I don't know how I'm going to integrate the testing tool that was selected by the test organization. I don't know how I'm going to integrate all of that. They might have plug-ins for that. I don't know.
• The only thing I can think about is finishing the lifecycle. There are tools in there, and I don't know how I can close the loop.

I have been using Agile Central for 10 years. At my last company, I had access to just go in and look at everything, but I don't have admin access at my current company.

Our product is doing very well. We had one production issue in the last three months, which is pretty good considering how large our customers base is.

We launched our product in April or May. We had two or three issues in the first month that I think had to do with the whole DevOps theme; and how it was configured and set up. We are working really hard on the DevOps side, but we have some work ahead of us. We’re not there yet. But we haven’t had any real software problems.

We're able to scale as much as we need right now.

The initial setup was complex. We have a lot of different internal and external integrations.

I wasn’t there when they selected it. However, I will say that having had the scaled agile framework, I'm a little disappointed at what it looks like in comparison to something like AgileCraft.

I think that they have some work to do on the scaled agile framework side. I don't know if they're doing it because I'm not in those discussions. 

I haven't really looked at any other vendors. Someone just sent me a link to AgileCraft. That's the only reason I mentioned them, and I don't know if it works. I just saw the “marchitecture” stuff.

I fully support CA Agile Central as a product. I would guess that I also support their scaled agile framework Implementation of it, if you go in with your eyes open and have honest discussions with the CA Agile Central implementers.

We do technical support and even more than that. We do what I call operational monitoring. We have an operations team on one of our products; on the other product, we don't. We're the operations team.

We actually just instituted a new process that we're implementing. We go out and check each of our environments every day. We are always deploying to QA, and always have something in our user acceptance testing area and in our production area. We look at all three of those environments. Any problems we see, we immediately investigate.

I think that's how we've been able to prevent some of the problems we were having. At least the development team is doing that. The operations team has their own methodology.

It allows me to do large team planning operations, where I can do "big room planning" and have all of my Agile teams in one session. We can get through all of our planning through the use of the software. With big room planning, we can get it all laid out, understand what the dependencies are, where the interlocks sit, and which sprints can be optimized. The portfolio tracker tool is phenomenal. It gives us the opportunity to look at our features holistically across the entire landscape of the solution, where they fall within a continuous delivery (CD) release when you're looking at a DevOps model. It allows us to apply those features to the DevOps model. I can take that and apply it across all of my teams, look at it when we can pinpoint exactly when that feature is going to be delivered holistically. This is a huge value to our client, who is Cisco.

We can have high predictability, which is what Agile tries to do. We can have low cost of ownership, dealing with “just-in-time” delivery for the monthly releases, because we release on a monthly cycle. We can look at this information and say when those features are going to become available. The portfolio tracker is huge, a phenomenal piece of the add-on functionality that's been wonderful.

I also like the use of apps, and the ability to use the customized HTML capability of the apps. We're working with the consultants to design a custom look and feel for specific types of reports that we need. It's very open architected, so we can take advantage and utilize the software as we choose to use it, and have a really good experience with it.

There's some room for growth. There's some more functionality we'd probably like to see in it, but at this point, it's been a stalwart product for us.

It's optimized how our organization runs. We can look across multiple teams, using Scaled Agile Framework Methodology (SAFE), so that we can look at various release trains, and how that then flows up to the overall program budget. Each train has its own unique budget line. I can look holistically across all the trains and have it flow up to the program office’s budget. I can track personnel within the software. We can do all of the quality functionality and spread that across multiple tracks. In this way, one track is not going to be heavily burdened by taking on the quality function.

The big value add is not only the ability to do Agile, but scaled Agile as well, utilizing the budget functionalities. It’s really top notch in that regard, with the ability to work with the personnel function of the software. It gives us another holistic view of the overall functionality and operations that we have providing a value add to our customer, Cisco.

The main area to improve is performance. If they can get that performance improved, they'd be golden. They really need more in the DevOps modeling, and the use of Kanban. Their Kanban area is fairly weak. That's probably the one area of the tool that, outside of performance, really needs improvement. If they could add more robust Kanban functionality, then they would have the best of both worlds. You would have a DevOps capability, Scrum capability, and Test Driven Development (TDD) within the tool.

That would also help from the quality perspective. When you're dealing with your DevOps team, especially when you're trying to do releases on a monthly basis, they need to be tied into deadlines and be able to track through a Kanban mode. They need to know about the workflows, the work in progress, and how it moves through the workflow. That would probably be one of the main areas I would tell them to put some energy into the Kanban side of the tool. If they did that, then they would have pretty much the complete solution. They are losing a lot of business to Trello.

There are performance issues that nag the product. I would like them to build out a more robust Kanban workflow methodology system. Then, I would open up the APIs more. I would allow for third-party solutions to be able to plug in easier. There's a little bit of work that they'd need to do.

There's a couple areas where that they can make significant improvements, and I'm sure they're working on it.

Stability is very good. The solution rarely goes down. When it does go down, we make a couple of phone calls and we get a really clear estimate of when it'll be back up. We get e-mail alerts when things aren't going too well. The biggest issue that the product needs is to improve is performance.

Ever since the Agile Central package (formerly Rally) came out, performance has always been an issue. It lags behind, at times, especially when generating large reports. That's probably the number one area for improvement. They know that. I'm telling them nothing haven't heard before. If they can get performance at a much better level, I think the product would be really well received for other companies, who tend to shy away from it from a performance perspective.

One of its main competitors, AgileCraft, is a high performing product. It's got really good performance. They really need to be competitive with some of the other products on the market. I have used it extensively. It's a great product. Its premier focus is being a safe solution, where Rally tends to be a Swiss Army Knife. It's more for all encompassing type of Agile work. Whether you're doing SAFE, standard Scrum, Test Driven Development (TDD), Feature Driven Development (FDD), these are all areas for which Rally can be utilized. That's what makes it a very multiverse tool and allows you to work holistically across an organization, where AgileCraft has a very specific, narrow focus.

Scalability is very good. No problem there. It will scale as you need it to. That's not a problem.

I personally haven't used technical support. My interaction has been through our consultant. We have a dedicated team of consultants with whom we work. If we ever run into an issue, we usually just pick up the phone, call our consultant, and explain what's going on. We do have support through a Cisco support group. They're extremely responsive. When we run into a problem, they usually solve it within about an hour or so.

Vendors who were on our shortlist were JIRA (Atlassian) and AgileCraft. At the end of the day, we chose Agile Central, mainly for its robust capabilities and the ability to talk to other database systems. For example, I can bring in all those JIRA defects or issues, into the CA central product, because of the open API architecture. Using the SOAP API codebase, I can then have one of their consultants write me a custom hook that allows me to bring in all the data from those other databases. The other two solutions didn't have that open-ended modular framework that allowed me to pull in information from older systems, whether it's coming out of Excel spreadsheets, or older systems, like JIRA. That's one of the big things that we look at.

When making a decision to switch products, I consult others on tool choice based on the number of departments they have. I went in as the Agile coach to Cisco and recommended that they move to this solution. One team I was working with used JIRA. It's an option that Cisco allows some of their departments to use. I got them out of JIRA into Rally, mainly because JIRA is older technology, and it's too lightweight for a major corporation such as Cisco.

This tool allows you to talk to the rest of Cisco. If you've got one group running one solution and you've got another group running another solution, they can't speak to each other. They can't share data. They can't assign issues to each other. By moving one off one platform and moving them onto Rally, or to Agile Central, we can now holistically start to work across organizations, and see each other's problems.

The only other big issue is their workspaces need to talk to each other. That's another area for improvement that would be good. There are a few areas they had to work on, but cross-workspace communication is the main one. If they could solve that problem, that would be amazing. I would be so happy. Even in my own group for which I'm providing consulting services, we have multiple workspaces and we can't talk to each other. That can get a little crazy. We have to create this third solution that we all feed into. Obviously, nobody pays attention to it, because everybody is so focused on their own lane.

In terms of selecting a vendor, I look for the responsiveness to quality concerns. Whenever you've got an issue, the timeliness that they'll come back to you to resolve those technical issues is important. I also look at whether or not they have consulting services themselves for customization work The other part of it is just overall “solutioning”. I want to know if they have a complete suite of products, or if it is just a standalone, a one-off. If it is, then I have to go bring in three or four other additional products to augment the single product. Then you've got multiple bids and you're talking across multiple vendors, and that can be a headache. I just want to do one-stop shopping.

That's what CA provides holistically across the entire platform. They're going to give me everything that I need. Another factor is with one vendor, you work on better pricing structures and a better deal. Whether it's in service, or getting a discount on other products, you can weave all that in as an opportunity going to one vendor.

My advice to other is take a test drive. They have a sampling system that you can demo. They'll give you a space to put your product in and try to go through the whole workflow process. Make sure you go through the whole workflow process. Really see and understand exactly the functionality that the solution has to offer. A lot of people stop at the very top level, the one-inch level. Go underneath the wave and dig down into the solution. There's a lot of great opportunity there.

One of the neatest opportunities, because of its HTML capability with its apps, is the ability to embed a lot of my Smartsheets right into the solution. I can take team rosters and embed them. I can track monthly performance reports and a number of different functionalities that are available to me via the Smartsheet. I can update my Smartsheet, and it'll automatically be reflected in Rally. That is huge in the CA Central product. That's significant for me.

For us, the most valuable feature was writing all the stories. We found features such as figuring out what stories are going to get into which sprint and organizing the backlog and dependencies, to be useful to us.

In terms of improving the organization functions, it gives us a lot of visibility as to what features are getting released and when. It also helps us to track across the organization in a much better fashion. In my opinion, visibility is the biggest benefit that we have received from implementing CA Agile Central.

We would probably like to see a more robust dependency management system.

We have not experienced any issues. So far, things have been working fine for us.

We have started a little slow. There are just a couple of teams that are using CA Agile Central, so we've not really scaled it up for multiple teams across the organization. However, within our group there are 3 or 4 teams that are using CA Agile Central right now.

We've not used them so far. Thankfully, we didn’t need to use them.

We were not using any other solution prior to this. Since our organization was moving to agile, we evaluated a few products and CA Agile Central seemed to be a good option that would fit all of our needs; so that's how we decided to go with it.

Not me personally but there was somebody in my team that was involved in the initial setup. We did not encounter a lot of issues or challenges.

Of course, we had to pull some experts from CA as well just to get their ideas on how we're supposed to set it up, how things work and what are the best practices to follow and so on.

Other than that, the first couple of iterations/sprints we had to learn and tweak a little bit as part of retrospectives. Otherwise, it has been okay.

Initially, we looked at a couple of vendors, namely Pivotal Tracker.

You need to clearly know what you want or how you want to implement and use the product. Once you have clarity then you can figure out how you want to setup the solution and go from there.

For us, the user interface was the most important criteria while choosing a vendor. We found it to be more intuitive than the others. We also felt that it can probably scale up to the needs of what we have within the organization, in terms of integrating with the rest of the ecosystem.

Agile Central has really helped us document our Agile requirements. It's really strong in terms of being flexible and how it's set up, getting a team organized quickly and easily. In our particular organization, we're responsible for maintaining the tool portion of it. We are not so much involved in driving the development of the individual applications, so from a maintenance perspective, we kind of admin the CA tool. Agile Central is what you'd consider an Agile management tool. It's a way of logging and storing your requirements, defects, test cases and things like that in a collaborative and Agile fashion. Everybody can go directly into one tool, see what's going on, and track their respective status.

The biggest benefit that we've found has to do with the ease of use. We can get into the data and actually report out of it. Historically, we'd gather requirements in Word documents and things like that, so moving to a tool where you've got easy access to get to the data was a big win for us. The reporting in the tool is pretty good at the team level. It struggles a little more in a big organization. We are trying to look at things across all of the teams, trying to do reporting across the whole tool, so it's a little less good there, but overall it’s pretty nice.

In the next version I'd like to see more of a focus on reporting at that overall level. I want to find a way to do analytics on what's going on within the tool, how many people are using it, and not so much detailed reporting on individual teams. I want to see how the organization is doing as a whole as they use the tool.

As an example, one of the metrics that we'd like to be able to see has to do with this idea of teams that are meeting their commitments when it comes to deliverables. So when they come in to start a sprint, we'd like to be able to say "By the time the schedule ended, you hit this many of your stories, or features." And we'd like to do that, not necessarily for a specific team, but on the whole tool overall. We want to be able to compare between teams, and say "What is this team doing that's better, what is this team doing that's not." I think they could really do some work on the overall analytics. There are parts of the UI that could use a little bit of work, as they are older. It would have to do with changing the analytics and a little bit of the performance.

Stability has actually been really good. We use the cloud service, and while it does go down occasionally, they're on it and it comes back up right away. No major complaints there.

In terms of scalability, we're a pretty big project, with thousands of teams out there, so sometimes we feel like we're pushing the tool to its limits. We start to see slow-downs in response time, and things like that, but it continues to function, for the most part. We'll see as it continues to grow. It usually shows slow-downs in the UI, or particularly in the web service interfaces, that are trying to fetch out data for large projects with thousands and thousands of features. Things can be slow because it's a lot of data to move.

We do use technical support. We are engaged with support and we have several open tickets. The technical support has actually been pretty good. They're definitely responsive. Some of the problems that we run into are a little more difficult to solve, so the response time's not always there, but for the most part, it's good.

I would definitely tell them to make sure that they plan out what it is that they're trying to accomplish with the tool. Making sure that they get a good structure set up, and if they are trying to manage multiple teams, try to establish early on what those teams will look like in terms of size and what they will be doing.

One of the pain points that we see in having so many teams, is that every team has its own slightly different thing that they're doing in it. This is great from a tool perspective that it is supported, but from a metrics and reporting point of view, that makes things difficult because not all teams are doing the same thing.

I think what’s great is the ability for teams to really plan at the team level. CA Agile Central does this very well without much overhead. This allows our teams to really focus on the work, as opposed to the administration of the tool. I think at the team level, that's the most valuable.

At the portfolio level, what’s most valuable is being able to manage the visions, the features, and the releases; it’s very easy, simple, and straightforward to do. I think there's good value, as well, by bringing together the business vision statements and what IT is thinking in terms of delivery, and what's possible in terms of capacity. The objects within the system are integrated well enough to allow for really smooth end-to-end planning.

It has improved the organization's functions by eliminating time wasted waiting for someone to have a prioritized list on their laptop or on some SharePoint site that to which we then have to get access. All of this is simplified and we're not wasting time looking for information. Everything is right in one place, correlated, and related in the right way, and at the right level that allows for planning, execution, and tracking afterwards.

We have pockets of really good Agile maturity in the company and some pockets where more maturity is still necessary. I think the bank as a whole is still maturing in terms of agility, and it's ability to adapt to change. I would describe it as just pockets at this point, but growing very, very quickly.

We use Agile for coaching as well. We try to coach to a few things. One of them is, of course, business value; to say, "hey, focus on delivering high business value first". So again, we are able to take advantage of the prioritized lists at all levels within the tool.

This applies to transparency also; making data visible at all levels and to anybody who is a stakeholder or part of the team. The information is right there, and everybody has the same exact view given the access that they are granted.

We work on predictability also. You're able to see the level of velocity that each team and each release has very quickly. You don't have to go and search for data. When talking about improvement, it's more of a process that we coach. But, enabling those types of conversations around continuous improvement based on accessible, real data from the system is invaluable.

We're focused on multiple areas. We are trying to get teams to think about the system as a whole and not just their small areas. We're trying to get end-to-end visibility of how efficient we are at doing our work. That's where we coach.

We have submitted lots of ideas to the Ideas portal, such as milestones. We would like to make sure that that's a first class citizen, if you will. Make it a little bit more robust regarding our API plans. Reporting I think is a big one too, especially at the bank.

We base a lot of decisions on real data. So if we're not able to get that real data in a very simple way and be able to slice and dice it, then we aren't as effective as we could be at making those decisions quickly. I'd like to see a reporting interface that is easy to use, based on report templates that we can take advantage of.

Lastly, the Insights module within the tool was great when it came out, yet very few people harness it's power today. I think it could be more integrated into their reporting interface, if it's possible. It would really drive true insight right into the data that we are creating around our work.

I think the CA Agile Central is pretty stable. I've used it for over 6 years and it's fairly stable. We use it on the SaaS model. The website says 90% up time, which is fantastic. No real major down times that we've seen.

We use Agile Central at scale already. The tool is being used across the entire bank and across the world. At last count, we had 7,000 or 8,000 people using it across multiple teams in multiple organizations and these are active licenses. I believe we are already using it at scale in a very real way to deliver value.

We have worked with technical support when we have questions of defects. They are very responsive. They approach their work with an open mind or open transparent setup, where they're sharing the latest information and where things stand in terms of questions, or defects, or enhancements, if you will. Overall, we have no complaints at all, from my perspective at least.

I don't believe there was a previous solution in place for Agile teams. Some teams were using Atlassian JIRA and then some are still using version one, but that was in parallel and not a replacement.

I was not part of the initial set up, but I have been a subscription administrator and I'm aware of what goes into it. It's not overly difficult. I think working with the CA setup team, makes it very easy.

When selecting a vendor, the ability to integrate with other internal tools is first. I also look at the stability of the brand and extensibility in being able to extend out. Of course, meeting our minimum needs is a given, such as being able to track and report on data. I want to know how robust those items are. I think most products provide those types of functions, it's just how robust they are and how high a grade they have in terms of being able to deliver that functionality. That is what differentiates vendors.

My advice to others is to start right away. Learn as much as you can. The tool itself is not going to be your impediment or your longest pole in the tent. It’s going to take a long time to figure out what your internal culture and processes are, and the tool is only there to help you reflect what you are producing. So start early.

Being able to control the requirements through the change request lifecycle is one of the most valuable features.

It optimizes the time to market of the requirements.

There should be different ways to decide on the requirements, not only by using a flow chart. There should be more than one way; maybe with use cases or another more graphical way to represent the business requirements.

I wish there was a way to maintain the documentation, the knowledge management of the development team; and to keep a live version.

The stability is very good. There are no crashes.

The scalability is very good. We are planning to complete the whole lifecycle of development activities.

We use technical support a lot. We have our partner, and we use support with them. Technical support is excellent.

We considered IBM Rational.

We have a lot of requirements. We have lot of business areas that continuously places demands on the IT group. We need strong tools that help us keep correctly the requirements in the lifecycle. It's important. It's not enough to do things better. You need to have a better tools. We have a lot of delays that we want to mitigate. We don't have a good time to market. Agile management helps us.

Technical support, knowledge, and productivity are the most important factors when we chose CA as a vendor.

Make sure that everybody in the company and team know the importance of the change.

With Agile Central, we are able to map out our work and time chunks for our sprints. It forces us to plan our work and enables us to get software builds to our customers more efficiently and quickly.

It has helped us to become Agile. It has helped us to really get our products in front of the customer faster. It's changing the culture of how we build software.

When you look at the old waterfall methods, we weren't adapting to change fast enough. We weren't able to rapidly deploy what we were building. By the time we would build something, there would be changes that came down the line. We didn't react to it fast enough. This allows us to react faster, and to build better products. We're learning more and more every day, and using their coaching.

An Agile Central mobile app is long overdue. At the end of this conference, I want to look at my burn down charts. I want to look at how my teams are doing, and trying to look at the full website on a phone. It's a terrible user experience. We need a mobile application for Agile Central.

It’s a great tool other than that. It's been fantastic. Developers love it. My managers love it. It's been great.

Stability has been very good. Every now and then, there is something. Ironically, it was down a little bit on Monday at the start of this conference, but we typically never have an issue with Agile Central being down.

It's very scalable.

Initial setup was straightforward. It was easy.

We're a long-time CA customer. We actually bought Rally before CA purchased them, so we were already a Rally customer when CA bought them. We were also already a CA customer for other products, so it really worked out well for us. We weren't upset at all over that acquisition.

We compared Rally vs JIRA, but we felt that Rally was the better tool.