The SDL Process: it’s a good thing

I received a link (thanks, Jonathan) to this post titled “Subvert from Within: a user-focused employee guide” on the Creating Passionate Users blog. I’m not sure that I characterize these customer-focused focus points as subversive. (BTW, a good “top eight list” can be found on Peter Davidson’s be connected blog.) I do like the top five (IMHO) out of the blog…

• Frame everything in terms of the user’s experience.
  
• Speak for real users… not fake abstract “profiles.” (I’ll include “Put pictures of real users on your walls” under this one)
  
• Get your hands on a video camera, and record some users. (I’ll put this under “Know your customer”)
  
• Challenge user-unfriendly assumptions every day.
  
• Don’t give up.

These are all great. But there’s one point in particular I don’t agree with in the blog: “Be afraid of Six Sigma. Be very afraid.” That’s like saying “be afraid of power steering,” something that you know has its place in certain everyday experiences, but you may not understand exactly how it works. (Note: I have a conceptual knowledge of it, thanks to how stuff works.) 

There are aspects of continuous improvement, striving for quality and better processes that can help the organization in different parts of the company’s operations. For examples, look at how our own Ops & Tech Group use the Microsoft Office System Accelerator for Six Sigma, and John Porcaro’s note and overview on Six Sigma in Sales & Marketing.

There have been some questions around process improvements at Microsoft and the impact to various teams, so let me put this rumour to rest: a squadron of black belts did not parachute in to Redmond, take the dev teams hostage and force them to read “Six Sigma for Dummies” while listening to Jeffrey Immelt sing his greatest hits.

Now, we do have a number of examples where we’re seeing process and systems improvements that impact our products are everywhere through the company, notably in security and privacy. I was reminded of this in the ride back from the Company Meeting as I sat next to Glenn Fourie, our International Privacy Strategist. From a process stance, we’ve built the Security Development Lifecycle (aka “SDL”), the development process we’re using across the company and in the product groups. It helps us ship software to our customers and partners that has been created by devs trained in the art of the SDL, spec’ed and tested to be more resilient and secure.

Steve Lipner (you can see him mug for the camera at the Secure Software Forum) and Michael Howard in the SBU documented the lifecycle, which also includes our introspective look at products in something called the Final Security Review (affectionately know internally as the FSR). In order to get approval for release, software products must go through a detailed review. In the FSR, we look at whether or not the product is ready to release to our customers and partners before we get to the release. In his blog, Soma covered the various phases of the SDL in VS2005. The FSR not only looks to see whether the code is ready for release, it also helps us determine the origin of any issues through RCA and (if needed) prevent them from happening again in the future (through our engineering and security training curriculums, dev/ test/ spec or other process improvements).