SAFe using Azure DevOps

SAFe using Azure DevOps

As organizations more and more apply an agile way of working many ask themselves how they can get agility to work at scale. There are several frameworks for scaling agile on the market like Large Scale Scrum (LeSS) and Nexus, but many organizations turn to Scaled Agile Framework® (SAFe®).  There is no process that supports SAFe out of the box in Azure DevOps so we need to work with the ones we have got unless we want to create a custom process of our own.

Let us take a look at SAFe first in Figure1.  This is the largest SAFe configuration called the Full SAFe.

 

Full SAFe implementation
Fig 1. Full SAFe implementation.

 

We can find four levels; Portfolio, Large Solution, Program and Essential SAFe that cover most organizational needs we can have. Microsoft has four Work Item Types (WIT) that we can use to support this setup; Epics, Features, User Stories and Tasks. There is a hierarchy to these WITs as the next figure show. This origins from the Agile Process but works the same for Scrum and CMMI. So if you’re interested in using SAFe, you can configure projects created with the ScrumAgile, or CMMI processes to track SAFe criteria.

SAFe using Azure DevOps
Figure 2. SAFe in Azure DevOps. The figure show the relations between SAFe levels and Work Items in Azure DevOps.

 

In Figure 2 we see at what SAFe level these would be used. Epics will support the Portfolio Level, Features the Program Level and User Stories and Tasks support the Team level. In order to further support SAFe in Azure DevOps we need to work with our areas and iteration from Project Settings. In the following figure we can see one way of implementing SAFe in the iterations view.

Iterations for SAFe in Azure DevOps
Figure 3. Configurating iterations for SAFe in Azure DevOps.

 

Figure 3 shows the overall Portfolio level (SAFe Demo Azure DevOps) with one Value Stream present (Value Stream 01). In the value stream we can find our Agile Release Trains (the Program Level), in this case ART 01 and ART 02. Below the release trains we have configured three Program Increments (PI 01, 02 and 03) and below them we have configured the sprints each PI will have.

Because epics can span several release trains, the Portfolio team probably wouldn’t be associated with any specific iterations. Program teams on the other hand will track their Features, which ship with a PI. The Feature teams work in Sprints to complete the stories chosen for the PI. Each team in their turn chooses which iterations will support them to track their deliverables.

Since we are free to configure the iterations in any way we want this is only one way we can do this. You need to discuss what your setup would look like before implementing it in Azure DevOps. One way to simplify the iteration setup would be to use tags for Value Stream instead it all depends on your needs. With tags that we add to work items, we can:

  • Filter any backlog or Kanban board
  • Create queries based on tags, and filter query results by tags
  • Create progress and trend charts or reports based on tags

Once we are satisfied with the initial iteration setup, we can start selecting which areas our different teams should have. We can always modify our iterations as time goes on by for instance adding new PIs. Using areas on the other hand, we determine which items the teams will see on their backlogs and boards.

Areas for SAFe using Azure DevOps
Figure 4. Configurating areas for SAFe in Azure DevOps.

 

As we can see in Figure 4 our Portfolio team will track Epics in each Value Stream and that way keep track on what efforts we have on a higher level.

The agile release trains will be tracked by the ART Management teams (ART 01 MGMT). These teams can also follow everything that happens in each PI on both ART, PI and Team level. In Figure 5 we can see that the ART team can track features on their Kanban board.

Individual boards
Figure 5. Working with areas enables different teams to see their individual boards. In this case the ART 01 MGMT team can follow progress on their Kanban board.

 

The individual teams (Team 01 and Team 02) will work with things on their own backlogs (subsets of the program backlog) so they can focus on their work in the first place. As seen in the following figure (6) Team 01 can follow their PBIs on their separate Kanban board.

Kanban board for Team 01
Figure 6. The Kanban board for Team 01.

 

This has been one way of using Azure DevOps to support SAFe. Keep in mind that the flexibility of Azure DevOps and Azure DevOps Server makes it possible for us to customize our own implementation.

Do you want to start implementing agile at scale? Leave a comment below or send us a message at [email protected]!

 

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.