OpenText ALM Octane Reviews

Octane is a relatively new solution for us. We needed better tooling than we previously had and Octane gave us extra flexibility. Our primary use case is for cross-project program reporting and dashboards. We are customers of Micro Focus and I'm a company director. 

The dashboards and metric reporting are valuable features for us. From a development perspective, we use Jira and Zephyr. To stay agile, we need to ensure that our Jira data is feeding into our ALM projects. It's about the real-time integration between the two and bringing that information across accurately. 

I haven't been impressed with the reporting from a requirements matrix and a traceability perspective. ALM has always lacked in this area. They come at it more from a Waterfall testing perspective, and less from a Sprint-based perspective. It's in those areas that we use Jira with some of our development teams. We ran into roadblocks due to the sheer number of users, around 1,500 people using the tool, carrying out testing, and ensuring that people understand the requirements.

I think they need to look at ways of innovating and finding the wow factor with more flexibility and agility in development, but they've never really been good at handling that which is why we stick with Jira. There hasn't been much investment in the tool and there are definitely some areas that can be improved upon.

I've been using this solution for about six months. 

The stability is fine and they give you the capability that you need to run a good quality engineering program. It's what they've been providing more or less for at least 20 years; perhaps it's time for some innovation.  

There's no problem with scalability. 

We don't deal directly with Micro Focus but with one of their support teams through another vendor. We've never had an issue. 

ALM is a little pricier than Zephyr Enterprise. Because of our familiarity with ALM and the fact that we had all the integrations, it was easier to resume using it. 

We compared Zephyr Enterprise with ALM and decided to go with ALM because we have another provider that already had integration with ALM. If we'd gone with Zephyr, it would have required some technical integrations with their APIs and some of our testing tools. From a capability perspective, the two solutions are pretty on par with one another. If an organization is evaluating capabilities versus investment, then they might prefer Zephyr.

I rate this solution eight out of 10. 

The platform's most valuable feature is pipeline integration or continuous integration services. It can fetch insights about various deposit points after synchronizing with Jira, IBM, or other tools. It gives visualization through dashboards and reports updates quickly and easily.

The product's requirements management feature needs enhancement in terms of functionality. Also, the release management feature needs expansion.

We have been using OpenText ALM Octane for ten years.

I rate the platform's stability a ten out of ten.

I have worked with around 400 OpenText ALM Octane customers. It works well for synchronizing data.

We had a good experience working in the support team's R and D department. However, they could provide more technical resolutions.

Positive

We used HPE Micro Focus ALM Quality Center for a significant amount of time. From a competitive point of view, no comprehensive tools could cover ALM functionalities better than HPE and OpenText. Almost 80% of enterprise companies use OpenText as a well-integrated solution. It doesn't require the technical expertise required to work with open-source tools. Also, it provides good support services.

The initial setup process is straightforward. The platform has well-defined, out-of-the-box workspaces and projects incorporating good practice workflows.

The product is highly priced compared to other tools. However, it offers substantial value. There is a distinction between OEM pricing and the final pricing for customers. They could understand the delta between the two and work towards a favorable outcome.

I rate OpenText ALM Octane a ten out of ten. It is a great product considering ETL and DevOps methodologies. It integrates and synchronizes well with other tools as well. I advise others to understand the business requirements before making a purchase decision.

In my company, I don't specifically work on OpenText ALM Octane, but my team works on it. My company uses OpenText ALM Octane as a test management platform.

Since I work for a software company, we use it for the management of test scenarios, how many tests to run against certain features, what are the test results, how long the resolutions or the fixes take, and when we can stop testing the features. The product helps in terms of collaboration and coordination between different teams.

The most valuable features of the solution are its ability to manage test scenarios, test results, and test automation, which are its primary functionalities.

Improvement-wise, I think that the tool needs to be made more flexible and easy to integrate with the rest of the tools in the SDLC ecosystem. There are some challenges when we want to integrate the tool with other products, and it takes time for a team to figure out how to do it.

I have experience with OpenText ALM Octane for a year and a half. I am a customer of the solution.

It is a stable solution. Stability-wise, I rate the solution a nine out of ten.

I haven't seen any significant requirements in my company regarding the scalability aspect of OpenText ALM Octane.

