Agile Manager [EOL] Reviews

The way that it handles the user stories. It's more compatible because it is built to support the Agile framework or Agile methodology. Unfortunately, it doesn't have the testing capability, so we have the bridge between AGM and ALM.net to support the testing we want to do. So how you write your user stories, and the requirements gathering, in Agile Manager is pretty good.

This is for one of our critical teams - which is the product lifecycle management team - they started using AGM mainly because they wanted to change how they are delivering their products. Now we can do shorter cycles and have better traceability, and we have this integration between AGM and ALM, as I said. That combination always pushes data of the cycles and the test runs so we can prepare better reports in AGM and present it to the leadership. That's how it increases the productivity of development.

Right now I can't say because other stuff is being migrated to Octane. But basically, the testing module that we are used to, that wasn't there at all. If they would have added that into it then they wouldn't even need to build Octane.

We did have a list of items we wanted to see added but now they are moving all those things to Octane, and we are also interested in Octane now, so we are not looking to request any more changes to AGM, understanding that this is the go-to tool.

It is a stable product. But unfortunately right now there aren't many changes they are doing to AGM because Octane is the preference and they're moving customers to Octane. But really stable, so far.

It is pretty scalable. We didn't do it enterprise-wide. But we do have about 100 users working on it, and it's a pretty big project - that always happens - so it's pretty good.

As usual, only if we get into any issues that obviously need to be done, we definitely use tech support. Sometimes when we order new features we use tech support as well.

They're good. They are responsive. We have a CSM, we always get the responses back. Even without the CSM, we used to have the response, it's pretty good.

If you are looking into AGM, don't go with AGM, go with Octane.

It's very important to us that we're able to adapt to a lot of changes in the space in which we do business. This solution gives us flexibility in product testing and allows us to get our products with very quick time-to-market.

It requires a lot of post-process testing of our products. It would be an improvement if those test weren't necessary. Also, the DevOps process should be easier to implement at the beginning of a project because that's when it would be most effective.

We're in the middle of a POC.

It's deployed just fine during our POC.

So far, so good on stability.

Because we're still doing a POC, we haven't really needed to scale.

We work with a French third-party team and they help us with specific issues.

It provides visibility on the progress of backlog item completions for sprints and the impact progress is having on the overall release date.

The release forecasting allows the team to make adjustments to sprint content in order to ensure we meet dates.

Integration with HPE ALM/QC, Jenkins and Subversion allows us to view the project’s health through one product.

The business, developers and QA now have a central location to track their progress as one team rather than three silo teams.

- Wider support for IDEs.
- In the world of Java, it currently supports Eclipse but not NetBeans.

I have used it for eight months.

I have not encountered any deployment, stability or scalability issues.

Excellent customer service and technical support. The SaaS solution certainly makes it much easier for technical support to troubleshoot issues and provide advice.

I did not previously use a different solution personally, but other members of the team had previously used Rally. We chose Agile Manager as we were already a user of HPE’s ALM/QC and HPE offered a modern solution with tight integration to ALM/QC.

Initial setup was straightforward as it was SaaS, but there was some installation and configuration work to be carried out on synchronising Agile Manager with our on-premise ALM/QC, Jenkins and Subversion instances.

The HPE SaaS team set up the Agile Manager instance and our in-house IT team configured the synchronisation side of things.

If you are syncing with ALM/QC, take your time and read over the help guide on the synchronisation. Get the synchronisation behaving exactly how you want it to with the various synchronisation settings.

It has a good sprint task board with the ability to export tasks to Excel and filter by team member.

Also I like the dashboard. All the graphs, burndown charts and reporting are user friendly and quick. Sprint Closure functionality makes it easy to perform sprint retrospectives. It has everything you need to work in the sprint.

It is easy to use.

The product makes it easier to work with remote team. It gives better visibility on project status/progress.

It definitely has room for improvement. This product does not fully cover the SDLC. The test team cannot track test cases or connect them with test cases.

