OpenText ALM Octane Reviews

The most valuable are the Agile practice methodologies. We have Waterfall with ALM and we use Octane for our Agiles. That's our distinction between the two.

I like the visual interface. The way they've redesigned the interface over ALM. ALM is kind of old-school, but it's mature and functional. Octane presents the graphics and the feedback that people need immediately without drilling into the dashboards. That's probably the biggest selling point for our teams.

Two things. One is Agile. The other is the CI integration. We've always struggled bringing the development teams directly into ALM. ALI is a bridge, but it's cumbersome. The CI integration of the pipelines is what we're looking for right now. To bring us into the DevOps potential. That's the biggest draw right now.

Octane fits that niche that we never had. We need an Agile solution. We had other teams using other products that are semi-Agile, but we didn't have an approved standard. Octane gives us that. It's awesome.

The biggest challenge for us is to bridge the ALM practices for testing more directly into Octane. That's going to be a challenge because the methodology between Waterfall and Agile is so radically different. We're going to have a challenge with that, but we knew that going in. The testing is new and we have a lot of embedded testing practices with the old ALM approach.

So it would be good to have something in-between there. Some kind of a bridge or training, that is going to be what we're looking at now.

We have yet to see anything that doesn't work. It's awesome.

We've only got 20 live projects in there right now. So I don't see any issues with it. Until we can put some massive projects in there. We've taken one 65-gig project from Agile Manager and ported that into Octane. We don't see any degradation, but that was still prototype.

I've used them pretty much every day. It's the most responsive tech support, it's been awesome. That's another reason we're going to Octane, because of that immediate support. That feedback.

We used Agile Manager and it does not have the testing capabilities. We really needed that. We also need the business rules, we needed some of the workflow that's not in Agile Manager. We needed an Agile solution that had a lot of the same capabilities and business rules that ALM has.

We didn't see that coming in the Agile Manager, so as soon as Octane came out, we jumped on it.

In choosing a vendor what's important is communication. Show up. Talk with us. Build that relationship and then we'll talk product.

I was involved in it, yes, but I have to qualify that. It's SaaS. All I have to do is call Mike. I didn't have to do anything, really, other than start using it. It's intuitive as can be.

No, just HPE, Micro Focus. It's our standard.

Getting something new approved is a nightmare. It also makes our job easier. We tell them, "This is the standard," and we can move on. We're not deluded by looking at bunch of other options.

Invest the time. Invest the time. Learn what it can do. Right now, it's still being developed. It's an Agile tool being developed into Agile practices. Don't get ingrained in what you see today. Accept changes. If you truly are an Agile environment, you get that. If you don't get that and you want things to be finished before you get there, then you probably don't understand Agile. They kind of go hand-in-hand. It's an Agile tool being built Agilely and you've got an Agile practice. You should be able to put two and two together. If not, you need to stay in Waterfall.

Our use cases are test management, defect management, and release management. We also do quality management and we have started to put our Agile journey on it. That is something we started at the end of last year. We're putting more and more on it. We're doing Agile delivery and Waterfall delivery with it.

It provides us with a single platform for automated testing. We've integrated our automation testing with Jenkins to the pipeline module—parts of it, at least—and the other part is connected through the API. It makes the test you're executing very visible. It also enables you to centralize. When we report on a project basis, we're able to do it in one click for a given project. The graphs are standard for all the projects. You just click and you always have the same set of reports, tailored to that project. It fetches the data from that project. I don't need to click five times to find my report. I just click to the next project and my report is there with all the needed information in one view. 

That's what my release manager also loves about it. He doesn't have to click 10 links or 10 drop-downs to get a report. It really has it all together in one view. If we have a release we report it on a project basis, and we can also report on an overall release basis. The overall reports are also done with one click.

In addition, we use the solution’s Backlog and Team Backlog capabilities and the team is very much working together there, from the developers to the testers to the product managers. They're all working together in one space or one Backlog to deliver the functionalities or the features. This is a good thing.

Octane has also reduced manual testing time. We integrated a big part of the regression sets into the pipeline. There's room for much more. We've only scratched the surface.

And using it, we have been able to streamline a lot on the business side. We have business testing or acceptance testing, and for them it's less complicated and there is less effort needed to get their stuff done. It has reduced the cycle times which, in the end, reduces cost.

On the user side, what I like a lot is the reporting capabilities. There's no tool, to my knowledge, that gets anywhere close to Octane at the moment when it comes to the reporting capabilities. I can do everything with the reporting. There's nothing missing. I have all the options. I can create graphs, including graphs of several types and looks.

Octane provides out-of-the-box integrations to proprietary, third-party, and open source tools. The integrations are of high quality because we were easily able to integrate Jira with an additional tool. That connector tool is out-of-the-box and it's very easy to handle. We also integrated one of our in-house developed applications that has a rollout tool. The person responsible did it in one or two days with API connections. It was very easy for him. In addition, we integrated Confluence with Octane, using a self-developed script that is also based on the APIs. For people who know APIs it's very easy. 

Octane's Agile support at the team level is pretty good because it's very visible. The sorting and filtering are very advanced, which is something I miss on Jira.

There aren't major things that need improvement. It's more detailed things, minor tweaks and improvements. For example, updating items, sorting, bulk updates—these things could have a bit more flexibility, but it's still possible to do them. 

Also, for training, the proposed graphs in the dashboards could have some more explanation about what they're doing because not everyone is using the same metrics. This is more a training or knowledge thing, not a lack in the tool, and I already addressed it with my OpenText contact.