Scalability-wise, I rate the solution an eight to nine out of ten.

Around 250 people, consisting mostly of QAs and software engineers in my company, work on the solution.

I rate the technical support a seven out of ten.

Neutral

I rate the product's initial setup a seven on a scale of one to ten, where one is difficult, and ten is easy.

The solution is deployed on an on-premises model.

I rate the product price an eight on a scale of one to ten, where one is cheap, and ten is expensive. The product is neither cheap nor expensive.

I don't recall the names of the products my company had evaluated against OpenText ALM Octane in the past. The reason why my company chose OpenText ALM Octane is because we were using Micro Focus in our environment.

I suggest to those planning to use OpenText ALM Octane to ensure that the workflow and the tools that you use can collaborate and integrate with the product.

I rate the overall tool an eight out of ten.

I use it to integrate automation jobs from Jenkins, and to document manual test cases to have traceability on our deliverables and OpenText coverage of our requirements.

The integration capability of ALM Octane was very straightforward. We had a supporting team, and they provided us with detailed documentation.

Test reporting and traceability metrics have proven most effective for managing our projects.

Promoting it more could help a lot of projects. It's time-saving and efficient, and I'm sure it will benefit projects with safe implementation in place. 

Octane is a good choice for companies using the safe portal.

I have been using it for three months now. 

It is a stable product. It performs well. 

Technical support has been good so far. They've implemented our requirements on time, with no delays.

I used Rally. 

Rally wasn't easy. The interface was very difficult, and it was hard to have traceability of our work. The UI wasn't user-friendly. From a test management perspective, we couldn't integrate our automation pipeline into Rally. 

We wanted one solution for both automation and manual testing to have a complete picture. Management team also needed easy access to relevant data. 

As a QA, I wanted to see the release details, defect rates, test coverage, and epic coverage for each release. ALM Octane's reporting structure is much better than Rally's. Rally is a bit complex from the UI perspective.

It's an online cloud version. We just had to have user accounts created, and we were all set up. It's been very smooth.

I am not aware of the pricing because it was introduced at an organization level, and we just integrated it into our project.

My organization would have definitely evaluated other options. We've been using ALM for years, at least since I joined three years ago. 

However, we recently acquired a new organization, and they were using Rally, which was difficult to integrate with Jira. So, we switched to ALM Octane.

We definitely use it as our one-stop solution. 

I would recommend it but depends on the specific project and organization needs. But for our project, it suits us well and has resolved a lot of problems. We are quite happy with it.

It's only been three months since we started using it, and there are still many features to explore. For now, I'll rate it a six out of ten because I haven't discovered all the features yet.

We are using it for test management. We are using its latest version.

It can simplify testing by structuring it after the application modules that you are defining yourself, and these are both tests and defects connected, which helps you control the quality in different areas of your solution that you deliver.

The filtering options are very good once you learn them. The document reports are also valuable. You can create reports in Word and PDF formats. That's very useful.

It is flexible. You can integrate it with a lot of other products that are available. If needed, there are APIs available. That's also very good. It's also pretty easy to adapt for the users.

Development of extensions or connections to GitHub actions could be better. Better integration with Azure DevOps would also help.

I have been using this solution for about four years.

It is stable.

It is scalable. It is just about adding more power and more Elasticsearch servers, and you should be fine.

We have about 500 different users daily.

We are happy with them. We have weekly meetings with the PAM.

We used HP ALM Quality Center. We switched to Octane because it's a more modern platform. It runs on full browsers and all OSes. So, it makes sense to use it. 

We installed it on the side of the existing one, and we migrated step by step or project by project. 

To start with, it was pretty complex because it was a pretty new solution when we installed it. We were probably one of the first bigger companies installing it. So, we were quite early adopters, but it is a lot easier today to install this. We haven't had any problems. There are very few errors in the solution.

It was done a long time ago, but we spent a lot of time because we had to explore enabling single sign-on, etc. That contributed to taking some time, but that had nothing to do with the product. It is probably a lot simpler today.

We are an IT company. We do it ourselves. We had just two people. We probably had a DBA too.

It is hard to say. We don't measure it, but we probably have seen an ROI.

