Agile Manager [EOL] Reviews

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.

We use the hierarchy Theme/Feature/Stories for a top-down approach. The widgets/dashboards are essential to easily setup the reporting and by putting an image on the data, it helps people to understand the issues or to see the potential impacts of their actions.

The forecast was initially made since it was the only points we had. Obviously at the beginning of a project, all the stories were not created, therefore we were forced to make some extrapolations. By using the feature points, the projection in the future is much easier.

As a consequence of the above statements, we would like to have an estimate of the possible end date when all the features will be done given a velocity. This means that we need to have some graphs/widgets which can be used over several releases.

We've used it for one year.

The deployment was very easy as soon as I had the documentation. At the beginning, you need to learn the vocabulary used by AGM and make the links with your own previous habits. Same names may have a different meaning in different tools or approaches. As soon as I understood them, I taught the other people in the company by highlighting what was similar with our previous tool to what was different and warn them on tricky shortcuts (another approach with different meaning or use from the one we were familiar with).

The product is very stable and we greatly appreciate that.

We were able to scale it, but my company has a bad habit. A project is open for a very long time and it piles up a lot of releases. I have to archive some, but I don't know what the result will be. If I don't do it, the response time will be degraded when the data becomes too important.

Commercially speaking, the customer service was a total nightmare at the very beginning. I hope that I will not have to face such an issue when we have to renew.

The technical support is good. Sometimes we need to exchange several times to be understood, but this is perfectly understandable. English is not our native language.

Yes, we used a smaller and less sophisticated tool. It became too small and not sophisticate enough! We especially needed to introduce a new level in the breakdown structure (the backlog was flat only composed of stories).

We implemented it by our own and I think that it is a luck regarding the bad experience I had with the vendors.

I cannot precisely give an estimated but everything gets done smoothly. Easier to change, to try something to see the impact, to move from a team to another one, or from a release to another one.

Yes, we made a criteria matrix to eliminate some and ranked a few of them. Version One was the major competitor.

I would recommend to assimilate the concepts to choose the appropriate breakdown: which themes, which applications, etc. Depending on how you want to group your items, you may want to divide your project accordingly. For instance, if you allow a feature to be assigned to different applications, the total amount of FP is no longer possible.

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.

Being able to capture details.

Burn-up charts for visibility on progress and workload.

• Understanding of “story points” and “velocity”
• Ease of using reporting/dashboard widgets
• Templates for imports, etc.

I've used it for three months.

10/10.

10/10.

Yes, and we switched because this tool is on our organisation’s strategic roadmap.

We used an in-house team.

First determine what your needs are and then evaluate whether this tool can meet those needs.

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.

IBM Rational Quality Manager

The IBM Rational Quality Manager tools have a comprehensive suite of test artefacts that may be used for test planning, preparation, execution, and reporting. A new user could spend considerable time reading the user manual and then exploring the tool. But for this project the team grasped the basic functionalities quickly without using the manual. The team further developed their skills while using the tool for the project.

The features the team liked about the tool were:

• The visual representation of the task board view
• Ability to query work items
• Drag and drop features
• Reporting capabilities

HP Agile Manager

The team used HP Agile Manager to organise, plan, and execute agile projects. The team took half a day to familiarise themselves with the basic functionality of the tool and working on the tool gave them further insights. The tool is highly configurable, but no configuration was done for this project. The team worked within the limitations of the out of the box functionality.

The features the team liked about the tool were:

• The tool gave great visibility on the project work with real-time analytics and dashboards
• All estimations of tasks were summed up and presented at the user story level
• Work items (tasks), flow from left to right according to their completion state
• Once all tasks of a user story were completed, the user story is automatically marked done
• User stories can be added to the product backlog and from there subsequently associated to a specific release and sprint
• Defects and testing can be added to the backlog as well
• User stories can be linked to defects. As long as the corresponding defect isn’t fixed, the user story cannot be set to done. This represents good agile practices
• Sprint closure page gives the overall picture of what has been done
• Retrospective tasks and information is easy to record
• There were views which reflected taskboards that you might see drawn on whiteboards with columns and sticky notes that could be dragged and dropped

IBM Rational Quality Manager

The teams noted that they would like to see improvements on the following:

• A manual refresh was required every time to view changes, and not in real time
• There was no visual indication that a task had not loaded correctly, so any changes made to it were not saved
• The Save functionality was not consistent across the application. When AutoSave was checked, the system would save a comment while the user is still in the middle of writing, so ended up with a half comment. The comments were not editable
• Discussion field was not there as an attribute when selecting the required fields for the query
• AutoSaving was problematic and selecting the auto save feature didn’t remain after navigating away from the main page

HP Agile Manager

The teams noted that they would like to see improvements on the following:

• The major drawbacks were in defect management and session sheet creation
• While creating a new defect the user could enter only limited fields. In order to add more details or even to assign it to someone the user had to edit the defect after addition
• There was no option to create session sheets
• The session sheets were created as Word documents and uploaded. The maintenance of session sheets generated overhead as the existing session sheet had to be downloaded, updated and then uploaded again. This also did not allow for easy monitoring of individual tests progress
• There were no out of the box dashboards for the testers
• Defects can’t be linked to acceptance criteria
• The tool is very reflective of Scrum terminology, therefore it would be better to use generic terms such as ITERATION rather than Sprint

Read the entire comparison study of Traditional vs. Agile Testing here.

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.

The burndown chart.

It helps our project team to implement the Agile WoW which was quite new for all of us when we initially started with Agile Manager two years ago.

Downtime was frequent initially, but now it is much better.

I've used it for two years.

None so far.

No issues encountered.

No issues encountered.

It's satisfactory.

It's satisfactory.

We used Confluence and Jira as part of different client requirements.

It was a bit challenging as we were all new to the solution. But things smoothed out with self-exploration and support from the HP team.

We used a team from Pronq who were satisfactory.

We began implementing following client suggestions and approval.

Just go ahead and enjoy!