creating SDKs: endgame
I'm gong to skip ahead a bit on the SDK process and talk a bit about the endgame process. I'll go back and talk more about the nuts and bolts of the process in the next couple of weeks, but I wanted to spend a little time talking about where we are right now with the latest drop of the WinFX SDK. We're in what many people call endgame mode, in which we lock down on a "golden" drop of our SDK, branch our source files, and prepare to RTM (Release To Manufacturing) and RTW (Release To Web) the product. This is a time where we try to get bugs down as close to zero as possible, when we many sure all our handshakes are done, and we do last-minute testing to make sure that things are as rock-solid as possible. Even though this is a Beta release, and therefore standards are slightly lower compared with a full, formal release, we still try to do everything possible to have everything work perfectly. I've been surprised that I never once heard anyone utter the words "don't worry about quality, this is just a Beta." We really do want to get things right. (No marketing puff here, we really do want our users to be happy with us.)
Here's the status mail that my manager sent out Friday on this project:
Bugs = 22 Actives
4 Fork Blockers being assigned. Should be okay for resolution by Friday.
1 Setup blocker tracking
Compiler issues new and being tracked.
* Current schedules
7/18 - Fork on Monday a.m.
7/18 - Shipstopper mode p.m
7/18 - EULA is back
7/18 - RTM Build Launched p.m.
7/18 - Contributor Signoff a.m.
7/19 - Readme signoff p.m.
7/20 and 7/21 Final test pass and sign-off a.m.
7/21 - Build To signing p.m.
7/25 - JSacks drop to **** by p.m.
7/27 - RTM/RTW
22 active bugs is actually a little scary at this stage of the process, but this has been a very tight release where everything came together really late. Thankfully, we were able to reduce the bug count substantially over the weekend, either by fixing the issues or postponing some of the niggling minor bugs that just aren't very critical.
It always amazes me how interconnected the SDK team is with other teams. Legal has to review the EULA, marketing needs to sign off on the names we give our products in the SDK, product teams have to sign off on their docs, the ReadMe is compiled with input from others, the SDK has to go through our Code Signing tool which is run by yet another team, and on and on. Few teams at Microsoft work in a vacuum, and this interdependence can sometimes cause friction. Because there is a fair amount of autonomy inside teams, it's easy to get out of sync and for things to sometimes take longer than we'd like. That's not a problem when you're talking about an automated process like the Code Signing tool, but it can cause friction when Legal needs to do their due diligence with the EULA while our team wants to get it locked and loaded.
It takes strong managers, clear schedules, and a certain amount of pushiness, to navigate this system. That's the biggest part of my learning curve as a new PM, getting a feel for how to manage and push projects, when to be aggressive and when to back off, and how to engage others. I became pretty good at this in my previous job, but on this team, the challenges are, inevitably, quite different. That's something I really want to get a handle on in the future.