Case Study from Real World Experience: Microsoft Windows Sustained Engineering Teams

6/15/19 by Jon Fincher

Case Study: Microsoft Windows Sustained Engineering Teams

When I first started as a program manager in WinSE, there were two distinct Windows servicing groups — one located in Redmond, WA, and the second in Hyderabad, India.


The team in Redmond serviced the most recently release version of Windows, while the team in India owned all the serviced versions of Windows prior to that. For example, at one point, the team in Redmond would service Windows 7 and Server 2008 R2, while the team in India would service Windows Vista, Server 2003, and so on. Each location had a full servicing team available, including program managers, developers, and testers. The exception was release, which was owned in Redmond only.


While each team owned separate products, and were generally autonomous in how they worked, there was still a lot of coordination needed. Simply stated, any problem fixed in one version of the OS needed to be explored and possibly fixed in the others.


Consider a security issue found and fixed in Windows 7. If we did not fix it in Windows Vista as well, and release it at the same time, it would be a simple matter for hackers to reverse engineer the Windows 7 fix and begin attacking Windows Vista.


Now consider a customer-requested fix in Server 2003. We similarly would need to make sure the fix was also available in Server 2008, and all future versions of Server as well. If not, a customer who upgraded from Server 2003 would encounter the bug again (called a regression).


This level of coordination required some management between two distinct and geographically separated teams. So how did we do it?


It was a multi-faceted approach:


The PM’s from each location talked face to face at least weekly.

We setup a conference call, which mimicked a weekly Sprint planning meeting. In that call, we discussed the bugs and issues with which we were dealing that week, how they might impact the other team, what our plans to deal with them were, and which release they were targeting.

Email and chats were common.

The weekly conference call was not the only communication channel. Since release was handled exclusively in Redmond, it was important that the Redmond team understood the issues presented by the Hyderabad team.

Engineering communication was encouraged.

We didn’t funnel everything through the program managers. Engineers were encouraged to communicate with their counterparts between locations as well. Getting the program managers involved would have turned a quick and easy engineering discussion into a time-consuming game of broken telephone.

Every bug and issue was tracked in a central online database.

Everyone could query and review this database, including the program managers, engineers, and management. Data on every bug included engineers assigned, planned release dates, and data on code changes. Bugs raised against one version of Windows automatically opened bugs against the other platforms, which were discussed and assigned to engineers the weekly PM calls.

The mindset behind this approach was transparency and accountability. We made sure information was freely available to everyone, and that everything was tracked. Without this mindset shift and broad buy-in for it from management down to the individual, we never could have been successful.

- Share with your friends or followers.