If you compare the price with the functionality, it is pretty much the same as other solutions. If you compare it to Jira, for instance, it has a lot more functionality. You don't need any plug-ins, but it's also more expensive. Once you start adding your different plug-ins to Jira, you'll probably end up with the same amount or more.

There is also a yearly support cost, which is usually 25% of the initial cost of the license.

We already had ALM Quality Center. So, it was a natural move to Octane. It was easier for migration purposes, and the users knew some of the main functionalities. So, we did not evaluate other tools.

I would rate it a nine out of ten. It is pretty good.

It's an Agile tool for our project-based test management. 

One of the things we're working towards is DevOps. With an Octane project, we have our automation, our requirements, our tests, our pipeline into build-and-deploy, and the ability to identify problem areas. It makes things quicker because it's more along the lines of an automated process. I would estimate it saves us 20 percent in terms of effort and time. We haven't gotten to Nirvana yet, which would be full automation, but we're trying to achieve that.

The most valuable features include the predictive analytics, being able to trace everything, and having all the tools for testing and test management in an Agile environment.

The problem with Octane is that if I'm in ALM and I need to go into this Agile process, and I have been using Micro Focus ALM, when I go to Micro Focus Octane, all the things that are in ALM are not all working in Octane. For example, the template feature: When I manage projects that are being created in ALM, I have a standard template, but I don't have a template for them in Octane. I literally have to create the project from the ground up every time, which for an administrator, is a nightmare solution. It could take you upwards of two to three days to set up a project, and then you have to try and make sure it has all the same stuff as the previous projects. You literally have to have this massive checklist to make sure you create all the same fields, you put all the links, you put all the dropdowns to make sure all this stuff works for the projects.

If I'm jumping from ALM to Agile, I'll go into Octane and create a new project template form, but I have to actually document creating that because I have to create every individual piece of that project - all the pages, all the fields, all the drop downs. I have to duplicate all the work, each time I have to add a new project in Octane.

It's very complicated. When I set up new projects, it takes multiple days, and then it's fraught with mistakes, because it's a manual process for setting these things up. I have multiple people trying to do it and I'm going to have all kinds of errors Typically, for ALM, it takes any one of us minutes to create a new project. I can create a new project in about 15 minutes, at the most. And I can guarantee you the project that's created is identical to all the other projects that I have created, because it's a template. In Octane, I literally have to create every field value, every field, every form, every workflow, manually, each time, which always ends up with a problem.

I've talked to them about it. They say it's on a list to be looked at. I would think that would need to be at the top of the list.

Another issue is that one of the things I do is link all these things together. Octane has a Synchronizer tool. The only problem was, it didn't work with all the fields. They just upgraded it to work with multi-select fields. I haven't had a chance to test it yet.

I worked with their engineers on this. I don't know how they could have not done this. There are not that many different field types that you would create. A text string or a single dropdown or a multi dropdown, or a numeric field. They had everything but the multi-select field. All the rest of them worked but multi-select didn't. In my projects, about one-third of my fields are multi-selects. When I tried to get the systems to work using Octane, I couldn't get them to work. I had to use another tool for the projects that needed multi-select. I put those projects in JIRA because JIRA worked.

You've got it up and working. It's stable. Other than the problems that I talked about, it works. I haven't run into any other major issues.

I did have one project switch out of Octane, back into JIRA, because of the way that it displays status. If you are in the Octane test area, and you have defects and test results and user stories, and you want to see a user story, if you have different workflows for defects and for test, what you see on your task board is all three tool items on one page. Say you had a work in progress with a vertical line of task records. You would see a work in progress for user stories, a work in progress for test, and, a work in progress for defects. So from the board, you see three work-in-progress verticals, and you say, "Oh, that's a problem. Which one is it? It doesn't say." The only way to get rid of those is to hide them. They're still there, but you have to hide them.

I struggled with trying to get it fixed for the users. They kept making changes to workflows and every time they'd make a change, I'd have to go in there and try to figure out how to hide it. I think the design of those boards could be better.

I'm in SaaS. If it slows down, I just call them. They increase something, whether its memory, CPU, or disk space. Scalability is pretty much a non-issue.

The support is good. They have worked very well with us, in getting things addressed. I work pretty heavily with the development staff and they are quite open and easy to work with. They do try to get the solutions addressed as quickly as possible.

