News

Microsoft's VS Team Lead Jay Schmelzer: Changes Inside Microsoft and Dev in the Age of DevOps

• By John K. Waters
• 09/20/2018

Microsoft's Developer Division has made significant internal engineering and organizational changes over the past few years as it moved purposefully away from a traditional waterfall development model into Agile territory, eventually betting big on DevOps and continuous delivery. Just last week the company officially unveiled Azure DevOps, which bundles a suite of familiar dev tools with new CI/CD-focused features, and effectively rebrands Visual Studio Team Service (VSTS).

Jay Schmelzer, Director of Program Management for Microsoft's Visual Studio Team, shared the story of this multi-year transition during his keynote at the Chicago edition of the Visual Studio Live! conference this week. It all started, he told attendees, with a groundswell of discontent within the product engineering teams.

"Most of us were not happy with the way we had been developing software," Schmelzer said, "We wanted to have a much greater ability to respond to feedback from our customers."

Back in the bad old days, the divisions at Microsoft operated more or less independently, Schmelzer explained, using their own custom, home-grown systems, and sometimes the relationships among them were almost hostile. The plodding product schedules included coding milestones, test-and-stabilize periods, and beta releases that were already behind the dev teams' next coding milestones.

Something clearly had to change, Schmelzer said, and by the time Satya Nadella became CEO in 2014, the teams were already adopting the Agile practices that would lead to their current DevOps practices. Nadella's arrival "lined up nicely" with the company's evolution, he said.

"He has a very strong engineering background, and he believes passionately that we need to invest in our engineering systems as a company to enable us to deliver the kind of value that you, our customers, were expecting," Schmelzer said.

Today, roughly 80,000 engineers across the company are working in a single, common engineering system. And the entire Developer Division operates on a sprint-based cadence.

DevOps is, of course, at the heart of Microsoft's current software development practices. The company defines "DevOps" as a combination of changes to the culture, processes that can be put in place to facilitate that operating model, and a set of products and tools. "It's that combination of those three things," Schmelzer said. "And the end result is being able to provide continuous delivery of value to our customers, and constantly being able to respond to feedback and changes in the environment."

Why did Microsoft make these changes? Schmelzer laid out three reasons: The company wanted to make sure it was actually building products its customers wanted, empower its dev teams and individual to do their work free of time wasters, and provide continuous delivery capabilities the market was demanding.

Schmelzer cited three keys to the success of Microsoft's transition: getting the organization to be customer-focused, facilitating team autonomy within a unifying framework, and establishing that accelerated cadence.

Getting the organization into a customer-focused frame of mind ("Satya calls it 'customer obsessed,'" Schmelzer said.) involved, among other things, adopting "hypothesis-based" development. "We think a customer is looking for this type of value for this reason," he said, "and we design experiments to validate or invalidate that hypothesis, and then implement mechanisms to learn and understand beyond the initial evaluation whether we're getting the results we wanted."

One of the toughest parts of this transition for the company's engineers: accepting invalidated results. "It was the biggest cultural shift for us," Schmelzer said. But people eventually understood that realizing you shouldn't build something before you start building it is a good thing, he said.

The company also amped up its efforts to listen to its customers with everything from one-on-one meetings with particular users to providing new feedback tools. And it pivoted from focusing on shipping code to shipping valuable features based on usage.

To support individual team autonomy within a framework of organizational alignment, Microsoft implemented what Schmelzer called a "combined engineering model," which pulls once disparate disciplines together into the same room.

"We strive to organize ourselves more vertically," Schmelzer explained. "Think of it in full-stack terms, or the feature team is vertically oriented to a feature. Which is not to say that we don't have engineers with specialties. Let's face it, you don't want an engineer who works on the backend of the C++ compiler to do UI. Also, people get a say in which projects they work on. We found that about 85% of engineers are happy where they are. But they had the opportunity to choose, which helps with buy in."

But this autonomy is tuned to the structure of a shared, sprint-based cadence and the three-week sprint. "Whether you're working on Azure DevOps, .NET, Visual Studio, Visual Studio code, programming languages -- regardless of what part of the products you're working on, you're all on the same, three-week sprint schedule," Schmelzer said. "We tried letting teams figure out their own sprint schedules. Bad idea. Complete chaos. As people tried to figure out how to collaborate and build on each other's work, the timelines wouldn't line up and it became a mess. Now that we're working on the exact same schedule, Sprint 193 means the same thing to every engineer inside the Developer Division."

Schmelzer offered an example to illustrate how all this change has affected Microsoft's ability to deliver value to its customers. The number of features the Visual Studio team ships to customers in a given calendar year has risen from 22 to more than 400. "Four years in we were able to deliver more value to you as a customer in a single year than we had in the four prior years combined," he said.

"It's important to remember that we didn't just wake up one morning and say, we're now DevOps and it's all going to work this way," Schmelzer added. "This is a multi-year journey that we've been on, and we're continuing to evolve. The truth is, you're never really done."