Enterprise DevOps Transformation at Microsoft

In this video Abel Wang, Principal Cloud Advocate, DevOps lead at Microsoft, talks about how DevOps transformation happens at Microsoft.

The speakers explain how Microsoft transformed their entire company from a waterfall-oriented business where new versions were delivered every 3 years to delivering new features every 3 weeks currently. In addition, the speaker will also cover the best practices required for DevOps transformation.

At 2:10, the speaker defines the concept of DevOps. DevOps can be considered as the union of processes, products, and people that would allow the continuous delivery of value to the end-users. At 3:42, he briefs on the motto behind a successful DevOps transformation. It is important to detect the part of the process that slows the output. Once that is found, make sure to incrementally better it every sprint.

Impact of Azure DevOps services and methodologies

At 5:56, Mr. Abel begins to explain how Microsoft started to follow agile methodologies and how the box software was transformed into service.

Azure DevOps services became the one engineering service to bring about this DevOps transformation. Azure DevOps services consist of different services that would cover the complete development life-cycle. Some of the prominent Azure services include Azure Boards, Azure pipelines, Azure Artifacts, Azure Repos, and Azure Test Plans.

At 11:09, he states that Azure DevOps is the toolchain of choice for Microsoft Engineering with nearly 96,000 internal users. At Microsoft, work is considered done only when it is in live production and until the telemetry is gathered. Telemetry helps in examining the hypothesis that motivated the deployment.

At 19:54, Mr.Abel briefs that Microsoft can now listen to their customers quantitatively and qualitatively through Reddit, user voice, or through stack overflow. Customers can also directly tweet about the features and products of Microsoft.

The presence of feature teams resulted in re-architecting the applications in a different way. During the transformation phase, the application was architected and designed in a vertical manner (in sliced) rather than the layered way. At 21:44, the speaker talks about how feature teams are structured at Microsoft. Each team is self-managing, has precise goals and tenets defined, and is composed of 10-12 people. Each of these teams owns the development of features in production and also owns the deployment of features.

Sticky yellow note exercise

At 23:23, the speaker talks about the sticky yellow note exercise that happens once a year. Every year, team members are allowed to pick which team they want to be on. If there are vacancies on the team specified by the team member, the member gets picked by their desired team. This exercise is an opportunity for employees to change teams without formal interviews or top-down reorg. In addition, this exercise creates opportunities for everyone to learn new things.

At 24:37, the author states that sprints at Microsoft are 3 weeks long. Deployment happens at the end of every sprint after the sprint planning. The deployment can take up to a week. At the beginning of the sprint, a sprint plan is created. The sprint plan will consist of details explaining things to be done during that sprint. The spring plan is then emailed to everyone. At the end of the sprint, the accomplishments made during the sprint are discussed.

At 26:56, he states that the sprint planning emails are sent at the epic level. Microsoft has a sprint which is every 3 weeks, a quarter every 4 months, a semester every 6 months, and a strategy every 12 months. Teams are completely responsible for the sprints and quarter phase. Team and leadership are responsible for the semester phase, while the strategy sections are completely owned by the leadership.

Conclusion

At 30:28, the speaker iterates that at the end of every sprint, all the bugs must be burnt down. Bugs should not be carried from one sprint to another. A simple rule called the ‘Bug Cap’ was created for this use case. According to this rule, every engineer on a team can carry only 4 bugs from one sprint to the next sprint. This rule was devised considering a Microsoft engineer can burn down bugs worth 4 points within a sprint.

At 32:40, numbers are collected to gauge the performance of the engineers at Microsoft. The engineering scorecard numbers are not used to reward or punish any employees. These numbers are used to help the engineers perform better. At 36:35, the author briefs that every developer check-in should go through a pull request or a code review.

The code is reviewed carefully and unit test verification is also performed. The prominent changes that were done during the DevOps transformation phase include vertical teams, team rooms, a 3-week sprint, continual plan and learning, features shipped every sprint, and a publicly shared roadmap.