We do have some big issues that we are struggling with, the template feature and the multi-select and the synchronizing. We were moving in a positive way to move people from the old tool to Octane until we ran into those issues. Now we're actually going backward. They got the multi-select fixed, but, unfortunately, I've got to erase some bad taste in peoples' mouths to get them to come back.

The way we brought it in is that we have a Flex agreement with Micro Focus for a large list of products. Because we had ALM, Octane was included. If I have 200 licenses of ALM, I have the equal amount of Octane. If use one, I get the other.

We have the SaaS. The system was all set up and working through the Micro Focus SaaS team. For me, it was just a matter of getting access to it. They said, "Here, put in your user ID and password," and that's how long it took.

The biggest ROI, compared to any other tool out there, looks like it will be the predictive analytics. I don't have it fully implemented, but from the demos I've seen, it is pretty amazing. Getting that fully set up and implemented is, in my opinion, a game-changer. It could make the tool top of the market. 

It's pretty pricey, one of the most expensive ones on the market.

The value depends on if you use all the features that it has. It comes with a lot of features. The difference between the license structure of ALM and Octane versus JIRA, is that you get everything with ALM and Octane. All the plug-ins that come with them pretty much come with the product. You may have some one-offs that you have to buy outside the product but it pretty much all comes with the product.

For JIRA, you buy the pieces one piece at a time. If you only use three of the pieces, you only have to pay for three of the pieces.

If I used all the features of the tool then the price of the tool would probably be fair. I've been doing this for 45 years and I don't think there's a tool on the market that anybody uses fully.

The good thing with ALM and Octane is you get all the features and you don't have to add anything else. If you want to see what the others are, you have them to use.

With JIRA, you need those three things and you buy those three things and, most of the time you don't go looking to see if you can use something else. Maybe two of those things could help you immensely with something else, but typically you don't go looking for them because they may cost more money and you may not have it.

Everything in the tool is good, but then it's expensive. The mindset, now, is go Agile. And go Agile means go cheap, at least in the executives' minds. But, in reality it's not.

You're fighting the "JIRA monster" because all the new developers in schools today use JIRA. When they come out on the marketplace they know JIRA and they like to use it. They don't know Octane because it's a new tool and it's still in its beginning, growing pains. You really have to have a perfect scenario that convinces them to leave what they know to go to what they don't know. I fought tooth and nail to get people to start using Octane here because we had a license, meaning it didn't cost anything more than we were already paying. I couldn't get anybody to come see it. I couldn't get anybody to use it. What I started doing was selling it to new people, people who hadn't been involved with JIRA before. They took it and they like it, except for the one team that left because they didn't like it.

When you compare ALM Octane vs JIRA, it's different than JIRA where you have the core product and then you have to buy all of the add-ons to do what you need to do. Octane tends to have everything you need.

Octane is really good about synchronizing data. Synchronizer is a really good tool to get people who are into any other tool using it quickly. Regardless of where you're coming from, you use Synchronizer to synchronize the data, as opposed to trying start new or migrate. This is a quick way of getting data over and being able to manipulate it so that it's usable in the new tool. If you're going to ALM to Octane, as long as you can get all the fields to come over, it's quick. I took two projects and it worked within hours of getting it set up. When I ran into the problem of multi-select fields, that was pretty much a roadblock; but a simple project to a simple project, it worked fine.

In terms of our tools and processes evolving to adapt to the change from traditional Waterfall development, it requires a retraining. When you're going from ALM to Octane, in an Agile process, everything is completely different. You have to train all the users on how to be Agile, you have to train all the developers on how to develop in Agile. You have to realign your whole organization by resource and resource assignments.

Then, you have to develop your change control, your change management process, because that all changes. Also, your configuration management teams all have to change. It's a complete upheaval of literally the whole organization, to go from Waterfall to Agile. And, for tooling, everything you do, everything you knew before, has to change. Your tools, your process, your planning, your resource allocation, everything has to change. It's a very big process and it will take a long time, and we haven't achieved it yet.