They improved some of the things I had on my list in the newest version. I haven't dug through the newest version fully yet.

We started to evaluate OpenText ALM Octane at the end of 2019. We did the kickoff in January of 2020 to plan all the migrations to it. We came from ALM QC.

It's very stable. We had one issue that was due to a faulty, outdated script that overloaded the system somehow. Apart from that, Octane is as stable as it gets. We haven't had any downtime apart from that outdated script.

The technical support is very good. Depending on the severity of your ticket, the feedback is almost immediate. And we can collaborate with them, show screens and share logs, and they come back with a solution. It has been a positive experience.

Our previous solution, ALM QC, was outdated. Our company started our Agile journey and we needed to be able to support that journey and the Waterfall journey as well. Octane offered this hybrid model which was the clear selling point for it.

The native support for Waterfall and Agile software development was very important in our decision to go with the solution because we knew that Waterfall and Agile will co-exist for quite some time, and the tool had to be able to manage both in parallel. Also, for the future, it will still support what we want. If the shift goes more to Agile and less to Waterfall, the tool still has to support both of the methodologies.

Because we came from ALM QC, and that tool was in use for quite some time, there were a lot of user-defined things and customization. Initially what we had to do was a cleanup on the QC side: what we wanted to take over and what we didn't want to take over. We really cleaned out stuff that wasn't needed anymore. That took one or two months. 

The actual installation of Octane was very quick and straightforward. The customization and configuration of Octane took about two months. That was because we were very new to the application. If I set up a workspace now, it's much faster.

We have 1,100 users and their roles are really across the company. We have project managers, developers, testers, release managers, and test managers. We also have business users and product managers on the Agile side. Any role you could think of is using it, apart from the C-level.

What I like a lot about Octane is that it's very easy to handle from an admin point of view. The maintenance is very low compared with ALM QC where it took several hours or days, even, to set it up and upgrade it. Those processes are very easy with Octane.

I compare it, still, with ALM QC, and there's definitely a return on investment on it. I see this leveraging more in the future.

The comparison is always with Jira, so the pricing of Octane is a bit on the higher side. But if you look at what you have to add to Jira, on the plug-in side, to have the same abilities you have with Octane, you're more or less even, or even ahead with Octane.

We only looked at Jira. We had some concerns about its reporting capabilities and its task management capabilities, as well as managing Waterfall and Agile in parallel.

You definitely need to prepare well, if you're going to implement it. Do a proper analysis of where you're coming from and what is still needed and what is not needed, and really kick out stuff that isn't needed anymore. It will make the whole migration to Octane easier when you have less historical data in it.

I see that our users like to add things and try new things because it's built in an open manner. When you add Python scripts and use the API connection, you have a lot of flexibility for doing certain things. I see some developers who like it and who like to experiment with how to work better on their side.

We have started a PoC on integrating the solution with our CI server for continuous integration and delivery. The CI/CD is working and we're fine-tuning it now. I hope it will give us a one-click approach where we can even execute the pipeline from the GUI, which will make it easy to use. My vision is that we have all the pipelines integrated in Octane and that we can trigger them from there to speed things up and have them visible for developers and for testers. This would also be a way they could collaborate more. We're not there yet. 

It has the potential to reduce integration costs by building a streamlined application delivery pipeline that is connected to all IDE, CI, and SCCM tools.

Octane can also provide a single, global ALM platform that supports all our Agile and Waterfall needs. We don't have all our Agile in yet, but it can. That's the vision: that we have them all in one tool. We're not there yet, but I see glimpses of hope. It has the potential to improve the quality and the speed. The potential is there.

It still has upside coming. Things are being developed. We are in the preferred partner program, so we see also the new features that are coming, which will facilitate daily work.

I work for a state government in the United States. So our business constituents have departments that use it. And we have analysts who build business cases in the ALM Octane for specific tasks or specific projects that we're working on. We create business rules for each project in ALM Octane. Then, when the developers finish coding and we're getting ready to test, we use ALM Octane again to test against the business rules we created. So that way, we know we're meeting our business objectives, our customer's requests, and what they want to be changed in our system.

It's more streamlined because we have it all under one umbrella. And once the business requirements and rules have been created, we can do test cases and apply them to the business rules. So we're able to make sure that the developers' code is tested thoroughly to meet the needs of the business.

It would help us if ALM Octane got FedRAMP-certified, so our government departments could use the cloud solution. That way our external consultants could access it. We've created a URL to get to it, but if it were FedRAMP-certified and service and had support in the continental United States, that would be better. In the government space, we need organizations or companies to be FedRAMP-certified, and the system must reside in the continental United States. The Micro Focus help desk and their environment are not located in the continental United States, so they do not meet the state's criteria for us to be on the cloud. I understand that the company is working on some FedRAMP certifications and is looking to do that because they cannot put all of their government customers in their cloud environment. It's not a technology issue. It's a security issue.

So we've been using Micro Focus for almost four years now, but we just recently migrated to Octane back in July of this year.

ALM Octane is very scalable. We have a great server team that we use to increase its space or size. We handle it internally, but it works great. 

We have worked with Micro Focus support, and they're very good. I'd say 9 or 10 out of 10. They're always available. And if they don't know how to fix an issue, they know to talk to. It may not be the person you're talking to or the person they've referred them to, but they know somebody who could help. So they know how to escalate within their organization.

So before July, we were using IBM DOORS Next Generation for business requirements.  Then we decided to consolidate the business requirements, testing, and defect management into one system, and Octane provided that solution for us. So we were able to decommission IBM DOORS Next Generation for business requirements after our July implementation to ALM Octane.

