Part 2

Agile at Microsoft: Visual Studio 

Perhaps unsurprisingly, the Visual Studio team was among the first at Microsoft to adopt an agile approach. Even as Microsoft stuck to its waterfalls internally, Visual Studio was used by third-party developers who themselves wanted to use agile methods, creating pressure on the Developer Division to build better support for these approaches. Further, these developers were often looking at or switching to other development tools, ones that were updated more frequently and hence able to deliver bug fixes and new features more regularly.

The first version of Visual Studio to provide some meaningful support for agile development was Visual Studio 2010, released in April 2010 and developed over the two previous years. However, the team rapidly got feedback that some of its templates intended for agile developers just weren’t useful. They were too generic and not directly useful to anyone.

The Developer Division was simultaneously making its first steps toward providing an online, hosted version of its Team Foundation Server (TFS), called Team Foundation Service (also, infuriatingly, TFS). This cloud service was the first time that division had a good chance to break away from the two- to three-year release cycle, instead moving to a more rapid, iterative process.

These two things—delivering something to customers that was unfit for its purpose and delivering a new online service where rapid iteration is both possible and expected—prompted the team to look at new ways of developing its software.

This move wasn’t driven from the top. Within Microsoft, it was up to each team to figure out the best approach to developing software, and the Visual Studio team realized it needed to change. They settled on an agile process called scrum. Microsoft’s Aaron Bjork, Principal Group Program Manager on TFS, told Ars about how this was done.

Scrum teams are multidisciplinary groups of around a dozen people, encompassing development, testing, design, and analysis roles. Their development work is divided into short, fixed-length iterations called sprints. The length of a sprint is up to a given team, but generally they’re between one and four weeks. Daily meetings are held to report on progress, and these are “stand up” meetings where everyone stands, to ensure that they’re kept short. One member of the team, the product owner, represents the customer. The product owner writes user stories that describe a task that a user of the software wants to perform. These stories are then prioritized and added to the backlog of work to do.

The short sprints give the flexibility and ability to quickly respond to new customer demands. Scrum has a principle that after each sprint, the software should be compilable and usable, which enables rapid deployment and feedback.

Visual Studio’s scrum teams take members from each of the three Microsoft roles: a program manager (who becomes the product owner) and some mix of developers with a dev lead, and QA with a QA lead. Each individual team manages its own backlog. At the start of a sprint, a few items from the backlog are chosen according to their priority, and at the end of each sprint, those items should be complete, with a working, tested implementation.

That’s straightforward enough, though it required plenty of adjustment. Bjork told us that initially, teams didn’t truly get on board with the sprint concept. They tried having five back-to-back “development” sprints, followed by two “stabilization” sprints. While paying lip service to “agile” with its talk of “sprints,” this was essentially the same as the old waterfall process. It suffered the same problems.

Education and discipline solved this issue; teams recognized the importance of building bug fixing and quality work into the sprints rather than treating them as some “other” task as they had done in the past. Fixing bugs and ensuring that the product is always of a shippable quality needed to be integrated into the regular development process.

Even little things like the sprint length had to be learned from trial and error. The Visual Studio team settled on three-week sprints, as for them that was the Goldilocks length.

The problem of scale

However, these were just teething difficulties. The real complexity for Microsoft is scale. Many of these methodologies are built for small teams. This is unsurprising; most in-house development teams at non-software companies just aren’t that big. But Microsoft is a software company. It has thousands of developers (some 3,000 in DevDiv alone) and hundreds of teams. Learning how to be agile while remaining coordinated across an organization of this scale required experimentation.

For this, the team has a set of different time outlooks. Beyond the sprint, there’s a six-month “season” and an 18-month “vision.” As the time window grows, the certainty of each outlook diminishes. A team has a very clear understanding of what it will do and what it will deliver in the next sprint. The season is a little more flexible; while it will generally get the big priorities right, the season’s vision is more malleable still. It could be disrupted by the next “Internet” or “smartphone” revolution, but it still sets the broad goals and direction for the organization.

To keep track of all these things, every three sprints the teams talk directly to the PM, dev, and QA leadership. This reporting doesn’t go through the (still extant) PM, dev, and QA hierarchies; instead, each team reports directly, in person. The leadership doesn’t care about the specific details of each team’s backlog, but it does care about their overall direction, priorities, and any problems they may be having. This communication provides the opportunity to coordinate between teams.

In addition, at the start and end of each sprint, teams send division-wide e-mails to say what they’re planning to do and what they have done. This communication makes it easier for interested third parties to get a sense of what other teams are up to.

Perhaps one of the most important changes the Visual Studio team made was to their office environment. Microsoft traditionally gave each developer a private office. There was a hierarchy of sorts. At low levels, you’d start with an interior office with no windows (having seen a few of these, they’re strikingly grim and depressing). Move up through the company and you’d get a window office, further still and you’d get a corner office.

There is a lot to be said for private offices. Development work can be complex, and distractions during complex tasks are highly unwelcome; open plan offices are by at least some measures less productive as a result. But they also make collaboration a lot harder. Under the old system, there was no guarantee that a PM would be near the devs he or she worked with, likewise the testers. Informal face-to-face discussions meant traipsing through corridors and up and down stairs—or even moving between buildings—to get the teams that worked together in the same place.

For agile development, this is a huge hurdle. Online collaboration is good, but in-person collaboration is a lot better. In person, simple cues, like noticing that a developer has headphones on and so doesn’t want to be disturbed, are effective. That’s much harder to see online.

Bjork showed us the Visual Studio team’s new office space, and it’s very different. Instead of private offices, there are large team rooms that house every member of a team in a few clusters of open-plan desks. The team rooms have small private phone cubicles and meeting spaces, enabling discussions to take place without disturbing others. All have windows. He said that for a lot of developers, giving up the private offices—and one’s place in the pecking order for the much-desired corner offices—was scary. But overall, the new environment has been a success. It enables much more ad hoc, informal discussion, making it much easier for PMs, devs, and QA to have the same shared understanding of what they’re actually trying to achieve.

Part 4

Source : arstechnica.com