The biggest lessons we've learned, so far, during this transition is that it's bigger than we thought it was. However, I'm still the owner of the tool and, for me, a tool is a tool. You have a screwdriver, and maybe you come up with a nicer screwdriver, but it's still a screwdriver. You still have to screw a nut into an object. The same thing with the testing tools. I still have requirements, I still have tests, I still have test runs, I still have defects. It's just how you process those things within the overall organization, how you address your processes. From a Waterfall process to an Agile process, everything is smaller. As opposed to a six-month delivery and test, where you're addressing thousands of defects, and thousands of test cases, in an Agile process, you're dealing with tens of them instead.  It's much smaller everything because you're working in two-week sprints as opposed to six-month or 18- month cycles or releases. 

In terms of the tools that you use, it's how they fit, how they get you to meet the objective quicker, and how much training has to happen. Some tools require more training than others because they're not logically thought-out processes for creating records. Octane's usability is more logical and step-processed, where you start with one record and it drops down to the whole thing as it explodes out into all of the different areas. Comparing it to JIRA where, if you don't know how to use JIRA, it's not very logical and you have to hunt and find things. In Octane, it gives you the big menu ribbon that has everything from left to right. So, you see how the process flows.

Regarding ALM tools in general, they're struggling with it and it could be because they themselves are on the same road that everybody else is on. But, they're a little bit behind. Agile has been around for a while. JIRA is the ALM of tools: ALM was the tool for test management for Waterfall, where JIRA is the tool for the Agile process. 

Octane is trying to play catch-up. The design of the tool is a little different. JIRA gives it to you in pieces, so you get the core product and you have to add on things to make it actually work, where Octane gives you everything.

We're in the process of going to this process. Right now, the larger side is JIRA. We have four projects using Octane. We can only hope it can replace JIRA.

We currently have fewer than 50 users in Octane. Their roles include BAs, testers, developers, and administrators. We don't require any staff for maintenance because it's all SaaS. The only resource utilization for us is setting up user access to Octane. Ninety percent of that is either the SaaS organization or the users themselves. Because we go through a portal, they have to set themselves up as a user on the portal, and then our support staff just grants them access to Octane and sets them up with a role. I'm the owner of the tool set and the support and maintenance.

Overall, I rate Octane a strong eight out of ten. The tool works and it works well if you're only on the Octane side. It does what it needs to do. It doesn't claim to be the easiest configuration tool, but utilization of the tool and its support for what your project needs seem to work quite well. All the things that they're giving you are everything you would need in projects. It's when you get into the integration piece, when you get into the more complex pieces... that's why I give it only an eight.

Micro Focus ALM Octane is hosted on a separate environment, that's a hosted environment for us, it's not on-premises because Data Consultancy Services is supporting the outsourcing to that company. If you compare Micro Focus ALM Octane with Jira, we have an on-premise deployment for Jira, that's the difference.

The most useful feature of Micro Focus ALM Octane is the dashboards, they are easy to use. 

I'm using Micro Focus ALM Octane as a manager, and it is two times easier for us than other solutions. The look and feel are good and we can customize the reports and dashboard. From a management perspective, it's quite a good solution. The features are robust, ironclad, easy to configure and use. 

When it comes to CI/CD for the developers, I did not find any major differences with other solutions except that some things are saved in the files rather than being visible in the window. It is not available in the graphical user interface(GUI), but it is in Jira.

The solution is frequently updated with new features.

I have yet to experience the CI/CD part of Micro Focus ALM Octane but as demonstrated by the team who is providing the services, I see that the CI/CD could improve. When we check in the code, for the code snippet that has been checked in by a particular user, you need to open a separate file. When comparing Micro Focus ALM Octane to Jira, they have a separate window in which you can click on the ID and the code is visible in the snippet. It's a two-step process in Micro Focus ALM Octane and it's a single-step process in Jira. It's essential for the developers to think about this difference.

I have been using Micro Focus ALM Octane for approximately two years.

Micro Focus ALM Octane is stable.

I have found Micro Focus ALM Octane scalable.

We have approximately 250 projects using Micro Focus ALM Octane. We are a  small team of 10 to 20 people that varies at times. Our performance-driven teams and we have been releasing month on month. We are finding it very easy and comfortable with Micro Focus ALM Octane. 

Since the ALM Octane is outsourced for us and another MNC provides support, regarding scalability, we as customers to them have observed it's highly scalable - addition of servers to handle thousands of requests/reposne from end users - agile/scrum teams/project managers/ stakeholders to manage backlog is easily met. There is no lag in response time, never did the pages hang. I never waited for Dashboards to collect data and show up, it's just in a fraction of seconds. 