We looked at Micro Focus ALM minus the Octane solution about two years before they decided to go with DOORS Next Generation. And they selected DOORS Next Generation, but IBM's integration with Micro Focus wasn't very mature. So it required a lot of manual tinkering to get the two systems to talk together. Finally, after some analysis about how much time was being spent, staffing resources, etc., we just went with ALM Octane.

Setting up ALM Octane is straightforward because we were already using Micro Focus ALM for testing. We were implementing it in the business requirements area. That was four years ago, so I can't remember exactly how long it took, but it was a few months. I'd say maybe two to three months. We did it on our own with Micro Focus guiding us. And Micro Focus had a statewide user base at the time. Other departments were using it, so we were able to share what everyone was doing. I have two FTEs. One is in charge of the business requirements module, and the other oversees the test testing and defect management.

I think the cost of ALM Octane is comparable to other solutions. It's actually a little less than DOORS Next Generation, but I don't have the numbers in front of me.

I rate MicroFocus ALM Octane eight out of 10. It's a great product. If you want to integrate your business requirements with your testing and defect-management tracking, it works beautifully.

I mainly use ALM Octane for product teams and Agile teams.

The biggest problem with ALM Octane is that it's very complex, so it's difficult to use and scale. The graphics could also be improved, and CSD could be added.

I've been using this solution for over a year.

ALM Octane is stable, but its performance isn't so good.

The scalability isn't good.

Micro Focus' technical support is good.

Positive

The initial setup was difficult and took over three months.

We used an in-house team to implement.

ALM Octane is very expensive.

I compared Octane with Jira, which is better-priced and more user-friendly than Octane.

ALM Octane is complex and difficult to use, so you have to be willing to train the people who are going to be working with it. I would rate it five out of ten. 

It's the most powerful tool to do Agile framework. It's very lightweight, and the tool itself is built based on Agile methodology.

My favorite feature is the user interface, how easy it is. And also how the modules are segregated in Octane. It is based on the Agile framework so it looks exactly like how you would develop your applications using the Agile framework. You get into user stories, you get into Epics. Everything has the same names so you don't need to interpret what is what. You can get into it right away.

I say to our customers, "You can just get into the tool, and just follow the process." That means you are doing the job, like you got into the Agile methodology.

I like the flexibility that I have working with them, starting from licensing it. The SaaS aspect, the hosting that they are doing, the way they respond to our requests, the way that I can escalate. And the way that we are working with R&D right now.

For one, it's the whole Agile framework itself. You're cutting the time, the wait stage, and all that. We wanted a tool. You could do Agile methodology on a whiteboard, by using Post-Its. But practically that is not going to work out because the teams are in different locations. For example, our development team is in India.

So we have to have an enterprise level tool which can support everybody. So now we can create the same "whiteboard" and the "Post-Its" in Octane, and everybody can see it around the world. That means the people who support our service, the development teams in India. And the functional team sitting here in the U.S. It's the "collaborator thing." That happens using the enterprise tool.

I can't say, as I'm not completely technical. But we do have someone working with R&D directly.

We provide them feedback after they asked us for it. We are meeting once a month with the R&D team. And then we'll send them the list of things that our customers are asking for, or which are missing from ALM. And they will tell us, "Oh, this is coming in this release. That is coming in that release." And if there is something that is missing they will say, "Yep, we will include that in our next release." They take feedback from us and then do it.

I have some problems with the way they license things because HPE is a hardware-come-software organization. I think that will be solved by moving to Micro Focus. Yesterday I had a meeting with the executives and I told them the same thing, that I hope this is one area that I want them to be improving. This whole licensing issue, it's so complicated. They agree. They wanted to set it as one fits all. But hardware is different than software.

Right now it is pretty stable. The thing is, it is continuously improving every two or three weeks, they are releasing new features in Octane. We are one of the customers who started way before it was as a prime-time tool. So we are educating our customers telling them there are things that are coming. Also, we work directly with R&D to know what is new, what is coming.

For example, last month, we didn't have the testing module at all. In ALM we have the testing module. And our customers are so into ALM.net, and when they didn't have the testing module they freaked out. But we said, "Don't worry. It's coming." And it came within a couple of weeks. They got hooked up and they started working.

The product is stable. Whatever they release, it is stable.

We haven't tried scaling yet because we just started and we have about 20 projects in there which are not such big projects. But we haven't had any issues so far. We have confidence, after using ALM for so long, in scalability, the way HPE - before Micro Focus - are doing it. We hope that, they will do the same thing.

We are directly dealing with R&D in most scenarios. For example, one of the things is we are struggling with is to get some of the reports we want. It's not that flexible to get the reports because we are SaaS and we don't have direct access to the database to see how many users are live at a point.

But tech support are good. They are responsive.

It's straightforward. Because it's a SaaS application, we got access to the server. And then the URL was sent and we started using it. So it's that straightforward.

When Octane came to us it was a beta program. They said, "This not prime time yet." We evaluated a couple of other tools, like JIRA, which is one of the other tools that we have in our organization right now.

But the integration between JIRA and ALM wasn't there. JIRA is not our standard, actually. But we do use JIRA because developers really like it. What we wanted to have is the integration between tools. Right now we are using AGM in our organization, which is integrated with ALM.

So that's where we thought that Octane - even though it was a beta version at that time - we would take it and do a PoC and see if it works. And we thought it's really good because there is a lot of investment being done on the tool from Micro Focus.

