Micro Focus ALM Octane Lessons Learned

What are your biggest lessons learned about adapting tools and processes for agile and DevOps?

Mike Smithson
ALM platform architect at a transportation company with 10,001+ employees
In terms of our biggest lessons learned about adapting tools and processes for Agile and DevOps, building templates and standards that have provided a lot of value in a Waterfall approach do not migrate well to an Agile practice. Previously, we focused on testing, mostly in isolation from requirements and development. Moving to Agile in Octane switched the primary usage to backlog (requirements) focus. The challenge has been to bring focus back to testing and quality delivery in concert with backlog management.
View full review »
Process Owner E/E Test Management at a transportation company with 10,001+ employees
In terms of lessons learned in this process, the benefit is that we try to be much faster and work in smaller iterations, delivering new functionalities faster.
View full review »
Gerd Fladrich
Test Manager at a financial services firm with 1,001-5,000 employees
The biggest lesson about adapting to Agile for DevOps is that it is really important to have APIs, to have open interfaces to connect all of these tools together; to have the chance to implement the pipeline easily. We are no longer bound to only HPE or Micro Focus tools. We can work together with open-source tools. It was easy to implement such things in Octane. This was a great lesson.
View full review »
Senior Expert IT Test Service Management at a financial services firm with 1,001-5,000 employees
When it comes to the biggest lessons learned about adapting tools and processes for Agile DevOps, I think it is really important, in the scope of evaluating the ALM Octane for a transformation, to have all stakeholders on the same page, and to have their opinions and experience included. In addition, define the process first and then go on to the choice of tool.
View full review »
Timothy Leach
Senior Software Engineer with 10,001+ employees
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.
View full review »
Jennifer Plourde
Enabling Manager at a financial services firm with 10,001+ employees
As for lessons we've learned about adapting tools and processes for Agile,... 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 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 in. It's very good that we have the ability to integrate our more traditional project management tool with our Agile tool.
View full review »
Programme Test Manager at a energy/utilities company with 1,001-5,000 employees
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 concepts 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.
View full review »
Steven Tompsett
CDA Engineer at Hastings
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.
View full review »