SAFe® in Azure DevOps - Teams and Boards
We're finally getting to the good stuff in this series on configuring Azure DevOps for ARTs and Teams. So far we've:
Built the Process where we set up the Work Item Types and established the Backlog Hierarchy
Configured Iteration Paths for Program Increments and Sprints
Set up Area Paths which we're going to use to build our Teams
Now it's time to finally build out the Teams in ADO. Generally speaking the only way to see something on a Kanban Board in Azure DevOps is to build a Team. (There is a plugin which makes it possible to build a Kanban board using a query, but its functionality is limited at the moment, and that's more than can be covered in this series.) So this article is as much about building Kanban boards as it is true Teams in ADO. Just to be clear, Scrum boards or Team boards or Sprint boards and the like are all Kanban boards with different names.
Kanban boards have, of course, become the standard way of visualizing and managing work in Agile environments.
Here's a key principle when configuring Kanban boards:
Kanban boards should serve the people doing the work over management.
For example: team members should only have to look at one board to find and manage their work. Management, be that a functional manager or a product manager, may have to go to several board or run a query to find what they need, but that's better than the other way around. Form real Teams and then bring the work to those Teams rather than pulling individuals into groups or so-called "teams" and making those people manage work in two or three places.
OK, enough Agile coaching talk, let's configure the tool!
Creating the Team
Building and configuring Teams in ADO can get a little confusing because the Project Configuration panel has two places for working with Teams. In this case we want the General / Teams section.
When the Project is built it automatically builds a default Team which has the same name as the Project itself. We're generally going to ignore that Team.
In our scenario we have TeamA and TeamB forming a tiny Train we're creatively calling ART1. So let's build TeamB first. On the Teams page click the New Team button.
Here is where you enter the Team's name (again, this can be changed later). The critical thing in this approach is to uncheck the box for creating the Area Path. Since we manually created the Area Path in the previous post, we're going to manually assign it in the next step.
Click Create and the Team is made.
A few other things to know:
The Description is useful, especially in large ARTs with creative Team names. It's helpful to know which apps or components the Autobots are working on as opposed to the Avengers or the Smurfs, and without a description then no one would ever know that POT stands for the Paid On Time finance team!
Every Team needs at least one Administrator. The admin is typically a Scrum Master or Team Lead. Team admins can:
Add and remove other Team members
Modify Board columns
Assign Iteration Paths for the Team and create new ones for the Team
Assign Area Paths to the Team and create Sub-Area Paths for the Team
Assigning Team members is good
Default security settings in ADO means that a member of one Team can see and modify everything for every Team
Adding a Team Member helps with some Dashboard widgets
Team Membership is useful with some plugins
The easiest way to add someone to the ADO project is to add them to the default Team in ADO
Configuring the Team
Creating the team is nice, but it isn't usable right away. At this point the Team exists. We can see it in the Project Settings page.
And we can find the Team by going to Boards and clicking on the Team name at the pulldown at the top of the page.
But when we select TeamB we have a problem.
There's a little more work to do before Team B is ready for action. Now it's time to go to Project Settings / Team configuration page. Then select TeamB at the pulldown at the top of the page.
We need to add both Iteration Paths and Area Paths. These can be done in any order since the Team and Boards cannot be used until both are in place. Let's start with the Area Paths. Click on Areas and then Select area(s) to see the Area Paths we created in a previous post.
This Area Path is now added to the Team and is the default Area Path. That means that if you're working in a Team page and add a new Work Item, it will automatically be placed in that Area Path unless you manually select a different one. This is a good thing!
Next it's time to add the Iteration Paths. On the same page click on Iterations. Click Select iteration(s) and you'll see all of the Iteration Paths we created in a previous post.
First we have to select a Backlog Iteration. All other Iteration Paths for this Team must be a child of the Backlog Iteration. Generally speaking the top Iteration Path is the right choice.
You'll get this error which is OK when first setting up the Team. If you're changing things later then make sure to read the documentation and understand what's happening.
Now that the Backlog Iteration is set you can start adding Iterations.
The first thing to note is that we're adding the individual iterations under PI 1 and not PI 1 itself. Again, either a parent or a child can be added to a Team but not both. The second is that once you select the first Iteration it's easy to add the next 4 because ADO will attempt to automatically identify the ones you want to add. You can only add 5 at a time, though.
Now let's add future PI's. While this isn't truly necessary, it's helpful to have a placeholder for those Features the Team knows it needs to put off until the future.
Now that we have Iteration Paths and Area Paths assigned we can update the Backlog hierarchy. Recall that the Backlogs were configured in the Process, and in our case the Features level includes both Features and Enabler Features and Stories includes both User Stories and Research Spikes.
We're going to leave this configuration as-is for now since we want to manage Epics centrally while having individual Teams manage Features and Stories.
Configuring Team Boards
At this point we have Teams. The nice thing is that ADO automatically builds Kanban boards for Teams. The Team boards can be access by selecting Boards / Boards. (Nope, that isn't a typo, that's just how ADO's navigation works.)
The Team is selected by the pulldown bar at the top of the page.
The level is selected in the upper right hand of the page.
By default the columns match the states for the Work Items.
We can change that if we want by selecting the wheel in the upper right.
And when I select Columns I see that there's a difference in my Process. User Story has a Resolved State while Research Spike doesn't, hence the advice about configuring all Work Item Types at the same level to have the same States.
If we were to map Research Spike to Active now and then remove the Resolved state for User Stores at another time then Boards would show an error like this.
So instead we updated the process and hid the Resolved state for User Story.
And now the Board configuration panel shows an error which we can easily resolve by just removing the unnecessary column.
And now the Board is ready for use!
Advanced Team Configuration
If you recall from the Area Paths post, in our scenario we made a Sub-Area Path for TeamA for its unplanned work. We can add that in one of two ways. The first choice is to include all Sub-Area Paths.
The second option is to explicitly select individual additional Area Paths. In this case the additional Area Path just happens to be a Sub-Area Path.
There isn't really a right or wrong choice here, but there are some ramifications. For example, you may want a Sub-Area Path for items that are unlikely to be worked but not ready to be deleted. They would still show up if you include Sub-Area Paths while they would not if you individually select the Area Paths.
And now if you select the funnel in the upper right of the screen on the Board you can see that we can then filter the Board by Area Path.
Final Note
One thing to know about ADO is that the Sprints functionality is focused on Tasks which are children of User Stories. And the Capacity tool is focused on hours. Since SAFe® doesn't recommend this approach, we recommend running everything off of the Board shown above and filtering the view to the Current Iteration.