We like how simple it is. It's easy for people to understand. Self-taught and they can work on it. A lot of our internal customers are using the tool even without formal training. They are self-teaching by going through all the resources. So we evaluated it and finally decided that it would be good to use Octane. We made that our strategy.

Comparing Octane and JIRA, I don't really know what the advantages are from JIRA. For Octane, it is primarily the integration with all the other tools that we have right now. And, as I was saying, it's simple to use.

And the changes - the way they are building the tool - we are part of the team which is building the tool. So we can always provide our input and make changes. We don't have that with JIRA. JIRA is there, but it's not used as a lifecycle management tool at all. We wanted to have a lifecycle management tool. So that's the reason.

When selecting a vendor, it depends on the product and how much they are investing in building that product. We don't get tools because we just like the tool. There has to be the need for the tool itself. It's important that they are able to support us and that they have good customer feedback or references.

If you are looking for any Agile tool, I would definitely recommend ALM Octane. Not only because it's a Micro Focus tool, but the way that they're investing in the tool. And the ease of use. Our customers were scared before, but now they are loving it. It's a really simple tool. And it's more powerful.

We use it for application lifecycle management.

We had projects in which we had the Agile part in a specific tool and the testing parts in another tool and it was very difficult to synchronize all that together for a reasonable price. Of course, you can buy tools to synchronize the different tools together, but to buy synchronization tools is very expensive. You have to handle that and if something is badly synchronized, you have to redo it by hand. So to have all that included in just one tool really makes our life easier.

Another benefit is the integration with Continuous Integration tools. Before, we had to upload all the test results either manually or automatically, but we had to write the scripts for that. With Octane that's just native, included in the package.

Finally, it consumes fewer resources than the previous tools in Quality Center. We have the same number of users but with half the servers. It's really economical from that perspective.

The most important feature is the integration of all the different features in just one tool: Agile management system, requirements management system, test management, defects management, automatic test execution. Really, if you're looking at other tools, you will never find all that integrated into just one tool with all the traceability, with all the elements in just one place. For me, that's one of the main advantages of Octane.

Globally, I don't see many major points of improvement. It's mostly plenty of little things, and it's weird to me that they are not in the product yet. They are really details, but they're annoying details. I'm sure all these features will be included in Octane in the following month or year because I talked with their R&D so I know they're working on it. But it's just awkward that some points are not there yet. 

Let me just give you an example. Today, in the tool, we've got plenty of assets we can handle, like requirements, user storage, defects, tasks and so on. And to all of those elements, we can add comments. We can add comments to any asset in Octane but not to tasks. It's just impossible to understand why it's not available for tasks because it's available everywhere else.

Similarly, for attachments, you can attach files absolutely everywhere except for automated runs, which is, again, awkward. I don't understand why for this element, in particular, you cannot do it. It's little touches like that. 

The Kanban boards are pretty easy to use and easy to configure. The only thing is that you cannot set a specific color for a specific card, depending on the value of the field. It's a really simple feature, very easy to implement because I implemented it in some other tools that I wrote. So I know it's easy to do. It would be really nice to have that, from a user-experience point of view, but we don't have it yet.

It's really little touches here and there that are missing.

We started from the very beginning with Octane, the very first versions that were released by Micro Focus, and the quality was really high from the beginning. We haven't had any major issues. It's mostly those small enhancement requests we are asking of them. But otherwise, it's working.

We haven't put scalability in place yet because of what I explained earlier. Previously, we had two servers for our Quality Center system platform and, with the same number of users, we've got just one application server with Octane. We haven't used the scalability yet.

We don't have a contract directly with Micro Focus. We bought our licenses through a partner, so we are not supposed to have direct support from Micro Focus. However, I personally know people from R&D, so I get support from them directly, although it's not the official way to do it. However, all the questions I've had have been answered very quickly and they are very efficient about it. So I expect that if I had a contract directly with them it would work like that. So support has been very good.

We were using the Quality Center Solution from HPE before and, in that solution, we had no way to handle Agile projects. That's one of the reasons we decided to move to Octane, which includes an Agile management system with the test management system and requirements management system that are available in Quality Center. Octane has more features than QC, especially for Agile methodology. It also has all the features to connect with the Continuous Integration tools, and that's very important when moving to DevOps.

Quality Center is totally obsolete today and Octane has all the new features we did need like Agile management, full web GUI, and connection to the Continuous Integration systems, as well as many others.

The initial setup was in between: not very complex, not so simple. Medium.

We are currently in something of an "in-between" situation because we are still using the old tool and moving to the new one. We have a transition period in which we need to maintain both tools at the same time. It's a difficult period with more work because we have two tools instead of one. We need time to move from the old to the new one. We will stop Quality Center, the old tool, in one year. At that point, things will be much easier and much more cost efficient than before, for several reasons.

First of all, Octane is automatable with APIs, so we have automated everything that we can for the users: project creation, user management, and the like. With everything automated via the APIs, we don't have to invest in people to support our users. That makes it cost-efficient.

Secondly, it's cost-efficient in terms of the platform. As I said, we use half the servers compared to what we needed for QC.

Also, a project in Octane can handle everything that is needed. We don't need to have two or three tools to handle different things.

It's also efficient because we have less training for users, and there is less expense for synchronizing data between one tool and another.

Putting all that together, it's really more efficient.

Pricing is the weakest point. It is expensive, but the tool has plenty of features. The main problem we have is that the pricing is very high compared to some other solutions.