Also, latest in DevOps technology like Azure DevOps for CI/CD is easily implemented. 

The support we receive is fast. When we had Jira, we had our internal team who had been given the training to support us. With Micro Focus ALM Octane we have outsourced the support to a separate company called Data Consultancy Services, and the response time is great.

We have used Jira previously.

The senior management of my company handles the purchases of the solution. However, the price per developer was a major reason we switched from Jira. Apart from the complexity and the support, the price was a major reason that a team of 20 people unanimously decided that we would prefer to go with Micro Focus ALM Octane rather than Jira. The senior management had seen some benefit in it and they preferred it over Jira because the per developer cost was less and the support was superior.

Micro Focus ALM Octane has been exemplary, and as a project manager, since the day I've started using it, it has been wonderful. We are very comfortable with the processes and the tool. We have zero worries since we have been using the solution. It has been very positive from our side.

It is early to rate Micro Focus ALM Octane because we currently are using only the dashboard features, solution backlog, and requirement backlog. The CI/CD has yet to be implemented. Addiotanlly, the orchestration is pending, but as for the current usage for these features, the solution backlog management, prioritizing the task, creating the task, creating the defects, creating the manual test fields, and automated test fields, are very good. 

We have experienced CI/CD in orchestration in Jira, but not in Micro Focus ALM Octane and, in a month's time we will have a better understanding.

I rate Micro Focus ALM Octane a ten out of ten.

I give the high rating because of the support, look and feel, reports, and the dashboards

We have a relatively splintered tool set and a number of tools which could not connect all of those things together. Therefore, the use case for ALM Octane was that we were trying to create a single version of the truth. A single source of everything to change within the IT department. 

I work in the programs management department.

We are using the latest version of the product because we are cloud-based. We receive all the deployments as they are released.

Octane has definitely improved the capability that we have for visibility within our tool set. The ability to report and see the current status on change, defect, and test runs on a spring by spring basis within our programs. Previous to this, change management was done in one system and testing was done in another system. Defects were in one of those systems, but they were like forgotten children and weren't really linked to anything. 

Octane has made everything a lot more visible. It's ability to relate everything together and create spider diagrams of change, the lifecycle of that change, defects, and the test status. These have made a massive difference to the visibility and our ability to trace back to the origin of a change, where it started, and see how it finished.

It's beginning to improve our processes as well. We are seeing some real improvements in the way we do things. We are becoming more agile in the way we do it because of that and in a way that stories are managed. Stories are given lifecycles as opposed to just being entities within a tool.

The visibility that we received from the ALM tool is that we can see a change through from its early requirements all the way through to development check-ins to the pipeline release then to the point that it's deployed. We can see the full lifecycle of the change within the ALM tool including integrations that we never before had in a change management tool. It's almost revolutionary for some people here to see check-in information appear against a user story in an ALM tool.

• Octane is built on the SAFe framework, which is the agile methodology that we are currently following.
• The capability that it has for so many out-of-the-box integrations is a fantastic feature. 
• The very clean, easy to use UI that it promotes.

The reporting side of ALM Octane could do with a few areas of improvement. There is not enough flexibility in the way that we can cut up the data to report on certain things. For instance, with test information, we can't split that up by team, so it's quite difficult to see what coverage each team is currently working on. Some tech managers and scrum managers want to see the testing which going on within their team, but it is difficult to see. We only get a more holistic overviews of that.

I come from a testing background, and think the testing could be improved. 

It is a very stable platform. We occasionally see areas that come up with a more client side, so they're not blanket across everyone. Sometimes people use the wrong browser. The product clearly states that it doesn't support IE, but then who would support IE, as it is end of life. 

We've only had a few stability issues. Generally, we have issues following any deployment they do, so if they do a deployment on a Sunday, then we may have a couple of issues on a Monday or Tuesday. However, their support and willingness to react and resolve issues for us has been second to none. They've been low impact to the point where it has not damaged anyone's perception at all.

We have 220 users on it. I have spoken to clients who have 3000 users on it. It's relatively scalable. We haven't seen any performance issues at all as we have ramped up the amount of data that we have on it or the amount of users. Our users include scrum masters, developers, testers, product turners, subject-matter experts, and business intelligence analysts.

