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)
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.