We evaluated several solutions. One is called the Tuleap, which is open-source. Globally, it's a software development forge. The problem with that solution is that it's lacking test management, primarily. Then we tested another open-source solution made by a company named Henix, called Squash, which is a good solution, especially for open-source. It's just missing an integrated Agile management system. We also looked at JIRA but it does not have a test solution system and I don't like Atlassian politics very much.

Just jump in, go ahead. Don't try to understand everything before starting. The tool is really easy to understand for users. We don't even give training to our users today, they just jump into the tool and use it and they immediately understand how to use it, so it's very cost efficient for us. We need very few people to do training. Don't hesitate to use it, whatever your development methodology is. 

You have no obligation with Octane. There are plenty of features but you can use just a few of them and, after a while, when you get used to it, you can use new ones, and so on. You don't have to use everything at once and to understand everything at once to use the tool. You can just build on what you're doing and, month after month, use new features. Just go ahead and use it.

There is a free trial of the SaaS solution, so users can jump in and use the free trial to understand how the tool works, to see what it looks like, and so on.

I rate this solution at eight out of ten. I'm mostly positive about all the technical aspects. It's just loaded with features. It's very efficient. It works well, there are very few bugs. I don't rate it higher mainly because of the price.

What we're doing is a cloud migration program. We're migrating about 70 applications from on-premise centers to the Amazon Cloud. That migration is primarily using Octane to store manual test cases and for a manual backlog of user storage to migrate each application. We're also using Octane to record the results of automated testing and performance testing.

The integration points are very good. Octane gives us a window not only into our manual testing, but also our automation testing and our performance testing. We can see all results from all three streams of testing in one place. We've never done that before, until this past year. Whether that was possible with Quality Center or ALM.NET, I really don't know, but it's the first time we've ever done this. So the fact that it gives us that window into all phases of testing is where it's a bonus for us.

The whole thing is geared towards Agile deliveries. It certainly has a good GUI, it's good to look at. The features provide good impact. It lends itself very well to Agile deliveries.

So far the stability has been okay. The stability is: Is the server up and running? In the last year we lost access, maybe once, for a couple of hours. Because it's a SaaS product, we don't know why it came down. We just know that it became unavailable to us. But on the whole, it's been pretty stable. We're not intense users just yet. We will be. In six months' time, we won't be able to afford any downtime really. But we're not an intense user right at this moment.

We may have not noticed when it wasn't available. But in six months' time, that story will change. Obviously, as part of our DevOps pipeline, we will really expect it to be up 99.9999 percent of the time.

In that one occurrence, they reacted quite quickly. We raised a ticket and then had an instant response. They said, "We're looking at it." I can't remember what the actual resolution was. I find Micro Focus quite reactive to issues.

I think it would scale. We've not needed to scale too much yet, but it seems scalable to me.

I think that the biggest obstacle to scaling with this particular tool is the licensing. You predict what licensing you need for the year, a whole year, and you're stuck with that for that year, unless you pay more to scale up. That's always a challenge. The challenge is not the scalability of the solution but the scalability of licenses.

We've just upped our licenses to 25. We started off with ten. Once we get to steady state, in some six months' time, we'll have about 30 steady-state silences.

Regarding the increase in usage, we'll push more work through it. Right at this moment it's just one program of work. Once we're happy with the way we use it, the stability, we'll then push all our organization's work through Octane, rather than ALM.NET. At the moment, the majority of our work is going through ALM.NET. It's just this transformation program that I mentioned where we're using Octane. It's almost a proof of concept for us. If it works with that program, we'll make it work for all programs.

Tech support is okay. So far our experience with them has been positive. They're certainly quite quick to react to the initial issue. Because they've got this "follow-the-clock, follow-the-sun" support model, there have been times when we have raised a ticket and has gone over to a resolving group in South America, and there has seemed to be a time lag in getting our updates. That can be a problem but, because we're not an intensive user yet, I'm not sure if that would manifest itself a major problem.

The initial response seems to be good, but sometimes the follow-up is not quite as quick as you'd like it to be.

When we've asked for details, we've received details. They don't seem to hold too much back. When we've pushed them for detail, we've gotten it.

We were working with Micro Focus on our cloud transformation program. We included them and a lot of vendors, but we had identified the Micro Focus set of tools as the tools we should be using for our DevOps pipeline. That was made through a process of evaluation of other tools. At that point, we engaged Micro Focus and said, "Look, this is what we want to do. How can you help us?" At that time, Octane was just coming off the production line and they said, "Well, we've got this new product which might work better for you." They made that product available to us. So we looked at it at that the suggestion of Micro Focus, given that this new product was coming out.

We'd always had what used to be HPE before it was Micro Focus, so we'd always used the variations of HPE testing tools, ALM.NET and, prior to that, Quality Center. We did some research with industry reviews and, obviously, the Micro Focus set of tools were in the top quadrant. Because we had the relationship anyway with Micro Focus we decided to stick with that toolset.

It was a natural progression, plus the fact that the review sites had the set of tools in the top quarter for being the most integrated set of test tools. We were looking beyond test management tools. We were looking at automation and performance, and the recommendation from those sites was that Micro Focus had the richest set of integrated test tooling. That led our thinking quite a lot.

I thought the initial setup was pretty straightforward for us. We started off with ALM.NET on-premise. We then took the SaaS offering. So our initial challenge was to migrate our existing ALM.NET projects into the SaaS product. We then were made aware of Octane, which was made available to us quite easily, and we were able to start using it.