In terms of usage going forward, we will rollout to our operations department. We'll get Ops using the same platform, so that should be another 60 to 70 users. The benefits of this would be that we would have more work concentrated all in the same place. Therefore, we can have a lot of crossover between other departments which aren't currently on ALM Octane that we can get onto Octane. This would make it work better and make it easier to manage because it would be a single place for work to be referred between teams, as opposed to having to go to a different tool if someone needs something hardware or software related to be created. 

For a company of Micro Focus' size and delivering this large of a tool, their engagement with me has been unbelievable. It has been to a point where I have never experience engagement like this from a software house. I speak to developers and architects. I speak to people who actually care about the issues that they are speaking about. I don't just get someone in a call center who is logging a ticket, and says, "Someone is looking into this." Then, the ticket disappears into the abyss for three months. It's really nice to see and have intimate feedback on your suggestions or queries. That relationship has been almost as valuable as the tool.

The technical support, help desk, or service desk where you log a ticket on their service platform has the ability to turn around an issue quickly and is very reactive. 

I logged an issue on Monday afternoon, and within 12 hours, it was fixed. They did a deployment on Sunday, where they made changes to the history area of every ticket. Then, on the Monday, that history had vanished. We noticed the history had disappeared. The history for every single change that we had in ALM Octane was gone. I logged a ticket with them late in the afternoon on a Monday, then by 9:00 in the morning the next day, our history had been restored. Whenever they do a deployment, if we have issues, it takes them no longer than three or four days to resolve that issue and deploy a fix for us.

One of the biggest strengths of the community that developed Octane is they are so willing to listen to their customers and learn, then improve the tool that they have delivered. They try and make it fit for the customers who are using it.

We were using Enterprise Tester and Rally (CA Agile) for change management. We switched from Rally to ALM Octane because of the lack of integrations and lack of drive to see Rally improve (from the company) because Rally is now owned by CA Technologies, and technically called CA Agile. CA has multiple other products that do the same thing as Rally. They have sort of acquired Rally, and it almost gives the impression that they will end of life Rally at some point, then take the user base and put them onto the tools that CA have. 

Also, Rally's age is a factor. Rally was one of the first scrum-based agile tools. It did a lot of things very well in its early life. It's been overtaken by newer agile tools now. The last reason was because Rally was not our choice. It was a tool that was pushed onto us by a third-party integrator when we brought them onboard to help us deliver a large program, so we just ended up with it. When you don't bring in a tool yourself and don't integrate it yourself, it ends up being a little bit of a mess on the administration side. There was a lot of stuff in it that had no home, no direction, nor desire to ever be completed, and had not been managed correctly. Thus, the administration to cover the tool was enormous.

We switched because outgrew the Rally tool with our process. It had gone beyond the capabilities of Rally.

People are generally happy with the position that they are in now in comparison to the position that we were in when we were on Rally. The administration is certainly a lot better now that we're on ALM Octane purely because people have a desire to not want to end up in the same situation, thus people are more conscientious of what they're doing.

The initial set up was very simple. The tool from getting our license to starting to use it, there is not a lot to do. We have evolved with the tool, as the tool has gone on, but we started using it straightaway. There was nothing that we needed to do to make that tool work. We have taken a very step based approach. We started using it, then we developed some changes in the way the workflow flowed. We have added additional fields here and there, where we decided we needed to do so. Then, we added additional bits of functionality through other bits of integrations as we've been seeing the need or when we know we've embedded it in processes with other things. We've rolled things out slowly. It seems slowly to us, but it's actually not taken that long.

There is not a deployment. It's literally they give you access. They go, "Your licenses are ready," and you login. That's it, then you start using the tool.

The planning phase for me was a year long project, getting everyone on the system and all the data migrated. Initially, it was about creating a need, because no one knew they needed a new tool until someone looked into it. I identified the need and problem, did the analysis, made the recommendations, presented the options, made the recommendations, and collected the requirements. There were a lot of requirements. Then, I went out and engaged with our InfoSec Department and our procurement process. I officially got sponsorship from the directors in about March for the project who saw it and put some money aside to be able to do it. It was a fairly smooth process from start to finish, but it was hard for me because initially there was no need for it. I created the need for it, then from that point on, it was a very smooth process.

