In Visual Studio 2013, Microsoft introduces CodeLens and Browser Link, two tools designed to increase developer productivity. Other enhancements to the IDE, which were announced after this magazine went to press but were discussed in a pre-briefing, focus on making the IDE, DevOps and the agile life cycle better.

But the behind-the-scenes run-up to the release is a story that tells how Microsoft has changed how it works, how it maintains relationships with its partners and customers, and how it views the future of development.

Between the 2012 and 2013 release, Microsoft adopted an agile development cadence, according to Aaron Bjork, Team Foundation Server product manager. He noted that this is the first release in which the team used a three-week development cycle.

(Visual Studio 2013’s release details)

“We’ve had a 2008 release, a 2010 release, a 2012 release, and now here we are with a 2013 release,” Bjork said. “So there’s a shorter cycle, but also this is the first release where we’ve really in a lot of ways incrementally delivered value to our existing customers in the way of quarterly updates. What I mean by that is, if you’re a 2012 customer, you’ve had available to you an update every quarter that kind of accrues to what you’re going to see in 2013.

“Certainly, not everything is there; there’s value held back in 2013. But it’s a little bit different, because in past releases you kind of went from this really sort of big bang, from 2010 to 2012, and it’s like, oh my gosh, there’s so much I haven’t seen before. And I think for a lot of our customers, it’s a little more incremental, and I hope our customers like that. In fact I know they like that, because it allows them to wade into some of these new feature, dip their toe into them, get familiar with them, and then really realize the value as those features are maturing.”

What agile changed
While this was good for customers, it might have created problems for third-party providers who are used to hearing about new features months in advance to get their products ready to support Microsoft’s next big release the day it drops. Bjork said this involved a change in how Microsoft communicates with its partners.

“It’s been an adjustment,” he admitted. “One of the things I start with there is that the releases themselves are a lot less disruptive than they’ve ever been. If you’re a partner that has some sort of third-party add-in that works with Visual Studio or TFS or whatnot, we’re going to do everything we can to make sure it continues to work. We’re not introducing a lot of breaking changes in these updates. But I think it has forced us to have probably more conversations with those types of partners, to make sure we’re keeping them abreast of what’s happening, because before we would spend six months planning and then a year and a half executing, and we had a lot of time in there to brief a partner and update them on where we were going.

“You’ve now got much shorter windows, and I don’t mean that to say we’re changing our plans every three weeks, but you’re thinking more in terms of probably six-month windows instead of 18-month to two-year windows. So we probably have a tighter relationship with a lot of those key partners.”

Often, moving to an agile development cycle involved changing roles, abandoning roles that are no longer relevant to that type of development, or creating new roles. Bjork said Microsoft experienced some of that in the move to three-week cycles.

“I wouldn’t say we’ve had to dismantle roles. I think we’ve had to adjust some roles and tweak expectations of roles,” he said. “One of the common ones is the program manager role. We have a title here at Microsoft called ‘program manager.’ If you rewound a few years, you would find that a program manager more closely equated to a project manager. If you fast-forward today and look at our program managers, I would say they’re clearly aligned with what I would call a product owner, to use a Scrum term.

“A program manager is less concerned about schedule and more concerned about value. So that’s definitely an adjustment we’ve made. And I do think when you look at the engineering disciplines, the dev and test disciplines, you see those groups operating much more in lockstep than they ever have before.

“So instead of a development team writing code for four weeks, six weeks, even eight weeks, and then declaring a milestone, like code complete, and then sending it over to the test team, you now have a dev and test organization, or a dev and test team, working in lockstep and writing code, testing code and delivering that code within a three-week cycle,” he continued. “And so it’s definitely forced us to kind of step back and look at those roles and look at how we had traditionally done them, and then put them back together a little bit differently. But the core roles are still there. We still have [program managers], we have dev and we have test, and those are our core roles. And certainly as we’ve dipped our toes in and are entering into the service business, the service engineer role is one that’s becoming more mainstream as well, I would say.”

Bjork described the service engineer as the team member responsible for deploying the bits to the service at the end of every sprint. The service engineer monitors the application and is responsible for the production environment. “I think their job is to help us build a really fast and efficient pipe from a developer’s keyboard all the way to the production environment where the customer can be leveraging that value from their keyboard on the other end, and they sort of provide that bridge,” he said.

Part of building that bridge, of course, is listening to what users want. Bjork put it this way: “Our job is to listen to what customers want, make sure we’re building them what they need—and wants and needs sometimes differ—and…we apologize for everything we’re not doing.”

(Additional details on VS 2013: Visual Studio 2013 announced at TechEd conference)

Sometimes customers take Microsoft in directions it never thought it would go. “If you look back over the course of this year and look at some of the things we’ve introduced into the product, a great example of this is Git support,” Bjork said. “We had developers screaming at us that they wanted us to support Git in a really good way, inside the IDE and within Team Foundation Server. And that, at the time, felt like a very controversial move. But the more we studied it, we realized it was absolutely the right move. And that was 100% based on customer feedback.”

One Microsoft, one heart
Bjork stressed that Microsoft does follow a road map for the evolution of its tools—keeping up with Azure and Office, for example, is a part of that—but he said the team believes one of its most important jobs is “to make raving fans out of our developer community,” and that can only be done by responding to what they’re telling the company. “You wish you could respond to everything; you clearly can’t, but really paying attention to those things that developers are screaming for,” he said.

Meanwhile, keeping up with the other teams is part of Microsoft’s “One Microsoft” initiative, aimed at bringing all the business units in the company in line with one another. As for development, Bjork said, “I can say that we have really strong relationships with all the big players, whether that’s Phone, whether that’s Windows, whether that’s Office, even Xbox, and we absolutely look to them to say what we need to be supporting next and how we need to be supporting it well, to make sure that we’ve got a fantastic developer experience.”

(More on Microsoft’s restructuring post-Ballmer)

As for a recent cartoon published in the New York Times depicting the teams at Microsoft aiming guns at one another, Bjork said, “The ‘pointing guns’ cartoon, it’s interesting, because I see that, but I’ve never seen that from our side of the house, though. I think we’ve always been a strong partner for those platforms and make sure we’re supporting them the right way. If we’re not supporting Windows app development or Windows Store development or Windows Phone development, well, what are we doing?”

Supporting each of those platforms, though, does present a challenge. “You’re seeing us start to do some work already to make sure that we want you to have a ‘write your code once’ experience and have it run on all of the Microsoft platforms, and we’re definitely taking steps in that direction. We’re taking steps in [Visual Studio] 2013, and I think you’ll continue to see us taking more steps in the future to make that really a reality.”