We have been using it for ~7 months.

It is good. It was down for couple times for maintenance and updates, but that was pretty quickly resolved. It would be nice to receive emails or some other notification.

We haven’t faced any technical issue with it so far. I cannot rate it.

Setup is very easy. Just pay for the licence per person and you have it available 24/7. You can have a 30-day free trial.

HPE is the vendor. I'm not sure it allows an in-house solution.

Because we already were using HP ALM, we decided to use HP Agile Manager. There are many reasons why...

This product is pretty good, but you need to consider what you want to achieve using it, and how open you want to be. Setup integration between all your internal tools might be difficult or even impossible.

This product does not support the full SDLC cycle, so you need to consider this tool as an add-on to existing SLDC tools for now.

The solution is pretty good and allows wide integration with other HP products and CI tools such as Jenkins and source code repositories, e.g., SVN.

Dashboard with release level graphs; it is so easy to gather the progress made at the release with these graphs rather going through each team’s backlogs.

It helped manage the agile process within our team.

They need to make further improvements with the graphs for each business unit. For example, if we want to track work done by QA or Development, there are no built-in graphs available.

I have been using for three years.

I have never contacted the customer service or support for this product all along.

We are the end users of the product. It was an organizational decision to use HP Agile Manager for tracking our agile planning and management.

You need to do a PoC and verify you are receiving all of the information you require. The tool is good enough to keep track of the information, but not mature enough to have a great Dashboard that tracks all levels of changes. The built-in graphs are not mature enough to use right away, as they are. We had to create those graphs internally for our management to use. However, there is a lot of room to look at and implement better graphs.

Gives us the ability to bring in the dev community as part of the testing community. I can relate to the user stories, the business requirements, whatever we are building within Agile Manager. Connecting it to the HP ADM suite that we have, and plugging it in to get Jenkins or any of these other tool sets. You can pretty much tie in in from your requirements all the way through your entire application lifecycle management. We are able to achieve that using this solution.

They are playing a catch-up game right now, they need to catch up real quick. By the time they catch up the competition has moved on. They are chasing a moving target.

There is definitely a maturity curve that Agile Manager needs to go through with. It's still not there, and it definitely needs to grow.

We use a size-based solution so it's scalable for us.

I've not had to contact tech support.

It's pretty straightforward as long as you know how the tool is designed to work and the architecture behind how you need to implement it for your environment.

One of the key features that we looked for when we were looking at Agile tools was the dashboard - all of the metrics that you can get on-demand, pulling from ALM Quality Center. Test runs and all of that kind of stuff. Also the way the user stories can be in some kind of architecture, so themes, features, user stories, linking those from one to another to another, being able to link two different entities to one story card that might be dependent on another one being complete, you can link those two.

With insurance software, there's always that sort of core capability you have to have done before you can start doing your extra writer work, extra coverages, that kind of stuff. Until you have that core base done, our backend system wouldn't be able to accept this policy if that wasn't there first, etc. We kind of manage the front-end work the same way.

Before Agile Manager we had a tool that came with the development tool that we're using. It's a componentized development tool that we bought from a company and it was very much not developed, so there were two fields (name and description) and then you had a single drop down for the story card statuses, either, "to do, running, done." I understand why they were trying to keep it sort of lean with the Agile mindset, but working in insurance, and working across any given project, you might have six, seven, eight, or nine teams involved with different connection points.

There's a lot of information that gets tracked, and you want to be able to capture that with comments, or tasks, to make sure everybody is doing their part. UX has their design done before it's handed over, wireframes have been signed up by the business, requirements are complete. Any business rules spreadsheets have been attached, so if there's any like state-specific tables that we have to deal with in this state it comes in a little bit different, and that state it's the normal flow.

There's more information that we wanted to capture and we needed to capture to be able to do the stories effectively. We're wasting a lot of time on the old tool, capturing, putting out on a SharePoint site, running that down, going and talking to somebody else about, "Hey, did you guys see this part yet?" In Agile Manager you can capture that all on the story card.

