Part 3

The result? Regular releases, regular updates

With the new process in place, the Visual Studio team has been able to build better software and deliver it more frequently. It’s now approaching its 70th successful three-week sprint. TFService, now rolled into a broader suite called Visual Studio Online, has a service update every three weeks, putting new capabilities and features into users’ hands on a continuous basis. On-premises software hasn’t been forgotten either. The sprint-based updates are rolled into quarterly updates for the on-premises TFS.

Visual Studio has similarly received a range of updates on a more or less quarterly basis. No longer is it the case that developers have to wait years at a time for better standards conformance; they get to see, and use, the progress several times each year.

The need for regular iterations has also caused improvement to some unsexy parts of the software. The setup and upgrade process for Visual Studio was annoying and complicated, with a large testing matrix to handle upgrades from various different versions. With an iteration every three weeks, this situation was set to become intractable. Because setup and upgrades are done every sprint, the system needed to be more robust and easier to test and manage. The agile process motivated that work, and the result should be that upgrading end-user machines is less disruptive and prone to failure.

The integration of testing and QA into part of the regular development process, instead of the old test and stabilization phase, means that the code quality is always decent and always shippable. This keeps developers happy, as they’re no longer faced with month upon month of endless bug fixing.

Beyond Visual Studio

When DevDiv went down the agile path, it was doing so on its own. Other teams, including Skype/Lync and Microsoft Studios Shared Services, have gone down similar paths for similar reasons. Sometimes they’ve done things differently from Visual Studio—Skype, for example, uses two-week sprints—but the overall approach, including the need to scale up processes designed for small teams, has been very similar.

Lately we’ve heard from within the company that there is now pressure from the top to adopt these kinds of practices and become agile as an organization.

Company-wide, there has been a new approach to source code and its management. Microsoft is traditionally viewed as a series of fiefdoms, with each team jealously guarding its own work and not sharing with others. As such, people in one team have historically had little access to other teams; they couldn’t see what they were working on or the source code they were producing.

When code did need to be shared—for example, the Xbox team’s fork of Windows, or the Azure team’s fork of Hyper-V—the sharing was a one-off thing. The new team would take the old team’s source code and then develop in parallel. This obviously introduces long-term maintenance problems; the maintainer of each fork needs to somehow incorporate important changes from the main version of the code, which can require complex integration work.

This is changing.

The parallel development, for example, is frowned upon. While a fork may be appropriate in the short term—the Azure team had particular scaling and management needs that Windows Server 2008’s Hyper-V didn’t address, for example—the long-term goal is to ensure that all these modifications are folded back into the main codebase. Nowadays, we’re told that the Azure Hyper-V is identical to Window Server 2012’s Hyper-V. Xbox One similarly needed to make modifications to support its usage scenarios, but we’re told that these too are being folded back into the main Windows codebase.

More broadly, people within the company have told us that source code is now viewed as a shared resource. If people in the Bing team, say, want to look at the Windows code, they can. Further, we’re told that if they want to fix something in the Windows code, then that too is possible (though it needs some coordination and agreement from the involved parties).

Amusingly, we’ve heard this described by several within the company as “open source.” It isn’t, of course, but the terminology is striking. That this greater collaboration is viewed as being “open source” highlights in many ways how insular the divisions within the company were and how those borders are now being broken down.

The agile approach of combining development and testing, under the name “combined engineering” (first used in the Bing team), is also spreading. At Bing, the task of creating programmatic tests was moved onto developers, instead of dedicated testers. QA still exists and is still important, but it performs end-user style “real world” testing, not programmatic automated testing. This testing has been successful for Bing, improving the team’s ability to ship changes without harming overall software quality.

However, there are costs to this setup. The recent layoffs have been poorly communicated both within Microsoft and beyond, but one victim group appears to have been the dedicated programmatic testers in the Operating Systems Group (OSG), as OSG is following Bing’s lead and moving to a combined engineering approach. Prior to these cuts, Testing/QA staff was in some parts of the company outnumbering developers by about two to one. Afterward, the ratio was closer to one to one. As a precursor to these layoffs and the shifting roles of development and testing, the OSG renamed its test team to “Quality.”

The Office question

One big question mark is Office. Office is perhaps Microsoft’s most “traditional” application, with a particularly conservative, corporate-focused userbase. Perhaps even more so than for Windows itself, Office users don’t like their software visibly changing with each new version. They certainly won’t stand for changes that disrupt existing workflows.

Conversely, Microsoft is working hard to encourage users to move to one of its Office 365 subscriptions, and one of the better ways to make subscriptions valuable is to provide regular updates and new features (as Adobe does with its Creative Cloud service).

The teams behind Office 365 and Office for iPad are working in agile ways to deliver regular iterative improvements, and users of those versions are arguably a lot more comfortable with these regular iterative improvements.

How Microsoft will bring this same agile attitude to the desktop Office suite remains uncertain, and the company seems a little more tentative when it comes to Office. The plan, for the time being, is to stick with the three-year release cycle, but the company recognizes that subscribers will expect something more, and it will provide updates of some kind to satiate them.

There have been some small forays into producing minor upgrades for Office 2013. Since its initial release, Microsoft has added some extra buttons to Outlook 2013’s thumb toolbar, for example, and there has been some under-the-hood work. However, the company tells us that its customers are nervous about adding more visible changes in minor updates.

Reconciling the desire to be agile to provide a better experience for customers with customer concern from having things change too much, too fast could be as big a challenge for Microsoft in the next few years as abandoning waterfall development.

A better Microsoft, building better software

For Microsoft’s customers, the improvements that have come from the agile approach taken to Visual Studio development are visible and real. The regular updates and new features mean that Visual Studio gets better every few months; Visual Studio Online gets better every few weeks. The Visual Studio C++ compiler doesn’t handle every aspect of the evolving standard (no C++ compiler does), but unlike the situation five years ago, developers can see the progress that the company is making. It’s now in a position to track the standard developments as aggressively.

Work on Bing is less obviously visible, as Web services can be upgraded transparently, but reports from inside the company are encouraging.

With the top-down demands for quality and agility, Microsoft’s customers should see wider improvement. There have already been signs of a more frequent update policy for Windows. As the company’s developers become more comfortable with the new approaches, the result should be higher quality, delivered more often. Anyone who uses the company’s software should reap the reward.

Source : arstechnica.com