What we didn't do, because of various challenges with our program, was we didn't really get too involved early because we weren't ready. So although the tool was ready, we weren't ready to consume it. But in the last few months, we've made quite a few strides with that. We're now at the stage where we need to say, "What more can give this give us?" There's a lot we can do. What is it we want to do? That's probably where we are now.

Our implementations strategy for Octane was quite simple. Because we've got this program of work, which is a cloud transformation program, we used that program as a proof of concept with Octane. That program worked, which is lifting and shifting 70 business applications. They are being migrated from on-premise to cloud, and each one of those migrations, on an application-by-application basis, is being managed by Octane. So our implementation strategy was to use it for this program of work. Once we realized the good and the bad, we could then start implementing it across the rest of the organization.

The staff from our side required for deployment was none. For us, it was just a request to Micro Focus and then agreeing to pay for licensing. It's a URL, basically.

For administration within our organization, the overhead is that there are several admin tasks, such as creating new backlogs, creating users, and administering users. It's no more of an overhead than with any other test management tool. The admin side is still the same. You have to set up your folder structures, you have to set up the users, you have to disable users when they leave the organization. It's simplistic and it's quite easy.

Here, because we're quite a small organization, we've got three people with admin rights, and between them they handle requests as they come through. We've got a site admin and a project admin. It's a layered type of admin, as much as it was in the previous products. The site admin can do everything and project admin can do everything within that project.

The product was there for us. As soon as we requested it, it was made available, so there was no implementation, as such, for the product. It was down to us to make use of it, and start creating our backlogs, and our structures, etc.

We relied on the help we get from Micro Focus. There are some good online video tutorials from Micro Focus. We made use of those. We made use of Help topics on the product. Other than that, for any issues, we would raise a ticket with Micro Focus. We didn't actually take on formal consultancy.

I don't think we've reached the point of ROI yet. For return on investment, we're looking at about 12 to 18 months before we start seeing that return. Our return will come when we automate more testing, when we show those results in Octane, and start making more use of the Octane dashboard. That's when we'll see a return on investment.

It's expensive. HPE products, and now Micro Focus, have always been expensive. The license is not cheap, and it will always be a challenge, particularly for small organizations like ours.

It's a good product. You need to consider the cost of it. We didn't do too much comparison against other tools, but I always felt that this product didn't only give you a project view, it gave you a program view as well, which some of the other tools don't. With this tool, you've got a program. You can see multiple programs. If you set up your dashboards correctly, you can get a much wider organizational view. That's where we need to play a bit more with it, to get more out of that capability.

I would advise others to consider the expense, maybe look at other tools, to see if they can do what they want to do cheaper. For us, we felt it was worth the investment.

I don't think we're quite mature enough yet to be able to say that it has improved our workflow. Where we are now, we've proved the integration points, we know how we can use the tool, we know how it can benefit us. But what we haven't done is actually reaped the benefits of that just yet. But in six months' time, we'll see improvements to our workflows and we'll be making more use of the tool for that aspect. We're quite immature in our journey at the moment. Although we've had the tool for a year, we haven't started to use it in anger until the last few months, where we've input all those integration points. Now we've got a set of integrations where we can do exactly what we want to do and now we need to decide how best to use that to improve our workflow, etc.

We're introducing an automated pipeline. Our end-to-end DevOps pipeline starts with ServiceNow, where we will request an environment. That request will be picked up by Jenkins, go off to the Amazon cloud, and stand up that environment. Jenkins will then orchestrate a set of automated tests, using UFT, to make sure that environment is working, and it will pass results back to Octane. At that point, a notification goes back into ServiceNow to tell the requester that, "Your environment is available, and it's been delivered." That's the kind of pipeline we're delivering for each application that we might write. In theory, we'll automate as much of that pipeline as possible. We are on that DevOps journey. It's still a work in progress for us.

Regarding the biggest lessons learned so far from adapting tools and processes for Agile and DevOps, I think it's the culture, spreading the culture within your organization. Some people don't like change, they don't like new ways of working. So the cultural issue, the people issue, is a challenge. 

When it comes down to tools and technology, it's the integration points; doing some proofs of concepts to prove each integration point works and finding out where your limitations are. We found some limitations in what we want to do on the Amazon cloud, which we weren't prepared for. The lessons learned for me are: We should've done many, many proofs of concept, small proofs of concept, to prove each point of integration, and then bring all those small proofs of concept together. If I was to do this again, that's exactly what I would do: small proofs of concepts before trying to build anything in an end-to-end fashion.

In terms of how Application Lifestyle Management Tools can help with the transition from Waterfall to Agile, Octane was created very much with that Agile focus. It gives you that set of tools to create the environment, to create your backlog, to create your sprint, and to give cadence to that and give a reporting view of where you are at. Also, it's not just at the project level, you can do it at the program level. We need to start looking at things from a program level, and how we can expand out. It's the views it's giving you, and the tooling that it's giving you that fully support that Agile-type delivery. We've made it work for a Waterfall-type delivery as well. It's giving you everything you need, for whatever delivery you want: the project view and the program view.

I work for a section of our company where what we do is host enterprise tools that our consulting projects can use. Potentially, as we get more and more users, we can have hundreds of projects at a time. We're not a typical use case where we have one way that we're using the tool. The tool is being used on various consulting projects.

Our use cases vary drastically. We have some people who have told us they just use it for testing, there are some people who just use it for defect management. People are familiar with other tools, like JIRA and ALM and even AGM. Octane is new, so some people are trying to take baby steps into adopting it.