I was the single person driving that process, but then it was a member of staff from procurement. I touched base with multiple areas of the business that would have been using it to gather requirements, so nine scrum masters for half an hour each. Architects were all advisory. Contract specialists/managers to do the contracts. We had our legal team. I was the single resource that drove the process, created the documentation, and found the supplies.

I am the person now maintaining the system. It shouldn't take more than me, but it probably won't be me forever. The only reason it requires maintenance at the moment is because of misuse, so it's not like things go wrong with it all the time. It's more of a case of that it's self-sufficient and I can go through and review the work that people do, ensuring they are using the tool and populating it as we would like them to, thus we can get quality data out of it. 

We purchased it via a supplier. Octane is being supplied by EOH Europe for us. I have worked with them in the past. They were happy to put us in touch with Micro Focus. We already have a couple of other tools through EOH, so we already had an existing relationship with them.

Working with EOH Europe was fantastic. My contact at EOH was very helpful. He has always been there to help with the multiple questions that I ask all the time about various different things, not necessarily related to Octane, but about anything that they supply us.

My biggest challenge as the integrator has been about changing culture. The tool does what it does. That is all. It has received a very positive reception by the majority of the people that use it. 

Changing the culture means improving the way that we do things, our processes, and the way that we do this is by having communities. We have a community to address concerns, misunderstandings, and conversation points that people bring, then we try and improve the practices that we do by trying to get everyone aligned to the same practices.

It's a bit early on to see improvements in times and deliveries. Our entire company has only been using the product since December of last year, so we don't have enough trend data.

We will see ROI once we have the automation suite connected up to Octane. We will then have the ability to report on automated testing versus manual testing and the ability to see those tests automatically parsing with the tool. When Octane shows us when our CI process fails and shows us what the story that failed, we will have return on investment. Because we will have not the overhead of having to do an investigation of having to find out what the change was, because Octane will tell us all of that information. 

For what it does, it's very reasonably priced. I like the licensing model as well, because it's very flexible. You can scale licenses up and down for short periods of time. 

In terms of pricing, it's comparable to what we had previously. It's not priced at the higher end of the scale by any means. It's priced nicely, in the middle of the market. For what you're getting, it's a very good tool.

It went through official procurement process where we went out to tender with seven different suppliers. We had responses from five of those suppliers. We had demos from five of those suppliers. We followed three more through, then we eventually selected Micro Focus ALM Octane. At which point, we started demoing Octane and ran it through 2018 whilst we were doing contract negotiations and signing contracts, which was probably the single hardest part of the entire thing. 

Four of the seven vendors that we looked at were Micro Focus, CA Agile (incumbent), VersionOne, and Jama. 

We went with ALM Octane because of its functionality and it is presented very cleanly and simply. You are never more than three clicks away from where you need to be in Octane. Another reason that we went for ALM Octane as a tool is because of our relationship with Micro Focus as a company.

ALM Octane has a cleaner version than VersionOne, which is a little busier.

If you're looking for a tool which will complement a CI or DevOps process, where you want to have a single point of visibility or a single version of the truth, and see all of the stuff that happens through that journey, Octane is the tool which will to give you that.

The biggest lessons learned: When you start focusing on a new tool that prides itself on having a very tight process to make things visible, you learn how other people don't necessarily follow its processes as tightly as you would expect them to.

Using the SAFe framework helps our workflow patterns. We have been using SAFe for about four to five years, and we've actually been using it properly for maybe two and a half to three years. We're still not perfect by any means, but we are definitely pushing forward in the right direction to become more focused on delivering the true version of that methodology. Although ALM Octane doesn't do every element of that methodology yet, they are endeavoring to clean up a lot of those areas. They are trying to mop of some of the methodology that SAFe works on adding in things. We have seen quite a lot of new features recently that have been specifically focused towards SAFe, which has been really positive for us.

ALM Octane has improved our use of agile, but we still do some waterfall stuff. We will always carry on doing some Waterfall stuff until certain systems fall out of use because we have old systems and those old systems don't lend themselves to agile.

ALM Octane has presented us the opportunity to push forward with a true CI/CD approach, which is where we want to get to.