This one kind of caught us by surprise, and all our evaluations from it doing demos to the team that was going to be using it. The original version that we got, I'm not sure the version number, didn't have the story card print functionality. The project manager was a little overboard. She had said if she had done this, we would have picked a different tool. I think that's a little bit much.

You can export all the stories to Excel. We created a little mail merge in Microsoft Office. We had a solution in 30 minutes on how to print story cards. That did kind of surprise me, something as simple as just printing story cards out of there. I believe it's in there now, but we have the on-prem version, so it's in the SaaS version, but the on-prem they're not going to do another build for that until I think version 2.0, or 3.0, the next major build. That was the one thing that surprised me a little bit that something as easy as a print feature would be not in an initial build.

We use the CI tool that they recommended and it's one that isn't natively supported by ALM. I think they're looking at changing the CI tool that they're using. We were basically being consulted from Mandex, so they were just kind of going with everything that they were recommending. I think now we're getting a little bit more mature with their tool, so we're sort of customizing to what we need.

It's been stable for us.

It's been really easy. First project we got 30 licenses. I think we're using about 24 to 26 of them. That team is basically rolling into the next project. Going to pretty much stay the same. Kind of take a few of the people to start another team, so we've got 30 more licenses, we're up to 60.

I think it was nearly flawless. There was a couple of server setup things that we needed help with. I was basically working off the requirements dock / setup dock from HP. Our server setup guy had a couple of questions that I think were answered. If I remember correctly, it might have actually been something with our firewall that was causing the issue. Which is funny that it's on-prem. I can't remember what the actual issue was. We set it up a little over a year ago. Other than that it was up and running within a week or so.

We also looked at Mandex who I think are based in Sweden, and have an office in Boston. It's a componentized development tool using reusable widgets that you basically wire up and do some CSS styling stuff on. We didn't really evaluate a tool coming into this project and then we found out really quick that we needed something better than what they gave us. I think originally the project manager, the sponsor, whoever does the sort the setup for it thought it was going to just be good enough, we would be able to sort of use SharePoint how we always have on our waterfall projects.

It was probably only four or five sprints in on a project that I think went about 25 sprints. We found that it just isn't going to work. We started evaluating two tools, actually at that point one was Rally that we already had in-house for a claims project that was going on, and then Agile Manager, and I ended up going with Agile Manager.

With all of the different features, it's really user-friendly and syncs with Quality Center ALM, which is our testing tool. That's already the standard for our test scripting and defect management. Everything has to be done in Quality Center.

With the claims team route on Rally, we had to make a custom sync tool that breaks a lot. It's just been a headache actually bringing that in. They're now looking at coming over to Agile Manager, syncing everything over from that first project, because there's only one previous project. Agile is new to our industry, and we've been slow to adopt everything so they're looking to bring in their artifacts to Agile Manager as well.

There's a lot of like YouTube videos out there for easy training, even before you're in the tool to kind of get used to it. There's a lot in there, it's a really powerful tool, so we had some people get a little bit overwhelmed when they first started using. I'd recommend taking a step back, just kind of watching somebody else use it before you dive in.

The ability to adapt - have the product adapted to the processes that are already in place at a customer. We don't want them to have to reinvent the wheel in order to use the product.

I think the biggest issues that I've seen, and this is a personal view of mine, is that most of the HPE products have a common look and feel to them. I'd really like to see it be a little more customizable to a use and user standpoint. For example. I happen to be colors blind, so I'd like to see more vivid colors on the UI, and things like that. It would make it a little more flexible from the customer standpoint.

I was formally an HP employee, so I've used the HP products in the past. I also was a former Mercury Interactive employee who was acquired by HP.

It's been extremely scalable as far as the testing that we've done with our customers. They've all been really satisfied with the scalability of the HPE products.

I've worked with Agile Manager for about two years now and they've always been very receptive along the way. The nice thing about Agile Manager is when you use the product is has a "What's New" page so you can see whenever something new comes out. There it is, right in front of you.