Day-to-day, how we typically use it, and how we're promoting it should be used, is for Agile project management with manual testing, including release management, sprint management; end-to-end type of use. We use it to manage our releases in sprints. Other teams within my group also use it for testing and defect management, and that's how we promote it, and train our consulting project teams to use it.

For our use case, it's brought our entire team into a single tool. We're all looking at the same real-time data. Our project management office has been able to set up dashboards for individual teams, and do comparisons by teams, of integration, and cross-team integration, burn-up, burn-down, and cumulative flow types of things. So from a PMO perspective, there is a really good overview, from how we've set up our dashboards, to know where each team is and how they're progressing and how much work they have that integrates with other teams. That's really helpful.

The feedback that we've gotten is that the way testing is closely tied into the product Backlog has made it more intuitive, or easier to manage the relationship between building out an application and testing it. In other tools, that is more segregated. The way it's designed in Octane, people have said it makes more sense to them, and that it's easier for them to understand their data and to maintain and test their solutions.

Very generally, the feedback that we've received is that people really like the user interface overall. It's intuitive to use, it's easy to learn, people like the usability features, the user experience. 

Another thing that people really like about Octane is how easy it is to customize. In some previous tools, that has been very limited, or you had to know how to write code to do some of the customizations, or it was very confusing. Going back to the user interface, they've made the customization of the tool, the workspace settings, very easy for people to figure out and use. We've gotten a lot of good feedback on that.

In general, I think people really like the Team Backlog and the capacity bucket for each individual team member. They like that ability to track capacity and progress very easily that way, by individuals.

I work pretty closely with Micro Focus, particularly on ALM Octane. Right now we have a backlog of some 60 or 70 enhancement requests, varying in priority from very high to low.

In general, there's a trend in our requests to have the ability to export data, en masse, out of Octane. There are capabilities within Octane to export data, but there are specifics around test suites and requirements and relations, as well as certain attributes, that we would like to be able to export easily out of Octane and into a database or Excel.

One of the things that a lot of our project teams have complained about is the simplicity of reporting that's available in Octane, and that they have to export data out of it in order to create the types of reports that their PMO or their client wants to see. Octane provides solutions around OData, and integration into reporting tools, but what people really want is smart and good reporting, advanced reporting, within the tool. They don't want to have to go out to another tool for reporting.

In general, we also have some requests to beef up the manual testing abilities and the ability to report on testing progress. All the basics are there, but there's an issue of maintainability. For example, one thing that we brought up to them recently was: Once you plan a test and it creates a run, more particularly a suite run, you can't edit the suite run afterward. It locks you in, and we're saying that that is not realistic with how people work. Mistakes are made and people are humans and we change our minds about things. So the tool needs to allow for a bit more flexibility in that testing area, as well as some better widgets to report on progress.

Overall, we haven't had any issues with stability. There are two things that do come up.

It seems like we have issues with Elastic, the integration to it. Intermittently we have these issues where global search isn't working, or widgets aren't populating, so there's something a little bit unstable with that integration. It could be on our end, or it could be something with the setup, I'm not sure.

We're also having performance issues. It's not really stability, but we do see some slowness in the system and in our performance testing, so we're working with Micro Focus on that to figure out how to resolve those issues.

The performance issues that we have come about when we have load on the system. We're trying to figure out if the source of those issues is the environment, and what the optimized settings would be for the environment: memory size, number of disks, things that we're doing in our performance testing, etc. But we're also looking at the software to see if there are any issues there.

We are working with about 180 to 200 concurrent users, which isn't a terribly high number. We're looking at all sorts of angles but we're currently in the middle of it, so it's hard to tell what the source of the issue is.

Micro Focus has definitely been good about helping us out with all of that, giving us advice, hardware related, on what our settings should be. Maybe we're not sized exactly correctly. According to Micro Focus - they also, of course, do their own performance testing - and they haven't seen the results that we have.

Because we're a partner and we've been working with them for years,  we'll have quick calls twice a month, at least for Octane, to talk about new enhancement requests that are coming up, providing them with feedback on the tool as we're hearing it from our project users, and to review our highest priority requests and their statuses and if they have been included in their release planning for upcoming releases.

We have a pretty good dialogue going back and forth with them, so we know when to anticipate the functionality that we're looking for is going to get delivered. That helps us when we're making decisions around which upgrades to take.

Tech support does a pretty good job. Sometimes it's a little frustrating because they're the Level 1 support, the helpdesk support. They often are trying to rush us to close out tickets. I understand that they've got metrics, but that part is a little bit frustrating.

When we get it escalated, when we're working with their research and development or with the customer service contacts that we have, they're much more amenable to our requests. They like listening to what we need and the type of support that we're requesting. They take us pretty seriously when we escalate and have high priority issues, and they really try to get us resolutions as fast as they can. We definitely appreciate that.

We have ALM implemented and we're still using AGM. We are making the switch to Octane because we implemented AGM with integration to ALM so that we could have Agile project management and a manual testing tool for our project teams. The nice thing about Octane is that it doesn't require integration. Integration always introduces a potential for points of failure. If you can house those capabilities within a single tool, why not go in that direction? It provides ease of use, less maintenance, etc.

Also, this is the direction the vendor is going in. Several years ago, our organization made the decision to go with HPE, now Micro Focus, for the majority of our suite of enterprise tools. We're following the direction that the vendor is going, but also recognizing that there are advantages to the tool that has good capabilities. We're not blindly following them, we're doing our assessments and saying, "Hey, this looks like a good thing for us." Of course, if it requires fewer tools, less maintenance, less setup, we'll go in that direction. That's how we made the decision to go with Octane.

