Best Practices on the patterns & practices Team

The Microsoft patterns & practices team has been around since 2000. The patterns & practices team builds prescriptive guidance for customers building applications on the Microsoft platform.  The primary mission is customer success on the platform.  As part of that mission, patterns & practices delivers guidance in the form of reusable libraries, in-tool experiences, patterns, and guides.  To put it another way, we deliver code-based and content-based guidance.

I’ve been a part of the team since 2001.   Along the way, I’ve seen a lot of changes as our people, our processes, and our catalog of products have changed over time.  Recently, I took a step back to collect and reflect our best practices.  Some practices were more effective than others, we’ve added some new ones, and we’ve lost some along the way.  To help reflect and analyze the best practices, I created a map of the key practices organized by discipline.  In this post, I’ll share the map (note that it’s a work in progress.)  Special thanks to Ed Jezierski, Michael Kropp, Per Vonge Nielsen, Shaun Hayes, and Tom Hollander (all former patterns & practices team members) for their contributions and insights to the map.

Best Practices by Discipline
The following table is a map of the key practices used by the patterns & practices team over the years.

Discipline Key Practices
Management Team
  • Milestone Reviews
  • Product Portfolio (correlated with customer & business challenges/opportunities)
  • Team development  (leadership skills, communication skills, … etc.)
  • Backlog
  • Connection with customers and partners
  • Fireside chats
  • Meeting with key stakeholders in the app plat space
  • People review
  • Scorecard management
  • Tracking overall team budget
  • Weekly Status
Architect
  • Articulate the inner (scope) and outer (context) architecture (these involve time)
  • Articulate technical principles - drive technical tradeoffs discussions
  • Be aware of roadmaps of the company, and build trust to make sure they are current
  • Be familiar with competitive tech.
  • Customer connection.
  • Groups’ technical strategy and product model.
  • Know actionable industry trends.
  • Overall design with functional breakdown.
  • Relationship with key influencers in the product groups.
  • Spikes / explorations including new approaches (technology and process)
  • Technical challenges
Development Team
  • Ship running code / guidance at the end of each iteration
  • User Stories
  • XP / Scrum with test-driven-development
  • Continuous build and integration
  • Iterations
  • Retrospectives
Product Management
  • Asset Model
  • Customer Surveys (feature voting, exit polls)
  • Standardized product model (app blocks, factories, guides, etc.)
  • Blogging throughout project (planning, development, release)
  • Case Studies
  • Community Lead
  • Customer Advisory Board
  • Customer Proof Points
  • Own Vision / Scope
  • Portfolio Planning
  • Project dashboard
Program Management
  • Customer Connected Engineering (CCE)
  • Fix-time, Flex Scope
  • Scenarios / User Stories
  • 5 customers stand behind it
  • AAD Sessions (Accelerated Analysis and Design)
  • Backlog
  • Exec Sponsor
  • Product owner from M0 (Milestone 0)
  • Quality over scope
  • Scorecards
Release Checklist
  • Release Checklist
  • Release Mail
Test Team
  • Automated tests
  • Focused on overall quality (functionality is tested by dev)
User Experience Team
  • Authoring Guide (Key practices for authors)
  • Content Spec (Content scenarios and outline)
  • Doc Tool (Template for standardizing content formatting)

Some practices are obvious, while some of the names of the practices might not be.  For example, “Fireside chat” is the name of our monthly team meeting, which is an informal gathering and open dialogue.   I may drill into some of these practices in future posts, if there’s interest and there are key insights to share.