Agile scaling with Microsoft Azure DevOps

Agile frameworks have often proven themselves on team level, when small teams (3-9 persons) work on a product at one location (distance < 10m). In practice, this constellation is rarely encountered. For one thing, products often cannot be developed with a small team, so that the work of a much larger number of people has to be coordinated (vertical scaling). Furthermore, teams are often not in one place. Working across different locations (horizontal scaling) is also common. 

Various frameworks are available on the market (including SAFe, Less, Nexus, Scrum of Scrums, Scrum@Scale, Disciplined Agile Delivery). They serve as support to master the challenges of scaling. From our point of view the frameworks should be seen primarily as inspiration and less as a blueprint in the context of a 1-to-1 implementation. Scaled environments often present teams with major methodological and technical challenges. 

Across all frameworks, the following success criteria have been identified for scaled environments:

1. Ensure co-location
2. Direct contact between the team, customers and other stakeholders
3. An overarching, uniform sprint cycle for all teams
4. A joint backlog with a responsible product owner
5. Training of staff on agility, DevOps and technical excellence (architectures, CI/CD pipelines, test management, release management)
6. Reducing dependencies between teams and features
7. Transparency across all levels and team boundaries

To meet these challenges, Microsoft Azure DevOps offers many helpful features, which we would like to introduce to you below.

How can Microsoft Azure DevOps help?

Ideally, the team should stay within a radius of 10m. In such an environment, knowledge is best shared or picked up "by chance". The main challenge in distributed teams is therefore communication. Working with Microsoft Azure DevOps reduces the challenges of distributed teams by integrating Microsoft Azure DevOps into Microsoft Teams and supporting the entire process chain from requirements management to deployment.  

Microsoft Azure DevOps inherently supports the collaboration of diverse and distributed teams through availability in the Microsoft Cloud. A local software installation is neither possible nor required. The introduction to the use of Microsoft Azure DevOps is deliberately kept simple so that stakeholders who are not directly involved in development can also access Microsoft Azure DevOps as an information platform. 
Furthermore, an open, cross-level and cross-team collaboration is supported. So can e.g. project documentation, product descriptions or architectural sketches be centrally managed in the Wiki.

The Microsoft Teams Integration allows you to reference work items directly from Microsoft Teams or to subscribe to changes to work items in the Teams Channel. Team members are actively notified about changes without sending another annoying e-mail. Discussions can also be conducted through comments directly in the work item. 

The advantage is obvious: Extensive transparency about the current status of the product and the work of the team.

Dependencies and handovers between teams must be avoided as far as possible. Unfortunately, it is rarely possible to do without them completely. To coordinate several teams and their dependencies, uniform sprint cycles are recommended.
In Microsoft Azure DevOps the sprint cycles or iterations are managed centrally in the project settings. These cycles are used for overall sprint planning, to which several teams can refer. This ensures that teams work through their scope in synchronized iterations.
 

Microsoft Azure DevOps inherently supports the possibility of using a central product backlog across multiple teams or creating multiple team backlogs. This allows a comprehensive product scope to be edited jointly with different teams. The advantage of a central backlog is that dependencies between backlog items are easier to identify, clear prioritization is transparent and the delegation of topics to the respective teams is easier. Depending on the number of teams, a central Product Owner can quickly become a bottleneck. One Product Owner per team can be useful here and increase efficiency.

We have implemented such an approach in Microsoft Azure DevOps via the Area Path Feature, which enables a central backlog to be edited jointly with several teams while maintaining transparency about which teams are working on which topics:
 

The 'Area Path' created here can now be used to assign backlog items to them and thus reference the responsible teams.

In order to achieve a sustainable transfer of knowledge and the acceptance of new process models, working methods in teams or even working with a new tool, we recommend accompanying the introduction with a suitable change management. The credo "A fool with tool is still a fool" naturally also applies to Microsoft Azure DevOps. In our experience, measures such as the establishment of a champion community, proven coaches, the establishment of virtual or on-site training and, above all, the demonstration of the use of tools and processes by managers have proven to be successful. 

Agile working methods are characterized by a continuous improvement process (PDCA - Plan Do Check Act). At the end of each iteration, the team, even aggregated across several teams, reviews its approach in a sprint retrospective. Especially at the beginning of the use of a new tool or a new process, we recommend to pay great attention to the retrospectives of the performed sprints in order to learn early on from the own way of working, be it with regard to the methodology or the tool. Details about the possibilities of Microsoft Azure DevOps in connection with retrospectives (as well as sprint reviews) can be found in one of our previous articles on this topic.
 

Dependencies between work items can make implementation considerably more difficult and also reduce the value of delivered results or increments. It is therefore recommended that you are always aware of the dependencies and reduce them if possible. A clean structure in the form of epics, features and user stories can help here:

Additional tools can help to keep track of the dependencies and manage them effectively. On the one hand, Power BI allows you to create individual reports that graphically visualize dependencies between items. On the other hand, the Azure Marketplace offers various extensions, some of which are free. One of these enhancements is the Dependency Tracker, which enables both consuming and producing dependencies to be clearly displayed. The extension offers many more useful features that can be helpful for more complex projects to keep the overview.

Microsoft Azure DevOps increases transparency through the close integration of all modules - be it the overview, the boards or the automated test, build and deployment processes. Correctly set up and configured, Microsoft Azure DevOps offers many stakeholder groups the relevant views of the status of a project.

Especially in software development, manual efforts to integrate development results from several teams as well as tests and deployments can be massively reduced (see article CI/CD). However, since Microsoft Azure DevOps focuses more on the operational management and implementation of development projects and provides agile teams with a wide range of tools and features to carry out projects efficiently and transparently, other tools that are more strategic or portfolio-based are a useful addition. Further possibilities are, for example, the mapping of hybrid project environments, which combine classic project or portfolio elements (Project for the Web, Project Online or Project Server) with agile tools such as Microsoft Azure DevOps. Especially in large organizations, this enables high transparency from the management level with a view of the portfolio down to the project details of an agile team (top-down and reverse).