There are other things that we haven't deployed yet, but the advantages of the direction they're going in for integration into the DevOps world to support CI and CD, that's a direction we want to go in. I'm on the Agile solution team, but we have the testing solution team, so they're very interested in those types of capabilities as well. Octane is opening that door for us to get more and more functionality hubbed in a single tool.

I don't do the software installation or that side of things, but in terms of our implementation strategy, we have four environments in which there are seven servers. In our lower environments, our base environment, we have one server that gets installed. 

We don't have any integration that we support currently, so it's a standalone environment. We do integrate into an Elasticsearch farm, as well as to LDAP for user creation, password validation, etc. We have those basic types of integration setup, but we don't have integration to other tools such as DevOps tools, yet. We are currently working on integration to PPM, and that's going to be deployed in the next couple of weeks.

Once we get up to our stage and production environments there are multiple servers on a load-balancer, so that adds an extra degree of complexity to the setup. They're also externally exposed to the internet so that our clients and external users can have access to the tools.

It was just us and Micro Focus.

We did not evaluate other options before choosing Octane. At that point, we were in pretty deep with HPE. But before we chose HPE as our vendor for the bulk of our enterprise tools, we did an evaluation of different vendors, different suites of enterprise tools that we could possibly host, before we made that decision to go with ALM and AGM and UFT.

The way that we approach it is that we don't rush into a decision and say, "This is the tool that we have to use." One thing that's nice is that there's always an option for a SaaS trial for 30 days or 60 days. Micro Focus has been very kind to us and given us extensions on our trial versions so that we would have enough time to evaluate the tool and the SaaS version before we make a full, educated decision about how we want to move forward. That's a good place to start: Plan on getting a trial version and plan out your assessment, what your objectives are, what your requirements are for the tool, and then just get in there and start using it.

I use Octane in my day-to-day work, but I'm mostly an administrator of the tool's usage on our consulting projects.

With respect to how tools and processes are evolving to adapt to the change from traditional Waterfall, one of the things our organization is finding is that it's not a switch that you turn on - that you're "traditional" one day and you're "Agile" the next. So, having tools that are flexible enough to accept variability, and that are flexible enough to adjust to project teams transitioning and becoming more Agile as they go along, is important. Octane, because of some of the additional features that are there and that are not in some of the other Agile tools we've looked at - like the Quality module, the quality story, the ability to customize workflow and business rules, and also having the Requirements module - lets you still be a little bit traditional when you need to be, while you're learning to become more Agile. There's some transitioning that the flexibility in Octane lets you do, where other tools might be more rigid in enforcing pure Agile project management.

As for lessons we've learned about adapting tools and processes for Agile, I feel that's very similar to what I just said. It's this journey that people are on. Where we started was with very traditional project management tools and, as Agile became more the trend, we recognized the need to add more tools into our landscape that would support it better.

The way that we work is that, while we host all of these enterprise tools, we don't enforce that these are the tools that are to be used on projects. We have to be a bit more flexible than that. Recognizing the need to have enterprise tools available for project teams that couldn't find their own tools, or clients that didn't have their own tools, that's where we brought in AGM and then, eventually, Octane when it came onto the market.

The other thing that's helpful to recognize with this transition, is that you can't become Agile on day one, once you make the decision that's the direction you want to go. It's very good that we have the ability to integrate our more traditional project management tool with our Agile tool. Currently what we support for project teams that are doing a bit of both, what we used to call "hybrid," is their integrating of their Agile project management tool, like AGM or Octane into a traditional workplan tool like PPM so that they can see the full breadth of their project progress across both more traditional tasks and Agile tasks in a single place. We're bridging that gap by using multiple tools and integration.

In general, ALM tools help in the transition from Waterfall to Agile because you have a tool enforces some processes, and provides a little bit more rigor than you would have otherwise. Having those ALM tools available has helped us enforce some consistency and adherence to Agile processes.

To date, we've had 136 projects, that's 136 workspaces, and about 1,000 users.

In terms of increasing usage of Octane, we deployed AGM and ALM four or five years ago. The problem in our organization - and this is another thing we've talked to Micro Focus about, and they're hearing similar feedback from other places - is that people are used to what they know. If people have used AGM or ALM on a previous project, they're just going to go with that.

We do have some early adopters. People have been keen, they've heard about this new tool Octane, checked it out, and those early-adopter types were on the bandwagon pretty soon. There are some people that are lagging behind and kind of skeptical. We're dealing with the psychology of that. Part of that is knowing there is not really a great reason for us to continue supporting two tools that do very similar things. AGM and Octane have a lot of overlapping capabilities. We're looking at our strategy for how long we want to continue to maintain and support two tools that do the same thing.

We're trying to encourage people who are used to using AGM, or are leaning more that way, that they should come over onto the Octane side, because that is the direction that the vendor is going in. That's where the investment is going, and that's where all the new functionality is coming out. We're trying to increase adoption in a variety of ways to get those people onto the Octane side.

We have an assessment planned early next year to strategize when we might scale down AGM, and maybe even cut off provisioning new projects, but we don't know the timeframe of that yet.

In terms of maintenance of Octane, their roles are project manager-types, people who do the server administration, and DBAs. There's also a QA group and a PMT group that we enlist on a very short, annual basis to do our performance testing.

I would rate Octane at seven out of ten. There's definitely some functionality that I think could make our lives a lot easier, especially around the extraction of data and the reporting. Those things would really help us out. I'm conservative on rating things.