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, 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 |
- 5 customers stand behind it
- AAD Sessions (Accelerated Analysis and Design)
- Backlog
- Exec Sponsor
- Product owner from M0
- 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
- 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.
