I work with many enterprise organisations that utilise Azure DevOps, and I often encounter practices that either diminish the effectiveness of its features or, in some cases, break them entirely. Recently, I had the opportunity to speak with Dan Helm, the principal product manager for Azure DevOps, about the top issues that users face. Today, I want to share those insights with you, drawing from my extensive experience as a professional Scrum trainer and Microsoft MVP in GitHub and Azure DevOps.
Understanding Azure DevOps
Azure DevOps was designed by agile teams for agile teams. The product team made a significant shift around 2013, moving from a two-year delivery schedule to a much more agile three-week cycle. As of my last update, they have successfully completed 235 sprints, delivering updates to production with remarkable consistency. This transformation was not without its challenges, especially given the legacy of the Visual Studio Team System (VSTS) days, which catered more to traditional project management than agile practices.
When Microsoft launched Team Foundation Server (TFS) in 2006, the goal was to create a seamless experience for engineering teams, from ideation to delivery, with full traceability. However, the initial implementation was heavily technology-focused, which limited its effectiveness. The transition to the cloud in 2011 marked a turning point, allowing Microsoft to address these limitations and align the tool more closely with agile methodologies.
The 1ES Vision
The concept of 1ES, or One Engineering System, emerged from this transformation. The aim was to simplify product delivery by ensuring that everyone involved in a project had clear visibility of work items, builds, release environments, and more. Today, Azure DevOps supports a wide range of technologies and stacks, fulfilling the original vision of 1ES. However, as with any complex tool, users often employ it in ways that diverge from its intended use, leading to common pitfalls.
Top Four Issues in Azure DevOps
Let’s delve into the top four issues that keep the Azure DevOps product team on their toes:
Same-Level Hierarchy
One of the most frustrating practices I see is the creation of a hierarchy of work items that exist at the same level. For instance, when users add product backlog items as children of other product backlog items, it creates confusion and disrupts the intended structure. This misalignment can lead to errors when trying to order items within the same category, as I demonstrated in a recent session. The system simply cannot handle this kind of hierarchy, resulting in frustrating refresh cycles and lost work.
Misuse of Work Item Types
Another common issue is the improper use of work item types. Users often create custom work item types that do not align with the agile framework, leading to a lack of clarity and consistency. This can hinder collaboration and make it difficult for teams to track progress effectively.
Ignoring the Importance of Traceability
Traceability is a cornerstone of agile practices, yet many teams overlook its significance. Failing to maintain clear links between work items, commits, and deployments can lead to confusion and a lack of accountability. It’s essential to ensure that every piece of work is traceable back to its origin, allowing for better decision-making and prioritisation.
Overcomplicating Processes
Lastly, I often see teams overcomplicating their processes within Azure DevOps. While it’s tempting to customise every aspect of the tool, doing so can lead to unnecessary complexity. It’s crucial to keep processes as simple as possible to maintain agility and responsiveness.
Conclusion
In my experience, the key to maximising the effectiveness of Azure DevOps lies in understanding its intended use and adhering to agile principles. By avoiding these common pitfalls, teams can enhance their productivity and ensure that they are leveraging the full potential of the platform.
If you’re interested in learning more about how to optimise your use of Azure DevOps or want to share your experiences, feel free to reach out. Together, we can navigate the complexities of agile practices and drive meaningful change in your organisation.
I work with many enterprise organisations that use Azure DevOps, and many of them do things that either reduce the effectiveness of the features or break them entirely. I asked Dan Helm, the principal product manager for Azure DevOps, what the top four issues were, and this is the result.
Hi, I’m Martin Hinwood, owner and principal consultant at Naked Agility. I’m a professional Scrum trainer with Scrum.org, a professional Kanban trainer with Pro Kanban, and I’ve been a Microsoft MVP in GitHub and Azure DevOps for 15 years.
Azure DevOps, in its current incarnation, was built for agile teams by agile teams. The Azure DevOps product team transitioned to Agile around 2013, and they moved almost overnight from a two-year delivery schedule to one of three weeks. As of the time I recorded this video, they have completed 235 sprints and delivered 235 times to production in this new model.
This was not always the case, and many of the tools, features, and capabilities which persist from the Visual Studio Team System days of the product are much more relevant for companies that are not using agile practices. When Microsoft created Team Foundation Server back in 2006, the intent was to create a connected experience for all of the tools and capabilities that an engineering team would use. The idea was to create a holistic connected experience from ideation all the way through to delivery, with full traceability of how and why things were added.
However, back in 2006, Microsoft found this to be at odds with the organisation’s general outlook, and they ended up with a very Microsoft technology-only focused system. Fast forward to 2011 and the move to the cloud, and suddenly those limitations were much more prominent and needed to be fixed. There’s a fantastic paper from Buck Hodges, director of engineering for Azure DevOps, on this, and I’ll put a link in the comments below.
As Microsoft transformed TFS to become a cloud product, it also addressed many of the Microsoft-centric issues that held back its adoption. The tool started to reflect the original dream, and the idea of 1ES, or one engineering system, was born. The intent of 1ES, as with the original team system, was to reduce the complexity of product delivery by ensuring that everybody working on a product knew where their stuff was: work items, builds, release environments, and more.
Today, Azure DevOps supports any technology from any stack and has enabled that 1ES dream. However, as with all products, users use them in many ways that were not envisaged by their creators. But with something as complicated as Azure DevOps, there are a number of things that users do that go against the very intent and paradigms of the tool itself.
I’ll show you the top four issues that give the Azure DevOps team palpitations.
So the first item that has the Azure DevOps product team pulling their hair out is same-level hierarchy. Creating a hierarchy of work items that happen to be exactly the same level. So let’s take a look at what that looks like. I’m going to show a simple example, and then we’ll go make a customisation and show a more complicated example.
So here I have my product backlog. I’ve got my product backlog items. I have under here a task, which is a sub-item. So I can quite easily go in here and add a new item. I’m going to call it a child, and I’m going to add a task. Click okay. You can see I suck at that, and now I have two tasks underneath this item. But what I’ve done over here is I have added product backlog items as children of product backlog items.
So it is represented on this board, and I should be able to… can I still move this around? Oh, I can still move this around here. But when I go to try and grab one of these items, I can order it inside of the context. Oh, and there I’ve managed to break it. This is why this is a problem.
Work item 4052C can’t be ordered because it’s appearing in the same category. So if I hit refresh, it’ll have gone back to where it was. There we go. So I was just trying to order within this category, and it jumped out, and that was the problem. If I go and try and order it over here, I will immediately get that error. That’s the one I was going to show you.
And now I can’t do anything with that until I refresh, and it will go back underneath because it has a parent-child relationship. You can’t order that hierarchy.
