Devopsdays 2020: Microsoft’s not-so-easy evolution into the world of DevOps - Abel Wang¶

Tags: devopsdays

(One of my summaries of a talk at the 2020 online devopsdays Amsterdam conference).

For devops he uses a definition of Donovan Brown: devops is the union of people, process and products to enable continuous delivery of value to our end users.

Note: delivery of value, not per se delivery of code or so. Delivering code is painful as things can break. But… if it hurts, do it more often. Find what hurts and keep getting little bit better at it every time. Incremental improvements.

He works at microsoft, so remember they went from shipping boxes with software (every three years or so) to continous deployment… One of the things they changed was to put their best engineers to work on engineering systems. With those systems, they could then build everything they wanted on top of it. This became azure devops.

A core idea: use your own systems. Azure devops is not only for outside users, it is also used everywhere internally. So azure devops problems get discovered and fixed quickly. And it improves continually.

One of their problems was the organisation chart. You had different teams for program management, development and testing. So bugs turned into shouting matches between devs and QA. That slowed everything down. Dev and QA got combined into an engineering team with shared responsibility. That took some re-training and some getting used to. They even lost 20% of the employees as they couldn’t handle it or didn’t want to do it. In the end, it was worth it.

They have now moved on to feature teams. Everything from UI to database to deployment is handled by one team. This way you can handle customer requests and interaction better. And you can get everything done more quickly. Feature teams don’t exist for ever, so as engineer you have the change to try something else from time to time.

They work in sprints of three weeks. Sprint and “quarters” (=4 sprints) are the responsibility of the teams. This deals with the details. The leadership is responsible for the big picture: “semester” (6 months) and “strategy” (12 months). Leadership is even forbidden from looking at sprint backlogs in order to prevent micro-managing!

They don’t want to incur debt. There is a rule: fix most of the bugs within the spint. There’s a little bit of leeway in that a team can take 4 x amount of programmers bugs over to the next sprint. But the amount isn’t ever allowed to be higher. This way, the total number of bugs in the whole system stays manageable. It is a huge difference compared to the longer development cycles they had earlier: a huge stack of bugs could accumulate that was near-impossible to chop down to size again.

So: continuous improvements! It took them a long time.