Yes. 

Oh, wow this definitely sets the record for the shortest blog article I ever wrote…

…Oh wait, I guess you are after more detail than a simple ‘yes’ or ‘no’ answer, right? 
If you are, please keep reading. 

Azure DevOps usage in Microsoft

I think a fair criticism that was levied at Microsoft repeatedly a few years ago was that its product teams weren’t using their own products enough. (we call this ‘dogfooding’ or ‘eating our own dogfood’) This is really no longer true. Both GitHub and Azure DevOps are used universally across all product groups today.

We get a lot of choice over what products and services we want to use as Microsoft employees to be productive (for example: it is totally fine to turn up on campus with your Intune-joined Mac) and it is therefore really great to see that all product groups have converged on the use of first party products. This was less of a push and more of a pull from teams themselves who wanted to have a platform where work can cross-integrate easily.

What’s going well and why?

I think work tracking and source code management is one of these areas, where having the same tool across a number of self-organizing and self-governing teams is incredibly helpful (albeit not necessary) as it just speeds up cross-team working. 

The Azure DevOps team has added the ‘remote related’ feature a while ago which allows us Program Managers to link to other organizations. It’s really useful for big orgs that do not map to a single ADO org. 

Product teams across the company perform semester planning in a similar way and goals are expressed in objectives and key results. These are mirrored in Azure DevOps as items that get updated on a regular basis. Because there is a strong process in place updates actually happen fairly consistently and reliably. 

In my group we also use ADO to document decisions and for more general sprint and iteration planning and execution.  For the teams that I’m aligned to, I try and own the work item tree down to the user story level from where developers take over and define their task/deliverable break down. All the developers I work with are very strong on ownership and will almost always update their items independently which means that very little time is spent on backlog grooming. 

What are the main challenges?

Joining a product team has reaffirmed my belief that less is truly more in ADO. You can have the most beautiful work item structure or code base structure or set of builds, but if nobody keeps them current, or if nobody can easily understand what’s going on the value diminishes incredibly quickly.

Having a strong and well-defined process is really key. This applies to cleaning up old work items, but also reorganizing code and builds. I’d recommend to anyone working with ADO today to have a well-understood process around how every aspect of the tool should be managed. Teams will always interoperate and morph that process to their needs, so it can’t be too prescriptive. With that in mind though it is so important to set a goalpost and define what ‘good’ looks like for your org. 

One thing that we do not do in my group in particular, but something that I’ve seen others do, is to rely too much on Azure DevOps and too little on their teams’ people power. 

What is important to understand is that the tool is only as good as the sum of its parts. Information that isn’t put in cannot be displayed and because all people are imperfect it is difficult to draw perfect conclusions from ADO data. 

Let me explain what I mean: It’s great that we can run all of these fancy analytics on our work item data now and there is obviously a use case where this makes a lot of sense. 

However, what we cannot do is rely on the fact that people will always be 100% accurate in transitioning the state of their items, adding comments, filling in all of the work item fields, etc. 

So, any process or reporting that relies on this may in fact be dead on arrival. I’d recommend exercising a lot of care here. 

Summary

Azure DevOps is a great tool that works well for most software development teams. In Microsoft I’ve seen it work best when interaction with it is kept light, simple, and if there is an understanding that it may not always be fully up to date. 

After all it’s about the people and the products not the tools that help them do their job. 

Ah and finally: Please don’t be that person that blocks their team from innovating by making them put things in a tool.