It really doesn't need to be as flexible as some other solutions because it's right out of the box, it's relatively easy to use. You open up, you create a test in ten minutes and then you're able to run it.

The storyboard and dashboard are the easiest to use features as they perform daily tracking and show you where your project and release is at any point in time.

My team was transitioning to Agile methodology, and we had no real project management tool prior to HPE Agile Manager, although we used ALM for defect tracking. It was easy to understand and provides a fairly user friendly, non-intimidating interface to new users which prevented what could have been a high resistance to change.

Resource allocation and management across multiple products. We have the same resources working on multiple products each with their own releases, and Agile Manager does not handle this well, so the overloading or underloading of resources is difficult to monitor. The only way around this was to call each product an application within the same release cycle artificially in order to really track the allocation of resources and workloads.

ALI integration needs to be improved. We have some large multi-module projects and for the SVN and Jenkins servers we need to completely reset them up every release which is cumbersome, there should be an option to copy the configuration from one release to another for the ALI integration.

The dashboards are excellent views into the project but you cannot drill in or copy the graphs into a powerpoint or word document to provide a status synopsis. There are some long standing bugs on the storyboard that allow user stories or defects to be moved to the left rather than the right if people make a selection within the User Story or defect. It should provide a warning as if you have a lot of user stories it can be hard to find the ones reporting wrong.

For the integration with ALM, it is done via a user account rather than a system account so the history of change will reflect the integration account rather than the user that actually made the change. User accounts are managed by email address, this is an issue when a company changes domain as the account cannot be changed.

I've been using it for two years.

We had a few occasional issues but on the whole it has been very stable.

We've been able to scale it to our needs.

Support has been very good. They are responsive and very informed.

Previously, we did not use any tool for project management however we now have AGM (HPE) and RTC (IBM), AGM is much more user friendly and easy to configure but somewhat limited in its capabilities on larger projects or programs. RTC has many capabilities but you need a doctorate to set it up and to use it. As our environment grows, and if AGM does not handle the multiplication functionality in a better way or make it easier on the license management, we will have to likely move to RTC eventually.

The initial set up was fairly easy. We use all aspects through code and build management along with an integration with a different defect management software. After one familiarization call I was able to set the whole system up in one day.

The price is reasonable and is a little more than some other online providers but still in-line. Licensing however is difficult to manage, as teams ramp up and ramp down the procurement process is difficult within organizations and I would hope be easier to setup and procure online. The support page makes it seem easy to get new licenses, but this a misnomer and you really need to contact the sales rep, get a quote generate a PO and get the licenses. There needs to be an easier way to order more licenses.

We did but we were looking for a very specific goal. We were transitioning a strongly functionally organized team to an Agile team and needed an easy to use tool to facilitate the transition and the learning of new behaviors. As a large enterprise we had in-house large enterprise tools but they were all too complex and intimidating to the users and I knew they would not use them. We then looked at the smaller online products for smaller teams (AGM, JIRA, etc.) to help with the transition.

Agile tools are great but first the organization must adopt and agile mindset to be successful. The product is really easy to use and manage single discrete projects with dedicated teams. Team members like it and are quickly able to customize the views to what they need to see to do their jobs. It is very fast on the setup and does not require a full time administrator or even a very technical resource to maintain it. It is a good tool for the project teams to not get bogged down in making sure status is right.

The dashboard summary views and product backlog management are valuable.

It is helping us organize and manage our agile development process to get solutions to market faster.

The user interface could be modernized to be more intuitive and to support more drag/drop functionality.

I've been using it for 18 months.

There have been no issues with the performance.

We've been able to scale it to our needs.

It's very good.

No other solution was in place previously.

It was straightforward.

Licensing costs are not trivial so be sure to get a commitment from all stakeholders in advance because without everyone participating in the agile process success and ROI will be limited.

We didn't at any other options.

Agile tools are great but first the organization must adopt and agile mindset to be successful.