Agile Manager [EOL] Reviews

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.

It's currently in proof of concept. Our development team in Prague is using JIRA/Confluence. We're installing Agile Manager to try to convert them into a standard more scalable solution. To me, the difference between what they're using now, the Atlassian product, and Agile Manager is that Agile Manager is much more scalable. If you're going to go into an Agile development environment, we definitely need to have something that goes beyond the number of users that we're going to have over in Prague. That to me is one of the biggest features. It's got a lot of the capability. I've seen Octane, so they're putting in some of the capability of Agile Manager into Octane. I do understand that over time, it will adopt more of the Agile Manager features.

I'm coming from a former company. Standards are critical - a common practice, common solutions - so we don't wind up with pockets of development teams doing their own thing. We have to be very careful with that. From an enterprise perspective, it's the ability to define common standard procedures and methodologies to use for the development. It makes it easier in the event that we do get audited.

I'm actually looking forward to leveraging more of Octane - on the capability in Octane and knowing that Agile Manager will move into Octane gives me that long term perspective. Octane's important in our environment because of the flexibility - the fact that you can get information from a development environment and know that you can shift your focus more to the left. From a testing perspective, I can see the areas that the developers are executing multiple times, where their defects are. That would influence the testing part of the organization to say, "Maybe that's an area that we should focus on, giving that there are multiple defects." I'm actually looking for that better integration using Octane as that mechanism and probably as the Agile Manager add-ons come in, expanding it.

Still a POC, but I've used HP products for decades literally. I've never had an issue with stability of the applications. Scaling is different. We've got ALM and in order for us to get better performance out of our environment, because we would peak out at certain times, we just added an F5 switch and we run two application servers and one database server and our problems went away. It's really just a matter of having that ability with a tool and Agile Manager I'm sure, would be something similar once we get a chance to scale.

It should be pretty straightforward. We're just going to add a load balancing switch. I don't know if we can have two instances of servers with Agile Manager. I'll have to find out. We're just using a single one now but that would be the intention - load balancing individuals, common database. It should take care of any size that we would have.

We've not used it yet, and we're just kind of muddling through.

With JIRA and Confluence, it's really scalability. We have to produce evidence to the FDA that shows, if we're questioned and have to go down to the actual test case, we don't have to worry about the software development. The way JIRA's working now you don't have a real test case. It's a bunch of lists and it's tags. You can't identify a test step, so you define a test case which is a single line, a step that includes multiple steps. That's not what any kind of FDA would want to see. They want to see a single action, proof that the action happened and with a screenshot of some kind. Right now, they're not able to do that with JIRA. We need to get that shifted more into a more standard solution.

My team's been doing operations and installation of ALM and other HPE products for quite a while so the installation went very easily.

We looked at Agile Manager several years ago before it was as mature as it is. That was maybe four years ago. The only other ones have been the open source tools which don't fit well in a pharmaceutical environment.

We want our want own IDE in their environment. Octane provides the development team a seamless integration so they can develop their own tests. They can link it to Jenkins. They can kick off the bills. They can do the automation. To them, it looks very similar to their own IDE. It gives the project managers associated with those Agile teams the ability to see what those defects are and how that backlog is being burned down all in one solution. With Agile development teams, testers are no longer a manual tester. They have to have an integrated idea of what the product is. They've got to be developers that don't want to develop, essentially.

I think the biggest thing is standards. The way I work with any new kind of application is that I'll get the application in, set up a simple proof of concept, and I conduct my evaluation that way. Understanding the product and if anyone's done any kind of Agile development, they would know how the tool works. The question is cost. That's typically the delineation. You spend money for Agile Manager but you've got a company that stands behind it with service and support.

• The Sprint Closure feature is very helpful to capture the sprint retrospective information.
• The Storyboard is an easy way to manage the stories at a high level. This can be configured to include more flexible Kanban statuses.
• The ability to easily filter and sort from multiple screens and then be able to export this information is great. This is a quick way to get reports the way I want to see them.
• Dashboards are flexible and visible.
• I also like the ability to update backlog items from a list view so that you don’t have to pull up each one to update. This saves a lot of time.
• The ability to make mass updates to records saves time.

The transparency this product gives us has been very valuable. Our business can see how we are doing and we use this during our Release Planning event.

Departments outside of IT are using AGM. They have commented that the product gives them a really good way to manage their work as well.

Most of the enhancement requests we have are minor, but the biggest challenge we have is around integrations. Defects seem to integrate well; however, we are still trying to figure out how to get requirements to integrate with how we set ALM up.

We have been using it for about a year, and it’s still a fairly new product in the marketplace. However, it meets most of our needs and supports the SAFe methodology pretty well.

The biggest challenge we have is around integrations.

It seems to be very stable for me. We haven’t had any significant outages.

So far, the product is supporting the needs of both our IT department and our other corporate areas that have been able to use the product.

Customer service is good. We have a dedicated Customer Success Manager who has been very invested in our success. She is great to work with.

Their support is in Israel and Vietnam. Usually, this isn’t a problem, but at times it has caused a delay with resolving more complex integration issues.

We used another product previously, but it wasn’t flexible and our teams didn’t feel that it worked as well for enterprise release planning.

It was very straightforward. We got on a call with their implementation team who gave us recommendations or things to think about when configuring the system. This was a great help so that we set it up "right" the first time. We focused a lot on what our process was going to be and then worked with the tool to have it support these processes. That seemed to work well for us.

HP was amazing to work with during our implementation. Our timeline was shortened by one month by our upper management and we were able to do it with HP's help. It was very easy compared to other implementations that I’ve seen.

I’m not sure that we have a good ROI measurement at this time. We haven’t spent the time to calculate this. I can say we’ve probably increased the usage of the tool by "non-IT" groups by about 30%. We have gone from 120 users in the old system to 250 with HP Agile Manager.

• CA Agile Management
• JIRA
• Scrumworks
• Version One

Make sure you have your processes figured out so that you can set up AGM to support them best. I think this is advice for any tool, though. Talk to other customers to understand how they are using the Themes and Features before setting them up. While it’s easy to change the configuration, I think it would be frustrating to start reporting on it one way and then have to change.

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.

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.

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.

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!