Agile Manager [EOL] Reviews

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.

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.

• 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.

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.

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.

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.

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.

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.