What I learned about Microsoft doing DevOps: Part 2 - Planning and alignment when scaling Agile

2017-11-13

In part 1 I looked at how the Microsoft team that builds VSTS and TFS began on their journey towards Agile, DevOps and Cloud. In this part I want to focus on some of the techniques that they use to plan their project and scale the process across the hundreds of people that work on VSTS and TFS. Let’s begin by looking at planning.

This is part 2 of a series on DevOps at Microsoft:

Planning in an Agile world

Are you allowed to plan when doing Agile? I hope you agree with me that planning is still important even when working in a fast changing world where we develop and ship software. There is however a big difference between the planning that goes into a development cycle that’s going to last two to three years and the planning for a fast paced Agile process.

Plans are worthless, but planning is everything.

Dwight Eisenhower

The VSTS team has chosen two work in sprints of 3 weeks. When the team starts a new sprint they know what they’re going to do. The program manager is responsible for making sure that the product backlog items for the team are detailed enough to start working on it. This means the team and especially the program manager doesn’t only look at the current sprint. The teams have a detailed plan for the next three sprints. And please don’t think of big documents when you read detailed plan. Program managers often create lightweight storyboards in PowerPoint. As an MVP I’ve often seen those PowerPoints when the team discusses new ideas for feedback. They are easy to create but still capture everything that’s needed to build the new feature and replace big specifications that would otherwise have been written.

After those three sprints, teams have a rough idea what they’re going to work in the coming 6 months. This doesn’t have the detail yet that the three sprint planning has. A team however has a rough idea what they are going to work on as is described in their charter. The program manager has to work with the leadership to make sure that ideas that are almost in reach have more detail and can be picked up when the team’s ready.

Teams don’t look any further than those six months. The leadership does however and this is what they call their strategy. The strategy is for another twelve months in the future. Items on this list are big, strategic features such as add Git support or reporting. The amount of detail is even less then on the season planning but this is where Microsoft thinks the industry is heading and which features they need to offer.

Figure 1 The planning for VSTS

Alignment and Autonomy

One question that always comes up when scaling Agile is how to find the right balance between alignment and autonomy. That this question is extremely important to build successful teams is shown by the book Drive by Daniel Pink. Pink describes that true motivation comes from having autonomy, mastery and purpose. Take the example of two teams both working on an encyclopedia. The first team is well funded, hires the best people and is established in the market. The second team works for free, in their spare time and only because they want to. Who do you think wins?

The first team was Microsoft Encarta. The second team Wikipedia. Funny enough, Wikipedia now has a page that describes what Microsoft Encarta was.

Microsoft tries to keep the right balance between autonomy and alignment. For example, teams are allowed to choose their own process methodology. Some teams use Kanban, others Scrum and there are probably other flavors throughout the organization. Some teams deploy continuously, others follow a sprint cadence for their deployments. Teams are also fully responsible for the feature they build and how they build it. They can make their own decisions.

Other things are aligned between the different teams. For example, release notes are published on a three week sprint cadence. Technologies are chosen above the team level. For example, VSTS is currently undergoing a move from Knockout to React. Some teams are tasked with experimenting with new technologies and making sure that the organization is always moving forward.

Alignment is mostly present on the planning and backlog level. An individual team can’t decide that today they are working on version control and tomorrow on release management. They also can’t decide they don’t like the current feature and without any deliberation decide they change course. In practice this means that management owns epics and features while the teams own stories and tasks.

Figure 2 Finding the right balance between alignment and autonomy results in succesfull teams

Keeping up

You can imagine that all those teams working on a large product like VSTS create an enormous amount of features to keep up with. To make sure that all these teams stay aligned with each other and know what’s happening over the full breadth of the product, the teams use Sprint mails.

Figure 3 Sprint mail showing the progress and plans for the next sprint

Figure 3 shows such as a sprint mail. The first part of the mail discusses what has been done in the current sprint. This is often accompanied with a short video that shows the new features. The second part of the mail shows the plan for the next sprint. This includes links to work items and screenshots of the storyboards that have been created.

This email is sent to the whole VSTS organization. Everyone can read this mails and keep up with what other teams are doing. Of course this is a lot of information and the detail in which you read each mail depends on the area you’re working in.

Conclusions

This second part concludes the Agile process that the VSTS team follows. As you have seen, the cloud cadence, changes in the organization chart and the alignment and autonomy when it comes to planning and daily work form the basis of how the VSTS team works. Of course this isn’t a clear blueprint that you can follow and immediately have success. But hopefully, the steps the VSTS team has taken can be an inspiration for how you can begin your DevOps journey.

In the next part we’ll dive into the code and see how Microsoft has changed its engineer practices to keep up with the increased pace of DevOps.