Here we share three useful tips that will help you be more successful with your Azure DevOps implementation. Follow them carefully if you want to make the right decisions.

Suppose you are looking to implement Azure DevOps in your software development organization. In that case, you need to make a series of decisions that will drive your teams’ capabilities toward success.

In one of our previous articles, we talked about the work item tracking model in this platform. Now, we would like to share the following three tips we have learned using this Microsoft service platform over the last years, which can be useful for making the right decisions.

1.    Choose the right structure: Team Projects vs Teams

Before starting with your implementation, one of the fundamental decisions to make is how you will organize (or divide) your working groups within the platform.

Each of your teams will have their own tasks, source codes, pipelines, and test cases, and you’ll want your teams to stay focused on their work. However, the reality is not that simple.

The teams’ boundaries are not often clear and precise and can overlap. They can share common source code or artifacts, or people can participate in more than one team, as it happens with UX/UI designers or testers (it could also happen to developers). In addition, you might have privacy or security needs, as you want to allow only certain people to access the code, work items, or test cases.

To make a long story short, you will need to find the right balance between isolation and collaboration. Azure DevOps provides three different levels of isolations. Under one Azure DevOps subscription, you can have Organizations, Team Projects, and Teams. They are linked in a hierarchical relationship — each Organization contains a collection of Team Projects, and each Team Project contains a set of Teams.

• Organizations (previously known as Collections) are fully isolated from each other, and there is no collaboration among them. They are the right choice when you need to implement rigid boundaries across Organizations for security reasons. A good example could be giving one Organization to each business division of an enterprise.
• Team Projects provide isolation but allow for collaboration at the same time. Each Team Project can see and share elements with other Team Projects, but they will have their own process definitions and security rules.
• Teams provide the best collaboration with almost no isolation with other teams inside the Team Project. All Teams will share the same process.

Within an organization, the two main alternatives are:

1. Create as many Team Projects as the number of teams you have.
2. Create a single Team Project and set up a Team for each team.

Each solution has its advantages and disadvantages. At the end of the day, you’ll decide based on your company’s needs. If you have teams working with different processes and products, you should probably choose option one. On the contrary, if you are looking for standardization in your development process and your teams work on the same set of products, option two will be the best for you.

For more information about how to plan your organizational structure, look at this.

2.    Don’t be afraid to explore it!

Azure DevOps offers a set of “out of the box” processes:  Basic, Agile, Scrum, and CMMI. We recommend choosing the one that best matches your current Software Development Life Cycle (SDLC) to provide a solid starting point. However, there is much more you can do. Customization and extensions are available, which can help you to accommodate the tool to your needs.

The customizations available will allow for the incorporation of information or elements that your organization needs for its activities. For example, you can add new fields to existing work item types or even create your own.

Extensions are plug-ins developed by Microsoft or others, which will expand the “out of the box” capabilities of this platform. If there is something you want to do but the necessary items aren’t available, check if there is any extension that provides what you are looking for.

We recommend you create a Proof of Concept (PoC) Organization inside your Azure DevOps account, where you can explore these ideas without being afraid of breaking your teams’ processes. Once you have done enough testing of these capabilities, you can confidently apply them to the real Organizations inside Azure DevOps.

3.    Don’t fall in love with Areas

The Area is a key element of the work items, and it plays a critical role in what each team sees in their boards. Microsoft highlights, “Area paths allow you to group work items by team, product, or feature area.”

One of the mistakes that I have made (a few times) was going too deep in the Area definitions. My first interpretation was that the Areas were a functional classification. We have an Organization with a set of products, each product has a list of modules, and each module has a list of features. We wanted to use the Area field to know to which product, module, and feature a work item belongs. To accomplish that, we defined all products in the Area Path Hierarchy, then all the modules for each product, and finally, each feature for each module.

Although it seemed like a great idea, that way of using the Area data element ended up being a big waste of time for several reasons. First, it was hard to find a common understanding of that structure among the team members. People have different interpretations and understandings of the product’s functional structure, which could lead to confusion and incorrect Area setting.

Second, it was hard to keep the Area Hierarchy up to date, and third, the team spent extra time filling the right Area for each work item or they didn’t complete it at all. In the end, we didn’t find any good use of that data beyond the classification.

The conclusion was that the cost of that approach was much higher than the benefit. The lesson was to keep the lists of Areas as straightforward as possible. In our case, we found that having only one Area for each Team was the simplest and the most efficient approach.

Summary

Before proceeding with your Azure DevOps implementation plan, you need to analyze which tailored process will help your teams find their highest level of productivity. Over time, you can make some adjustments; however, investing some time before jumping into it is necessary.

We hope what we have learned and shared in this article can help you make wise decisions that positively impact your company and processes!

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.