Microsoft Azure DevOps Review

Integrates well with other tools, and enables us to perform different functions within one tool

What is our primary use case?

It is used to manage our projects. We basically maintain what would be the equivalent of our project schedules for various projects. So, we capture or create user stories to identify elements that need to be accomplished for the delivery of a project and to track who is responsible for it and the level of effort. We aggregate that within the tool and report out to leadership about the status of when we anticipate completion.

We are using its latest version.

How has it helped my organization?

Its integration with different functions has been very helpful. Previously, we had Microsoft Project schedules, and we did our reporting by using Excel and PowerPoint presentations. We also did testing tracking in other tools, such as HP ALM. Our source code was on Teams Foundation Server. All that can now be done within DevOps, which is a huge benefit. Things that we used to do in different tools can now be done in one tool. 

What is most valuable?

I like the fact that there is built-in Power BI. Both are Microsoft tools. So, you can incorporate dashboard capabilities. 

I also like the integration with the other toolsets, such as Outlook and GitHub. You can do your testing and check your source code within the same tool. That's definitely something really good.

What needs improvement?

The tool was developed for Agile project methodology, but I've noticed that there has also been a try to incorporate what is typically done in MS Project, which is for more sequential Waterfall projects. The problem with that is that it is half-baked for Waterfall projects. If you're going to do it, then either go all the way and allow us to use the tool for both or don't do it at all.

One thing we had to customize ourselves was to create the critical path. You can't do your project dependencies within the tool. We tried using the tool for a Waterfall project, and we had to find a custom approach to do that because. There should be some functionality for the reporting and dependency tracking for the Waterfall projects.

For how long have I used the solution?

I have been working with this solution for two to three years.

What do I think about the stability of the solution?

So far, so good. It has definitely been sized appropriately for our use. We haven't had any issues with it.

What do I think about the scalability of the solution?

We've only been using it for about three years, and so far, it seems to be able to adapt to our growth. We're maturing into it. We're moving in the direction of using it more, and I feel confident that it'll scale appropriately.

We have at least a hundred people using the tool. There are different degrees of people who are using it. Some people are using it in the read mode or view mode to keep themselves informed of where things are. We have some project managers who actually use the tool, and then we have a couple of administrators. I'm one of the administrators for our program. I have a couple of vendor or partner folks who are also administrators. We also have a development team that does some customizations on the dashboard and the Power BI reports that we do. These are pretty much different roles or layers that we have.

We do grant developers access to be able to make their own updates within the tool. Typically, project managers or scrum masters do that, but we also have some team members who are on these projects and have enough understanding of how the tool works and how we're using it. They are able to do their own reporting and their own updates on their statuses.

In terms of plans to increase its usage, we're moving in that direction. Most of our projects are done in Microsoft waterfall project management schedules, but we are being encouraged to move over to more of an Agile approach on our project methodology. Our mandate is that if you're going to do anything Agile, use the DevOps tool.

How are customer service and technical support?

I have not interacted with them. We have a sort of layer for support. I have had to reach out to one of the three resources that we have. He is our true admin at the company who had to reach out to their support, but it has been seldom, at least from my experience.

Which solution did I use previously and why did I switch?

I used Jira while working with a vendor that we had here for one of our projects. They brought that tool from their practice. We were doing that because we had not yet moved to DevOps. After they rolled it out at the organization level, the mandate was to stop using Jira and switch over to Azure DevOps. There are a lot of benefits to Azure DevOps over Jira, but Jira is the one that has a lot of market share on that side.

How was the initial setup?

I wasn't involved in that, but I do know that, just like many tools, there is a learning curve that was associated with that. I have used Jira before, so I had more or less an understanding because it is very similar to Jira, but I know that for other people I work with, it was a completely new concept to use something like this.

For its maintenance, we have a small team. We have about three individuals who do the backend support. So, it is minimal. Obviously, if they have any escalations, then they do go to Microsoft, but we haven't had that happen. It was very minimal. There are plugins that are available to enhance kind of some capabilities of the tool. When we ask for that type of functionality, these three individuals have been able to implement plugins for us.

What other advice do I have?

It is an Agile tool. We were using the tool calling that we were Agile, but we were really doing things in the Waterfall methodology. It was our square peg in the round hole, and that's where I realized that we didn't have the capabilities in DevOps to use it as a Waterfall tool, which makes sense because Agile is a different approach. We've evolved since then, and now, we're doing a bit more Agile when we use the tool. So, a tool is just a tool. There has to be that thinking alignment. Otherwise, it is a square peg in a round hole, and it doesn't quite fit. Your organization and your team have to understand that. Just using the tool doesn't make you agile.

The only problem we had was when we rolled this out, we didn't realize how Waterfall we really were. So, I had to go back and have PMs create additional data elements for us to capture what we really wanted to capture to report in Waterfall. Dependencies weren't tracked, and we had to go back. It almost felt like we had to do rework, and people weren't too happy about that.

I haven't used its mobile device capabilities, but that's definitely something that I would hope to evaluate in the future. 

I would rate Microsoft Azure DevOps an eight out of 10. Overall, I'm pleased with the tool, but there is definitely some room for improvement.

Which deployment model are you using for this solution?

Private Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Microsoft Azure
**Disclosure: I am a real user, and this review is based on my own experience and opinions.
More Microsoft Azure DevOps reviews from users
...who work at a Computer Software Company
...who compared it with JIRA Portfolio
Learn what your peers think about Microsoft Azure DevOps. Get advice and tips from experienced pros sharing their opinions. Updated: September 2021.
535,544 professionals have used our research since 2012.
Add a Comment
ITCS user