In this chapter, we examine a tool that makes it clear why DevOps is an important process for organizations engaged in IT development. A good implementation of ALM helps an organization deliver better business value to fulfill its business needs. Automating tasks by using tools such as Visual Studio 2017, Azure DevOps, and TFS 2018 (soon to be renamed Azure DevOps Server) supports this process.
We will take a look at how Azure DevOps can be used to fulfill the three main pillars of ALM and the issues addressed by ALM, which were covered in Chapter 1. We start with an overview of ALM and of Azure DevOps, then move on to the specifics of using Azure DevOps for ALM.
ALM Overview
- 1.
Traceability of relationships between artifacts: The lack of traceability can be a major cost driver in any enterprise. There must be a way to trace requirements all the way to delivered code and back again—through architect models, design models, build scripts, unit tests, test cases, and so on. Practices such as TDD and configuration management can help, and they can be automated and supported by Azure DevOps.
- 2.
Automation of high-level processes: There are approval processes to control handoffs between analysis and design. There are other handoffs among build, deployment, testing, and so on. Much of this is done manually in many projects, and ALM stresses the importance of automating these tasks for a more effective and less time-consuming process.
- 3.
Visibility into the progress of development efforts: Many managers and stakeholders have limited visibility into the progress of development projects. Their visibility often comes from steering group meetings during which the PM goes over the current situation. Other interest groups such as project members may also have limited visibility of the whole project even though they are part of it. This often occurs because reporting is hard to do and can involve a lot of manual work. Daily status reports may, quite simply, take too much time and effort to produce—for example, especially when we have information in many repositories.
Improving collaboration: Collaboration is needed among teams, team members, stakeholders, and users, just to mention a few relationships. When development is spread around the world in different locations, collaboration can be hard to manage without the help of a proper tool.
Closing the gap between IT and business: The big gap between IT and the business side of an organization is a serious problem for organizations, preventing us from delivering the greatest business value that can be achieved from our projects.
Using one tool: The complexity of using several tools for solving project issues as a team member can be tough, and costly as well. Switching between tools can be a cost driver. Using one tool that enables us to add plug-ins and use more features directly in our ordinary GUI, instead of switching between applications, is preferable. So, if you have several roles in a project, you can still use one tool to get the job done.
Enhancing role switching: ALM also addresses the potential to use one tool when switching among different roles in a project. In many cases, project members play several roles in the same project. A developer, for instance, might also work with tests or databases. If that person can use the same GUI for all tasks, there will be minimal overhead for switching among these roles.
Azure DevOps Overview
Comparison between VSTS Features and Azure DevOps Services
VSTS feature name | Azure DevOps service name | Description |
|---|---|---|
Build & Release | Azure Pipelines | CI/CD that works with any language, platform, and cloud |
Code | Azure Repos | Cloud-hosted private Git and Team Foundation Version Control (TFVC) repos for your project. |
Work | Azure Boards | Work tracking with Kanban boards, backlogs, team dashboards, and custom reporting |
Test | Azure Test Plans | All-in-one planned and exploratory testing solution |
Packages (extension) | Azure Artifacts | Maven, npm, and NuGet package feeds from public and private sources |
Azure DevOps is an open and extensible product that lets us adjust its features to our needs and add the things it might lack at this point to support our specific needs. It is also important to know that Microsoft is spending a lot of time, energy, and money on developing this product further. This is not a tool set that will go away quickly (although one never knows); it is one of the most important tool sets in the Microsoft ecosystem.
Azure DevOps is now available in two versions: TFS and the cloud-based Azure DevOps. In this book, we mostly use Azure DevOps for illustrations.
Team Foundation Server
An overview of TFS and Azure DevOps
TFS and Azure DevOps expose different functions and services for developers, PMs, and others such as version control, reporting, build, and work item tracking. Not shown in Figure 2-1. is the fact that TFS uses Microsoft SQL Server as its data repository.
Note
Work items (Figure 2-2) are used to manage different types of information in TFS and Azure DevOps. There are work items for requirements, bugs, general tasks, and so on. To put it simply, a work item is a piece of work that must be completed for a project. The work item tracking system is one of the core parts of Azure DevOps for DevOps process implementation.
The heart of Azure DevOps: a work item—in this case, a product backlog work item
Process Template
The process template customizes Azure DevOps behavior
Most companies use some kind of process for their development or ALM. Although some companies don’t think they have a process, they do. The process might not be written down, but the company still has ways of doing things that, in reality, is the process—for instance, naming conventions, where to store builds, how to handle CRs, and so on.
In many cases, we have seen companies with lots of money invested in their processes. They have sent staff to training, provided large process manuals, and so on. However, they have had problems getting project members to use the processes in their daily work. The excuses are many: The process is hard to understand, remembering all the process steps is difficult, the process is not automated or included in the tools, and many others.
The end result has been that PMs use their own variant of the process, causing confusion during the project’s lifetime. This also causes severe problems, because handoffs between the development team and the operations team are often difficult. A typical bad scenario can occur when a system has to wait for deployment because the infrastructure isn’t in place for the new system. Operations was not involved (or perhaps not even informed) during the project and suddenly they are expected to run the system on hardware they don’t have.
With Azure DevOps, you can implement your development process as a template that is mandatory for all new projects. When you create a new project, you also create a new instance of the process template. You don’t have to stop at the development project level either. You can implement most parts of your DevOps cycle in the template as well, enabling you to take advantage of Azure DevOps all along the way. The template helps you visualize and automate tasks and steps that the process includes. It helps you by providing document templates for requirements specs, test cases, scenarios, handoffs, and other artifacts you produce.
The template also provides information about which reports you have available for each new project—reports that you can use to retrieve information about the status of your projects and many other things. The template also contains information about one of the most important core parts of Azure DevOps: the work items. These items can be adjusted as needed so you can make sure they contain the information the organization must have. This information could be status information for a bug, for instance, such as Active, Resolved, or Closed.
This template is so flexible you can develop and implement your own process, you can choose to use any of the three that Microsoft supplies, you can use a third-party template, or you can choose to customize the Microsoft templates to your own liking. You also have several process templates in Azure DevOps, so you can use different templates for different projects. Because Azure DevOps really is not used to its full potential without the process templates, it cannot be stressed enough that you should consider which templates you want to use and the information you want them to include.
Visual Studio 2017 Editions
Visual Studio Community: Full-featured IDE for building Web, Windows Desktop, and cross-platform iOS, Android, and Windows apps. This edition is free for open-source projects, academic research, training, education, and small professional teams.
Visual Studio Professional: Professional developer tools and services for individual developers or small teams. This edition includes powerful features to improve a team’s productivity, such as CodeLens. Improve team collaboration with Agile project planning tools, team rooms, charts, and more
Visual Studio Enterprise: Enterprise-grade solution with advanced capabilities for teams working on projects of any size or complexity, including advanced testing and DevOps. Build quality applications at scale with advanced features such as load testing, automated and manual testing, and new IntelliTest capabilities. Manage complexity and resolve issues quickly with features such as Code Map and IntelliTrace.
Visual Studio for Mac: Developer productivity of the Windows version to a Mac. The experience has been developed to optimize the workflow for the Mac developer.
Visual Studio Test Professional: a tool for testers. Tools are also included in the Ultimate edition, but it lacks the development tools included in the other editions.
Team Explorer Everywhere (TEE): access to Azure DevOps for developers on other platforms, such as Eclipse on the Mac. This is the perfect add-on for teams with development on multiple platforms such as .NET and Java.
Azure DevOps
The project start page on Azure DevOps
Many of our customers use a team project portal primarily to provide access to reports and work items for nontechnical people not used to the Visual Studio interface. When we want to give an external user (such as a customer or remote stakeholder) access to work item creation and editing, or another more advanced task, we usually use the web interface.
Microsoft Office
Microsoft Office can be used by PMs, product owners, or Scrum masters, for example, who want to use tools familiar to them, such as Microsoft Project and Microsoft Office Excel, during a project. The integration is very nice and valuable to these roles.
IDE Integration
When it comes to add-ins, one thing we should mention in particular is Team Explorer. This tool can be used as an add-in to Visual Studio, and it gives access to Azure DevOps directly from within Visual Studio. From there, you can open reports, add new work items, and run queries against the Azure DevOps database.
Azure DevOps is a flexible tool, as we have mentioned. It is also very extensible, because all functionality can be accessed via web services. This is a very nice feature that enables you to build your own support for Azure DevOps in other applications as well. Many third-party vendors have done this, and a wide array of add-ins and tools are available. Our favorite came from Teamprise, a company that has built add-ins to Eclipse so that you can use Azure DevOps features in your Java development environment as well. Teamprise was purchased by Microsoft, and its suite of client applications has been available as TEE since Azure DevOps 2010. Briefly, it offers the same IDE integration into both Eclipse and Visual Studio, which allows you to work as one team, regardless of whether you use Eclipse or Visual Studio.
Traceability
Having traceability in your DevOps processes is key to the successful delivery and maintenance of your applications and systems. I once visited a company that stopped making changes to its systems just because no one ever knew where a change (or bug fix) might have its impact. You don’t have to deal with such a situation.
Work item tracking
TDD/unit testing
Azure Pipelines
Check-in policies
Version control system
Let’s look at some of the specifics involved with these features, starting with how the work item tracking system implements traceability.
The Azure DevOps Work Item Tracking System
Sometimes you might have tons of Post-its on your monitors and desk, which each note containing at least one task you are supposed to address. Most likely, you would want to track these tasks using a tool that can help you, but often this just isn’t possible. It could be that some tasks are connected with one project and others with another. You may have tried recording them in an Excel spreadsheet and saving it to the computer. But, you may soon realize that the spreadsheet is located on your laptop, your customer’s computer, your desktop, another customer computer, and so on. And, you have no idea which spreadsheet is the current version.
The same thing often occurs with projects. PMs have their to-do lists for a project, and they all have their own way of keeping them updated. Let’s say a PM uses Excel to keep track of the tasks—the status of tasks, to whom they are assigned, and so on. How can PMs keep the team updated with the latest to-do list? If PMs choose to e-mail it, chances are that some team members won’t save the new version to disk or will miss it in their endless stream of incoming e-mail. Soon there are various versions floating around, and things are generally a mess.
Work Items
Each work item has a unique ID—in this case, 1301
Work items provide a great way for you to simplify task management in a project while at the same time enable traceability. No more is there confusion regarding which version of the task list is current; no more is manual labor required to gather status reports on work progress used only at steering group meetings. Now you have a solution that lets you collaborate more easily with your teams, and enables all members and stakeholders to view status reports whenever they want. You can also collaborate more easily with people outside the project group by adding work items via the web client.
Azure DevOps is so flexible in this regard that it lets us tailor the work items as we want them to be. The work item tracking system is one of the core components of Azure DevOps. This system enables you to create work items, or units of work, and can be used to enable traceability. You can use the work items included with Azure DevOps from the beginning, you can choose to adjust them to your needs, or you can even create your own work item types. Each work item instance has a unique ID that you can attach to the things you do in Azure DevOps. This enables you to follow one work item—let’s say, a requirement, for example—from its creation to its implementation as a piece of executable software (component). You can also associate one work item with others and build a hierarchy of work items.
The work items can contain information in different fields that define the data to be stored in the work item. This means that each field has a name and a data type.
All work items can have different information attached to them. You can have information about to whom the work item is assigned and the status of the work at the moment (for example, a bug could be open, closed, under investigation, resolved, and so on). The State field can be modified so that each work item type has its own state mechanism. This is logical because a bug probably goes through states differently from those that a general task goes through. You can also attach documents to the work item and link one work item to other work items. You can even create a hierarchy of work items if you want. Let’s say you implement a requirement as a work item and that this requirement contains many smaller tasks. Then, you can have the requirement itself at the top and nest the other requirements below that so you know which work items belong to which requirement.
When a bug is discovered, for instance, you can quickly follow the original requirement by its work item ID, and see in which places in the code you might have to make some fixes. You can also visualize the associated work items so that you can evaluate whether other parts of the code need to be changed as a result of the bug fix.
Azure DevOps saves information about the work item on the data tier, which helps you follow the change history of the work item. You can see who created it, who resolved it, who closed it, and so on. The information in the databases can be used for display on reports, which allows you to tailor them depending on your needs. One report could show the status of all bugs, for instance. Stakeholders can see how many open bugs exist, how many are resolved, and much, much more. It is completely up to you how you choose to use the work items.
If you implement a requirement as a work item, you can use the work item ID to track this requirement through source code to the final build of the executable system. By requiring all developers to add one or more work item IDs to the check-in using a check-in policy, you can enable this traceability.
Configuration Management Using Azure DevOps
In any (development) organization, there needs to be version control of the systems in production. If you don’t have that, the overall DevOps process suffers, because you suddenly lose traceability. This makes it harder to implement changes and bug fixes, because you won’t know which versions you need to update.
Version control
Azure Pipelines
Configuration identification: Ensuring you know the code with which you are working
Configuration control: Controlling the release of a product and its changes (version control)
Build management: Managing the process and tools used for builds
Defect tracking: Making sure every defect has traceability back to the source
If these issues are not covered by your DevOps process, you could very soon find yourself in a troublesome situation. It is crucial for the development teams to have full control over those versions of the applications that exist, those that are in production, and where they are in production. This topic is closely related to portfolio management teams. In general, a big company has one or more persons devoted to keeping track of SCM.
Version Control and Release Management in Azure DevOps
Using the version control system in Azure DevOps, you can manage and control multiple revisions of the same information in your projects. This information can be source code, documents, work items, and other important information that you want to submit to version control. When you want to work on an item under source control, you check it out to your local computer so you can start working on it. When work is done and tested, you check in your changes so the version on the server is updated.
The version control features of Azure DevOps are powerful. Microsoft supports Git and the native Visual Studio version control. They are fully integrated into the GUI, which is something that ALM prescribes as well. If you want, you can access some of the features from a project portal as well. Many people want to use the command line for their work, and Azure DevOps enables them to use the command line for working with version control as well.
However, if you do want to use Visual Studio to access the Azure DevOps version control system, you can do that. The extensibility of Azure DevOps makes this possible. One example of this is the TEE suite of client applications that can access Azure DevOps, including the version control system. TEE lets you access Azure DevOps from Eclipse on Mac OS X and also through command lines. In this way, you can integrate different development platforms more easily in an Azure DevOps project. You will still use the Azure DevOps repository and have the ability to get reports and other information directly from Azure DevOps.
Build Management Using Azure Pipelines
A build is basically the process of taking the source code and all other items necessary in an application and building it into executable software. Azure Pipelines is a cloud service that you can use to build and test your code automatically and make it available to other users. It works with just about any language or project type. Pipelines combines both CI and CD to test a build your code constantly and consistently, and ship it to any target.
CI is all about automating tests and builds for your project. It helps to catch bugs or problems early during the development cycle, which makes them easier and faster to fix. Items known as artifacts are produced from CI systems and used by the CD release pipelines to drive automatic deployments.
CD is all about deploying and testing code automatically in multiple stages to help drive quality. CI systems produce the deployable artifacts, including infrastructure and apps, then automated release pipelines consume these artifacts to release new versions and fixes to the target of your choice.
It works with any language or platform.
It deploys. to different types of targets at the same time.
It is the best integration experience for deploying to Azure.
You can build on Windows, Linux, or Mac machines.
It provides great integration for GitHub.
It’s a great offer for open-source projects.
Automation of High-Level Processes
Without one or more templates, Azure DevOps is not used to its full potential, as mentioned earlier. You can still use its version control system and some other tools, but the real value comes from using Azure DevOps to automate your DevOps process. With the process template, your entire DevOps process is defined.
Work item types : These refer to those work item types that are necessary and the information they should have attached to them. You can also define the workflow for a work item. For a bug, you might have different states through which the item flows, such as active, resolved, closed, and so on.
Project phases : By using areas and iterations, you can define the initial project phase setup of your projects. If you use RUP, you can define the process phases in that model or you can create the first sprints of a Scrum project. Areas and iterations are flexible, and you can create your own way of working through these concepts.
Document structure and templates : The number of documents that should be produced during a project differs depending on your process model. In the process template, you define the document structure you need and the templates you should use. For instance, you can add templates for requirement specifications or acceptance testing.
Reports and queries : In the process template, you can specify which reports and work item queries you need to have as defaults in your projects. You probably want reports and queries that show the progress of your project, such as the status of bugs or work remaining. You can create your own reports by using Power BI, SQL Server Reporting Services (TFS 2018) or Excel, and then add them to all projects by adjusting the process template.
Security : The template also adds information about which users or user groups have access to which information. You can connect Azure DevOps groups to your Active Directory accounts, for instance.
The process template is the overall process for our ALM implementation. Many of our customers create different templates for different kinds of projects. They also create templates for Operations, so that when a development project is finished and deployed, the operations staff can use the template to run the system until the system dies. A few customers have started creating a template for Information Technology Infrastructure Library (ITIL), for instance, and we are looking forward to seeing the result of that work.
It is important to remember that you can adjust the process to your needs. You should consider changing the default templates or even replacing them, rather than adjusting your own way of working to the templates that come with Azure DevOps out of the box. Microsoft enables this flexibility by letting you access the process templates easily to adjust them or to add new templates.
Visibility
Information about project status is important to all participants of a project—and we don’t mean team members only, but stakeholders and decision makers as well. As project managers, we have spent too much time chasing down information to answer questions about the status of projects, how much work remains, and what the latest bug status is.
- 1.
Widgets and dashboards : Customizable, highly configurable dashboards provide us and our teams with the flexibility to share information, monitor progress and trends, and improve our workflow.
- 2.
Queries: Queries are used to ask questions of the work item tracking service. Some questions might be: How many bug work items do we have? How many and which are dedicated to me? How many bugs are there? And so on. You can create new queries when necessary.
- 3.
Power BI: The integration of the analytics service with Power BI makes getting the data into Power BI easy, so you can focus on creating Power BI reports.
By using these components, it is easier to gather the information you need for your status reports for a steering group meeting or project meeting. You won’t have to look around in several places and in several applications for this information anymore; instead, you can use the automated reports and queries from inside Azure DevOps.
Project owners, PMs, and Scrum masters certainly benefit from Azure DevOps. Because Azure DevOps has all data in the same repository, you can retrieve the correct information more easily when you want it. The flexibility of the SQL Server database that stores all information is great. You can work with the data warehouse information just as you would with any other database.
Viewing dashboards from Azure DevOps
Collaboration
As you know, Azure DevOps comes with Team Explorer, which is an add-in to Visual Studio. With this tool, developers can access every aspect of an Azure DevOps project. They can view reports and queries, for instance, as well as access the documents in the project. Developers can access the version control system as well as build systems, tests, and so on.
Team Explorer is full featured, but it is still a tool for people used to working in Visual Studio. For us, that is no problem; but, for most PMs and stakeholders, the GUI is confusing. They want to have a tool that’s easy to use to access relevant information.
Each project created with Azure DevOps has a project portal created as well. This portal gives you access to reports, documents, project process guidance, and other project-related information through a web interface, which enables people who are not used to the Visual Studio interface to retrieve the information they need easily.
The Azure DevOps wiki
Sample discussion thread in a work item
Work Items for Collaboration
Assigning work items to a specific person
The Gap between IT and Business
Closing the gap between IT and business is obviously a very tough problem to solve. Azure DevOps won’t get us all the way; that’s for sure. We don’t think any tool ever will, because so much depends on the people in the organization, which is an important consideration. But, tools can help us bridge the gap, so you should consider carefully how you can use them for this. Organizations need to improve on their ALM process and way of working to start addressing this issue. Once a new way of working is in place, Azure DevOps can support much of their efforts using, for instance, the process template to implement this new way of working.
The gap between IT and business is often a question of work process. It requires considering many things, and when we have a solution—or start working toward a solution—we must evaluate which parts of this work process we can automate and use tools for solving. One thing worth mentioning here is that the use of the Azure DevOps Project Server Connector with Azure DevOps lets you integrate Azure DevOps with Microsoft Office Project Server. Having this integration allows you to control your resources and automate this process more effectively as well. In this way, you can align your portfolio management process better so that you can choose which things to work on more effectively.
Office/Microsoft Project Integration
When we have run projects in the past, we mostly used Microsoft Office Project to handle project planning, especially the Gantt diagram. We suspect that this is the case for many of our fellow PMs, as well. In many cases, we used this product not, primarily, because of the tool itself, but because so many of our customers use Microsoft Office that it becomes natural for them to use Project. Project has its strengths and weaknesses, as all tools do, and we cannot say we don’t like it, but we have never become friends with it. Sometimes it does things we don’t expect, and even though we know this is because we are not very familiar with its features, we still blame the product from time to time (which is unfair, but that’s life sometimes).
Excel and Project are two tools that most companies use on both the business and the IT sides of the company. By being able to use these tools, business people can be a part of the ALM process more easily, because they can use a tool with which they are already used to working. A nice feature here is that the communication between Office and Azure DevOps is two-way. This means an update in Azure DevOps is reflected in Office, and the other way around. This allows for a dynamic way of working with Azure DevOps information.
Use of One Tool/Role Based
A good ALM tool should enable you to use add-ins that provide new features inside one interface. If a developer needs testing features, you should be able to integrate them into the development tool. The developer should not have to switch tools to do testing tasks. This is also what Visual Studio offers. There is no context switching because team members can use the same GUI no matter what role they are performing at the moment. Azure DevOps is also extensible and lets you create your own add-ins as well as purchase third-party add-ins that are accessible from inside Azure DevOps.
Extensibility
When the built-in features of Azure DevOps are not enough, you can use the extensibility features to expand and enhance it. Azure DevOps is often seen as a closed black box that Microsoft ships, when it’s more like an enterprise resource planning (ERP) system for DevOps. Any DevOps environment must be customized for an organization’s processes, existing applications, and services.
Many of our customers have been a bit reluctant to customize TFS. They have instead tried to squeeze their way of working into the templates Microsoft provides. We think this is the wrong way to do it. Our suggestion is that you start the other way around. Start by asking yourself how your organization wants to work. This process involves all parts of the organization, from the business side to Operations. Try to find agreement on how to work in the DevOps process. By doing so, you will see that this also is a good start for collaboration within the company. With Azure DevOps you can customize your process (more easily than with TFS), so you should not avoid customizations.
For instance, consider the work items and the information in them. If the fields and information in the templates are not enough, you can extend or edit them. Azure DevOps lets you do this by changing the process template. You can choose to add the information you need, and it is stored in the Azure DevOps databases, so you can have access to it from within your reports and queries. Don’t forget to change the reports or queries, as well; otherwise, you will not see your information.
Some of our customers have changed the workflow of a work item by adding more states to it when the ones supplied have not been enough. Often, we have used TFS Power Tools to do this for TFS (and still do for TFS 2018), but Azure DevOps provides an easy way to do this through the web interface.
When you have an initial idea of how you want to conduct the DevOps process, start looking into what Azure DevOps gives you out of the box. Use what can be used, change other things, and build your own solution when needed.
One great strength of Azure DevOps is its extensibility and flexibility. You can adjust the whole tool to fit most parts of your DevOps process. If you want to, you can develop your own add-ins by giving support to roles not included from the start. We strongly encourage you to use these extensibility features; but, in the end, it is your choice.
Extensibility is a great way to integrate existing systems and potentially migrate some of them into Azure DevOps to reduce the tool set in the organization.
Difference between TFS and Azure DevOps
Comparison between TFS and Azure DevOps
Feature | TFS | Azure DevOps |
|---|---|---|
Work items, version control, and build | ✓ | ✓ |
Agile product/project management | ✓ | ✓ |
Test case management | ✓ | ✓ |
Heterogeneous development (Eclipse, Git) | ✓ | ✓ |
Ease of installation and setup | Good | Better |
Collaborate with anyone, from anywhere | Good | Better |
Data stay inside your network | ✓ | ˚ |
Process template and work item customization | ✓ | Good |
Data warehouse and reporting | ✓ | ˚ |
CodeLens support | ✓ | ✓ |
Cloud load testing | ˚ | ✓ |
Application insights | ˚ | ✓ |
Always running the latest version of Azure DevOps | ˚ | ✓ |
Summary
In our opinion, Azure DevOps can help you implement a good, automated, and robust DevOps process. There are features for all aspects of ALM. When used correctly, these features help improve the DevOps process, which result in better business value and more successful projects.
The three pillars of ALM—traceability, process automation, and visibility—are important to all organizations. Azure DevOps is a great foundation on which to build DevOps solutions. Azure DevOps has work item tracking for traceability, process template implementation in the tool itself for process automation, and reports and queries for visibility. Through a project portal, accessible via the Internet, you can improve collaboration among all parties that have an interest in your projects.
Azure DevOps is role based in the sense that it supports different development roles. It has support for architects, developers, DBAs, testers, and more. They are not given separate tools; all are accessible from a unified GUI. You can also add custom add-ins to the GUI and do not have to use several tools to get the job done.
Product owners and PMs have the ability to use tools with which they are already familiar. Many use Excel or Project for project planning, and there is integration between these tools and Azure DevOps. You can sync information easily between tools.
The extensibility of Azure DevOps makes it fairly easy to write your own code that integrates Azure DevOps with other applications. This is an incredible strength of the tool, and something for which we should give Microsoft credit.
So, all in all, Azure DevOps is a great foundation on which to build your ALM and DevOps process.