Predominantly, we are using LeanKit for our agile management. Basically, we are a PMO. We belong to the PMO organization within our company, and we deploy products that are used by our project management team. Typically, we use LeanKit for that purpose.
LeanKit is a SaaS application. They update the version, and everybody gets the same version, as far as I understand. I don't think we are going to be in a prior release and then jump into the new release.
We have a monthly release cycle. Before using the LeanKit board, we used to use many other tools, and we always would see the crunch on the day we needed to release. Sometimes, our work would extend into overtime. We have also seen some of the features slip through the cracks in the sense that we would miss releasing them. It was, in a way, a bit chaotic. Once we started using LeanKit, we haven't missed a single feature from deployment. We are also able to better manage the capacity so that we're not over-booking ourselves for work where there is no capacity, and that has really helped. For over a year now, we have not missed any deadline.
It helps us not to over-promise. Basically, the motto we all have is "Under-promise, over-deliver." That's what it helps us do. So, we know what we plan to deliver, and we don't crush ourselves by promising beyond our capacity.
We use LeanKit's board and card hierarchies. We have an initiative board, which is basically a high-level board where any new projects that are coming into the pipeline, or basically into the backlog, will move from one lane into the other. This helps the scrum master in looking at how the projects are moving. We also have trial boards, where the stories, the features, and the tasks are managed. For example, if there are a couple of projects that are impacting a particular feature, then we can link those two projects to this feature so that we know which updates are impacting which projects or initiatives. This way, whoever is managing the projects will know the progress of work as well as the impact on those individual projects. So, it removes the risk of doing something that will impact some other project. These boards help us this way, and it is one of the many examples.
It provides a visual ability to look at the deadlines. When we use a card, we always have a scheduled finish date. As the date is approaching, the color of the date icon changes, so it has a visual way to say that we are nearing the finish date, which makes us take a look at it and check whether we can meet the deadline or not. So, as we are near a deadline, the date icon's color changes to yellow, and once we pass that date, it changes to red. When it is in yellow state, we do a deeper review of the card and see whether we are still okay or not, and most of the time, we are okay with those dates. If not, it helps us to replan and see where we go from there. This is absolutely helpful in project delivery.
The main thing is that we know what's in the current sprint and what we have planned to deliver. We know what those dates are. All the deliverables are in front of our eyes in the form of cards, like a schedule. There are lines, dates, etc. We know who is working on what. We typically have a daily standup meeting in the morning in which we review the cards in the Develop lane. We have multiple processes, and in general, if somebody is working on a feature, we already know what is happening. We do a one-minute review of each card and look at it and say, "Hey. Are we still on target? Is there any issue that is stopping us from working on that feature or functionality?" That's basically what it is. So, we know whether we will make it or not. It basically gives us the flexibility to look at any risk to delivery beforehand, and that way, make adjustments so that we won't miss a delivery.
We use the Card Health feature, and we also use other reporting features on the card. Generally, we do a review on a daily basis where we are with things. We are a small team, and we know what's happening with each card and whether we are going to make it or not. So, we already know what's happening on each card, and typically, only when we are doing our sprint introspection, we go and take a look at the predictability aspects. We sometimes look at the predictability that a particular report is giving during the standup meetings, but usually, we review the Card Health information retrospectively to see whether we can make any improvements in the future so that it is much smoother.
The Card Health feature activity stream affects our project management and delivery, but we have always looked at this after the fact. We usually don't use that on a daily basis. However, we do look at every card every day so we know where it's going. We will get to know if there is any risk in delivering a certain feature. It takes our attention to those cards to say that there is something going on with it, and we need to look at it. It needs a different analysis.
The board analytics helps with the speed and looking at how we are doing. It helps us to see if we can accommodate additional features within the sprint. In case, we have everything on target, we can pull additional cards to work on them, and board analytics helps with this. It also tells us how we are doing and how we are estimating.
LeanKit has reduced our cycle times because as we finish the planned work, we now know if there is more room to do additional work. So, we have the ability to know how we are doing. In this sense, it has easily reduced 50% of cycle time.
Every feature is valuable. LeanKit is a Kanban-based tool where you have a visual interface that you can use to create various cards and to create boards to house those cards. You can create a board for managing project work. You can create a board to do PI planning. It is pretty close to the agile way of doing business.
The Board Layout Editor is excellent in terms of flexibility. They have been improving its usability. Their development is very much agile, so for any feedback that we give them, they let us know if and when they would act on our request for enhancements or change, and then they make those changes. They are responsive.
Within the current features, if they can give some ability to show more icons on the card, it would be helpful. It would help us in showing more data on the cards.
I have been using this solution for close to three years.
In the last three years, I have only seen it once that LeanKit was not available. They had a technical glitch for about 10 to 15 minutes. That was the only time, and it was only for a brief duration. Otherwise, it has been pretty stable. I've not seen any issues with performance either.
It is very much scalable. We started with one board, and over time, we have transformed our work into multiple boards. We have links within each board. So, it is very flexible.
Currently, mostly the project management team uses it. We have about 20 users who are using LeanKit. We have analysts who do the development work, and we also have project managers and program managers who use it. We do plan to increase its usage in the coming years.
I have not used their technical support for an issue. I have only used them when we needed to renew our secure certificate.
We've been using LeanKit for almost three years. In the beginning, we weren't much aware of it, but now, we are very much aware of it. The reason for not using their help is because we know how the application works. New people in our organization have to go through the videos that Planview has provided for LeanKit. We also give peer-to-peer training. So, in general, we all know this application because we've been using it for a while now.
LeanKit conducts a webinar every month. We attend those webinars so we know what the new features are. That webinar also shows how we all can use it. In a way, we are getting trained by attending those webinars.
Before LeanKit, we were using Planview's Enterprise One application, but that application was more for the traditional way of project management, but of late, I feel it is gearing more towards agile. So, we've used that, but mostly, it used to be spreadsheets. We replaced spreadsheets with LeanKit, and the plan is that we're going to integrate Planview LeanKit and Jira. That's the future vision.
It was very straightforward. LeanKit is a SaaS application, so implementation is mostly configuration. There is no on-prem option for LeanKit.
You buy the licenses, and Planview implements the space for you. They provide template boards that you can use to have a quick start, and then, you can modify them to fit your process, which makes it very simple. They have templates for various methodologies. They have a template for sales; they have a template for DevOps. There are quite a lot of templates. We picked their templates for PI planning, and it was very quick.
One of the main processes for its implementation is that you need to get all the security clearances and establish a single sign-on. Once the paperwork was complete, it took a week. We did have a strategy, and we went through that. So, basically, most of it was securing IT security clearances. Because this is a SaaS application, we needed to ensure that we comply with all the security requirements before we use the application. We had to ensure that we have non-disclosure agreements and business associate agreements with any company we do business with, so we had to get an agreement in place. After that, we bought the licenses that we wanted.
Once that was done, we had meetings with the Planview LeanKit team to set up a single sign-on. We didn't want to use a specific user ID password, so we discussed implementing that and the requirements associated with it. They worked with our IT infrastructure team to get the setup for single sign-on, and they had to do certain integrations with our other internal systems so that we had the ability to add users and manage users. We worked with Planview to get the single sign-on in place and set up all the certificates for a secure connection, and we got access.
We had already done prep work on how we planned to implement the boards and how we planned to do our work, so we started with it. Then over time, we have reformed our boards and the methodologies on implementing as we learn more and more to make our work efficient.
It doesn't require any maintenance. They update the version regularly. Sometimes, we can request to be added to some of the features that they have implemented so that we can do testing or something like that.
As far as I understand, it is not an expensive application.
We already had Jira in our organization, so we looked at Jira. We decided to go with LeanKit because we were looking for a simple Kanban-based application. Because we had already used Planview's Enterprise One application, we thought we could try LeanKit and see how it works, and we have been with it for three years.
I would highly recommend this solution to others. I would definitely ask others to take a look at the application and evaluate it. We have really benefited from it from the delivery perspective as well as from the perspective of planning the work. It is very simple and intuitive. It doesn't need too much training. Any new person who comes in can pick up the features and start using it very easily.
The LeanKit team has been adding new features, which is another good aspect. They have very recently introduced KPIs, which is where the industry is going. We hear a lot about it. Even our organization is talking about KPIs. LeanKit is very responsive to any feature requests that we provide.
We have Jira in our organization but not in our team. We have only been using LeanKit. We don't use its integration with Jira at all, but we do have plans for that.
I would want to rate it a 10 out of 10, but I won't because there is always room for improvement. So, overall, when compared to all Kanban-based tools, I would rate LeanKit a nine out of 10.
We're doing a full continuous integration (CI), continuous delivery (CD), continuous testing (CT), security, delivery, and monitoring.
We're currently using TFS 2013, TFS 2017, Azure DevOps Server 2019 update one, and Azure DevOps services, which is the SaaS cloud platform. I manage all of these.
It is deployed on Azure DevOps Server and Azure Services' private cloud.
They have been lately adding features to the services on a regular basis. Every two weeks, they are adding functionality to Azure DevOps Services to match it with what Azure DevOps Server or on-prem would offer. So, we continue to get more robust functionality.
My favorite right now is that they are starting to open up the API availability within Azure DevOps Services.
Another thing that I like about Azure DevOps is that you can use it with any of the products that are on the market. You can integrate it with Jenkins and other open-source products to complete that fully functional CI, CD, CT, CM, and CS pipeline. It continues to enhance.
We are currently in the process of moving all of our on-prem to the cloud platform. We are trying to make that move and host the majority of our DevOps services in the cloud because the cloud is where most of the things are going nowadays. However, the process of this transfer is not straightforward, and it could be a lot easier. Microsoft hasn't provided the maturity for migration tools. It could be a lot easier in that respect.
I want to see them continue to advance the API capabilities. They could add some more robust functionality to the administrative layer within ADO services. There are a lot of configuration elements that you need to take care of at the organization level and the project configuration level from an administrative capacity. When you're dealing with process templates and things of that nature, you have to do them all manually. Being able to automate some of that using scripts or API functionality would be really nice.
I have been using this solution for about nine years.
It has actually been pretty stable. Some of the early gen ones were not so stable. Before Microsoft started communicating with the end-users, they would make changes in the middle of the workday, which was a bit frustrating because things would change, which would impact the end customers because they weren't expecting that change. Microsoft wouldn't communicate with tenant administrators and tenant owners, but now, Microsoft has gotten a lot better about articulating their roadmap and communicating when those kinds of changes are coming down the pipeline. We are now able to communicate that out to our tenants and the end-users working within our projects. There is a lot better communication in that respect, which makes it easier for us to make customers aware of what might be coming, what is going to cause changes for them, what are the timeframes in which those things are going to hit their views, and what to expect from those things and additional functionalities.
For the cloud, it has been really good. For on-prem too, it is easy enough to scale out. TFS also has always been pretty easy to scale out.
In terms of the number of users, currently, we're in a transition because we were just acquired by another company. So, we're leaving our parent company, and we're going to a new company. The numbers that I have are in flux. Our current numbers are at about 600 for just our existing or old company. I've been asked to stop onboarding my users and projects until we move our current organization into our new operational tenant in the new company, but I'm projecting that we'll have between 2,000 to 4,000 people.
I use it all the time. They're very good when you get to the right queue. So, when it is working, it is great. I would rate them a nine and a half out of ten because I always think people have room for improvement, but they've been very good and supportive.
It works great for us especially now because we've kind of been divested from our old company to our new company. When we were with our old company, it was a little bit mired because of the way our enterprise architecture was. My requests didn't go to a North American team. It went to an EU team, and then I had to work within EU hours to get support, whereas I am in North America. That was a little tricky. Our old parent company was parented in the UK, Ireland, and Scotland.
I've used other solutions in tandem, and I have been an administrator for them. For example, I've used Jira and Confluence products, which is Atlassian. I've also used Remedy, but I'm not sure if they're still in the project management. I have also managed HP Performance Center and Tricentis. I've actually been administrating these for the last two years for this company.
I also use UCD, which is another very similar product. It does a lot of the same things and is also agnostic, just like Azure DevOps. You can use both of these with any of the products that are on the market.
It is pretty straightforward on the administrative side, but I've been working with this technology for a long time. It really falls in line with the majority of Microsoft products. If you're familiar with the Microsoft stack, it follows their pretty standard setup. You go through a similar process. It is just about knowing the nuances that Microsoft has when you're doing a farm configuration or a farm setup and the recommended prerequisites before you get started.
If we're talking about new end-users who are going from an older version of TFS to Azure DevOps Server or Azure DevOps Services, there is going to be a bit of a delta because the technology is different. There is a slight learning curve. Of course, it has got fancier bells and whistles and a jazzier user interface. It has softer edges and things have moved from left to right. Things that you found on the left side have again moved back over to the right side for administrative or usability functions. Your security elements and the things that you used to see on the left side have again switched back to the right side. These are the kinds of nuances about which you would need to educate your end-users. You need to get them used to the boards and how to use those. If your company is transitioning from a CMI model to an Agile model, it is going to be very important for the folks who are administrating your projects and your project managers to know how to configure the projects themselves, how to use Teams, and how to use permissions. Security becomes even more important because a lot of that really influences how you see the information within your project, and how you manage your boards, your sprints, and the work items that you allocate to your scrums or sprint users.
As you're going through different stages of your project, you have your pipelines and repos where your more development-centric users are going to be. I try to allocate out two different kinds of users that we're going to have and target them when I'm educating my folks. You have a kind of power user, and you have your regular contributor user. It is important to make this distinction because there are folks who are going to be doing basic or just regular contributor work. They will just contribute to the work items that are on a board or within a sprint. You're also going to have users who need to be slightly elevated, which is going to be that basic plus test plan. You need to understand how those affect your subscription and billing towards that subscription and how to manage that when they're not actively using it. You need to monitor this and enroll them back to a stakeholder so that you're not constantly incurring costs against your pay-as-you-go subscription costs. Everything is pay-as-you-go once you get into the cloud.
I would ask those who are looking into implementing Microsoft Azure DevOps if they are already on the Microsoft stack of products. If they are, I would highly recommend them to use Azure DevOps Services or Azure DevOps, because they're already paying for that as part of their E-agreement. So, they should take full advantage of that because it is part of their licensing agreements. They should exploit what they're paying for because they are already paying a lot of money for Microsoft products.
Both UCD and ADO are the best products in the current DevOps space right now. They're both agnostic, and you can plug and play and integrate them with the majority of the tools in the market. You can integrate them with Jenkins and other open-source products, and open-source is where everything is going when you move to the cloud. Having that flexibility and viability within your company and business, no matter whether you're a small or large company, is a huge benefit. That will allow you to be flexible and deliver to on-prem or container.
Microsoft is extremely flexible, and they are listening to feedback and hearing what customers are saying. I've worked with Microsoft for almost 20 years now, but I took kind of a two-year sabbatical. Most of that time, I was developing out their SharePoint Online O365 platform. I stepped away for two years and then I transitioned over to DevOps because they really weren't taking feedback that was being provided by customers, and they were ignoring the customer experience, but their new CEO has kind of refocused Microsoft's outlook on the customer experience and is putting the priority back where it needs to be. They're doing a much better job in terms of incorporating feedback. They're continuing to advance and advent their product, and they are keeping ahead of and staying in touch with what technology is doing from a CI/CD pipeline perspective. This is why I am looking forward to continuing to use them.
I would rate Microsoft Azure DevOps a nine out of ten.
We are using it for test management. We have distributed teams in three locations with one location in Portland, which is the newest, and also in India. We have a team of around 150 people (developers plus three testers). We are implementing an order migration legacy system to a new system based on AngularJS 5.0. We also have test automation being implemented on this account using Micro Focus UFT.
Automation is triggered through ALM. We have the test scripts stored in ALM that are triggered through the execution dashboard. Also, the reports are available on the dashboard.
We do defect management through ALM, which is the typical use case. The defects are raised in our different locations, then the collaboration between the development leads and testers happen through ALM.
We use the Test Plan module where we have test cases related to all our different releases up until now with a few current releases as well. We use the Test Lab tab to pull test cases from Test Plan and do executions accordingly. We have also created some smoke and sanity testing suites where we pull test cases, then execute them when required during the project phases.
Any user who accesses a project gets to know what is the latest status on a test case, from a test case writing or test design perspective as well as test execution perspective. Collaboration is very strong. The communication that the tool sends out along with the log which is maintained is locked in the history. This is for any change at the test case level or within any of the components of ALM. The history helps us to understand what went wrong or when has somebody made a change. Therefore, the history log is a very important feature.
From a collaboration perspective, I can send out emails directly from ALM that, at times, get triggered automatically. If you raise a defect, then it automatically triggers to a particular email ID that the defect has been logged in ALM. This helps to get immediate visibility or attention of the development team from a testing team's perspective.
Initially, we used to lose a lot of time in collaboration. If we do this in a very crude way through Microsoft Excel, then there would be a lot of issues related to version control. Like somebody might say, "I've fixed the defect," and the other guy would say, "It is still open." Now, across the team, we have one single source of truth because ALM helps the whole team to understand the exact status.
Ease of use is definitely one of the strongest points for ALM. It's a very user-friendly tool and the maturity of processes within ALM are amazing compared to other tools. Their in-built reporting does help with getting ready-made reports from the tool.
The Test Plan and Test Lab setup helps us a lot when pulling test cases repeatedly from a different perspective. If I want to make a sanity pack, then I can pull test cases from that same library of test cases. I don't have to create them again or copy and paste them.
I love linking/associating the requirements to a test case. That's where I get to know my requirement coverage, which helps a lot at a practical level. So, we use the traceability and visibility features a lot. This helps us to understand if there are any requirements not linked to any test case, thus not getting tested at all. That missing link is always very visible, which helps us to create our requirement traceability matrix and maintain it in a dynamic way. Even with changing requirements, we can keep on changing or updating the tool.
We use the dashboard and have created our own reports. The typical dashboard also helps us a lot to understand test execution progress and the percentage of open defects from a defect perspective. We use the defect aging reports a lot. This saves us lot of time and gives us the right input from the perspective of which defects are aging. Those need to be looked at again and possibly discussed in further detail in the defect triage call about what's the blocker to get them fixed and how we can work in a better way to avoid the defect aging in these manners.
The vendor is still investing in the product and releasing valuable features. For example, there has been improvements in the overall folder structure. Initially, we just used to have Test Plans and Test Lab. Now, we have the Task Board.
Sometimes I do run my queries from the admin login. However, if I want to reassess all my test cases, then I am still doing this in a manual manner. I write SQL queries, then fire them off. Therefore, a library of those SQL queries would help. If we could have a typical SQL query to change the parameters within test cases, then this is one aspect I can still think that could be included in ALM. Though they would need to be analyzed and used in a very knowledgeable way.
About four years.
It's very stable. We haven't had issues with any sort of stability issues, e.g., no downtime.
We have around 4,000 test cases in ALM, so I don't think scalability is an issue.
We have around 150 users. The hierarchy of ALM users is:
70% of our people use ALM and the other 30% don't need to be on ALM.
The technical support is nice. At times, we have needed to wait. However, this is understandable for a few of the issues as they sometimes can be tricky. I would rate the support function as above average.
The turnaround time varies with the issue, but they're decent enough. The average time is two days. They provide us local support.
I have always used different versions of ALM. I did not previously use a different solution before using ALM.
The initial setup was pretty straightforward. The process was just about our customization, which we do from our end and is admin guided. This took us around a couple of weeks and wasn't cumbersome at all. ALM is a mature product. We could set up how we wanted to upload our test cases, then structure the different parameters or columns the way we wanted them. The process was quite streamlined.
We did have some internal help, but we didn't have a full-time consultant. We didn't have any external help. We used a team of three people (part-time consultants).
We definitely feel that it has given us a huge advantage from a collaboration and time savings perspective.
It can reduce the wastage that happens in collaboration activities. The effort has definitely gone down. Effort and collaboration have been reduced by 60 percent.
It all comes down to how many people are going to access the tool. When teams go above 20, I think ALM is a better tool to use from a collaboration and streamlining perspective.
At a process level, the maturity within ALM is at the highest level. Now, if I have run the same test case five times within Test Plan, it will gives me a status of that test case based on the last run, whether it passed, failed, or its situation. If I want to know right now from a functionality perspective what functionalities are working for me and which are not, then based on the immediate last run done directly through Test Plan, I can understand that. That's one of its strengths. This is not available in other tools, like TestLink and Jira (we are using both).
Jira has an advantage from agile perspective. For an agile project, it helps to have the dashboard in the way Jira is structured.That's where Jira is pretty useful. We also have three of the defect calls running different ways using Jira. There are a few things from a visual perspective where Jira poses some advantages over in ALM.
TestLink is pretty similar to ALM. It is not really drastically different. It's open source and doesn't have the kind of maturity which ALM has, like the BI page, the history log, or other functions that are present in ALM. It doesn't have that type of strength. However, since it's open source, at times a couple of our clients use it, but I use it very rarely within our projects.
Security is driven by the different user login credentials that are created by the admin. This is pretty typical. In this aspect, all their tools are good.
For risk-based testing, I used to have a different version of ALM that gave me a confidence level. Currently, I don't think our company has bought the version where you implement risk-based testing. However, it does help me to get the required inputs from the tool. Then, I have my own way of going about risk based testing.
I have seen the Single Sign-On. It's nice, but we don't use it in our current project due to a few constraints and a few user experience related issues. Sometimes, people don't want to change and just want to do it the old way. That is why we stopped using it.
I would rate the solution as a nine (out of 10) to keep pushing them to include more features.
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 Micro Focus 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 Micro Focus 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.
We manage the whole software lifecycle. We combine the user stories and requirements, including the test cases, in order to describe the test execution and the defects. We manage the rest of the cycle inside SpiraTeam instead of Jira. In some cases, we started using Jira connected with SpiraTeam. We can manage the whole life cycle of the software in only one tool.
The integration is really better than it was in the past.
The initial setup was pretty simple.
Their documentation is excellent.
The solution is fast and very accessible.
Organization time is free of charge in terms of licensing. This is until you finalize the migration from one tool to the other. That way, we don't need to pay to license two solutions at the same time.
The maintenance team doing the support gives you a lot of knowledge. They often have up to ten years of support experience. Those leading the support teams are very knowledgeable. There seems to be very little turnover or team change, which helps retain the knowledge
The importing aspect is one of the areas that probably could be improved. We talked with Inflectra several times about that point.
It would be great if they worked more closely with other solutions. There needs to be better integration with the platform for development purposes.
The improvement that's really important is in the reporting. We need to be able to customize it more and to export the reports themselves. You can export the data, however, not the reports.
We've been using the solution for a while, and definitely in the last 12 months.
In order to move from Jira to SpiraTeam, we need the support of Jira due to the fact that in some cases, with high volumes of information, we've had some problems with Jira that we didn't have with SpiraTeam. The stability of SpiraTeam, in general, is very good. We don't have any problems with that. Even documentation about the maintenance windows and improving capacity is very good.
The support provides a baseline for the stability of the server. All of the support below the server is very good. It's quite stable.
There's basically a roadmap, where users can increase the capability year over year. In general, they obtain feedback from the customers and they put the improvements in the roadmap, and then the clients can have clarity on what is needed inside the tool. That is very good. In some cases, not all the providers give you a roadmap about which functionalities will change in the next versions of the tools. In this case, they increase version to version their capability and base it on the feedback from the customer. It's quite good and quite scalable.
Different clients have different amounts of users. Some are near 3,000 while others are under 3,000. When it comes to training on the solution, we have anywhere from 100 to 1,000 pupils at any given time on the solution.
In terms of increasing usage in the future, it's hard to ascertain. At the moment, Argentina is in a very difficult situation, due to the exchange rate of the currency.
The support in Latin America of Inflectra is the best if you compare it with Jira support. Jira is an Australian company and they have several distributors, however, don't give support and they don't have any offices in Latin America.
In the case of Inflectra, they're already aligned with the time zone. We have only five hours time difference with Chile, however, with Australia, we have 12 hours, 11 hours or time difference.
Overall, they are very professional, and in general they fix the problems very quickly.
I was in charge of a percentage of HP tools for five years. Before that, I worked with tools from IBM, and that has more or less the same. I find this tool is fast and is very accessible.
The initial setup is really very easy. The documentation is key. The documentation provided by the solution is some of the best documentation that I've seen in the last years. It really is very good and they maintain their quality year over year and even improve the quality of their documentation. The tutorials have videos and there are step-by-step instructions for different situations. They cover basically cover all of the situations that you can see when you are installing. It's really easy to install the products that come from Inflectra.
The pricing is difficult as the exchange rate is not great. The local currency in relation to the US dollar is not great. It makes it hard for the customer to afford the solution, not necessarily because of the cost, but because of the fluctuating exchange.
We are using the general enterprise license, which is unlimited. We also have access to the solution for training purposes, and that is free.
We are an integrator. We use the tools of Inflectra to integrate into other big solutions.
For training for the government, we created something to provide certification in testing, and in terms of Inflectra, we have asked for sponsorship of that training. They give us SpiraTeam on the cloud with free access for the pupils and the robot Rapise too. That way, we can give people training for one year. We test engineers in theory, expertise, and techniques or methodologies used in SpiraTeam and Rapise.
Then at this moment, we have nearly 1,000 pupils a year and those pupils, after they obtain the certificate with the Ministry of Education of Argentina (and signed by Inflectra). It's an initiative between the government of the city of Buenos Aires and the Inflectra Corporation. Inflectra gives us the facility to use all the tools.
After the pupils obtain the certificate, in general, they obtain their first job in IBM, Accenture, or in any organization using Inflectra.
Many companies in telecommunication are looking to change their management tool and to move all their solutions to Inflectra solution using the SpiraTeam and Rapise for testing automation.
We're using the latest version of the solution, as it's on the cloud and consistently updates itself.
Overall, I would rate the solution ten out of ten.
