Microsoft is one of the largest companies in the world to use Agile methodologies. Over years of experience, Microsoft has developed a DevOps planning process that scales from the smallest projects up through massive efforts like Windows. This article describes many of the lessons learned and practices Microsoft implements when planning software projects across the company.
Instrumental changes
The following key changes help make development and shipping cycles healthier and more efficient:
Promote cultural alignment and autonomy.
Change focus from individuals to teams.
Create new planning and learning strategies.
Implement a multi-crew model.
Improve code health practices.
Foster transparency and accountability.
Promote cultural alignment and autonomy
Peter Drucker said, "Culture eats strategy for breakfast." Autonomy, mastery, and purpose are key human motivations. Microsoft tries to provide these motivators to PMs, developers, and designers so they feel empowered to build successful products.
Two important contributors to this approach are alignment and autonomy.
Alignment comes from the top down, to ensure that individuals and teams understand how their responsibilities align with broader business goals.
Autonomy happens from the bottom up, to ensure that individuals and teams have an impact on day-to-day activities and decisions.
There is a delicate balance between alignment and autonomy. Too much alignment can create a negative culture where people perform only as they're told. Too much autonomy can cause a lack of structure or direction, inefficient decision-making, and poor planning.
Change focus from individuals to teams
Microsoft organizes people and teams into three groups: PM, design, and engineering.
PM defines what Microsoft builds, and why.
Design is responsible for designing what Microsoft builds.
Engineering builds the products and ensures their quality.
Microsoft teams have the following key characteristics:
Cross-disciplinary
10-12 people
Self-managing
Clear charter and goals for 12-18 months
Physical team rooms
Own feature deployment
Own features in production
Strive for vertical teams
Microsoft teams used to be horizontal, covering all UI, all data, or all APIs. Now, Microsoft strives for vertical teams. Teams own their areas of the product end-to-end. Strict guidelines in certain tiers ensure uniformity among teams across the product.
The following diagram conceptualizes the difference between horizontal and vertical teams:
Allow self-selecting teams
About every 18 months, Microsoft runs a "yellow sticky exercise," where developers can choose which areas of the product they want to work on for the next couple of planning periods. This exercise provides autonomy, as teams can choose what to work on, and organizational alignment, as it promotes balance among the teams. About 80% of the people in this exercise remain on their current teams, but they feel empowered because they had a choice.
Create new planning and learning strategies
Dwight Eisenhower said, "Plans are worthless, but planning is everything." Microsoft planning breaks down into the following structure:
Sprints (3 weeks)
Plans (3 sprints)
Seasons (6 months)
Strategies (12 months)
Engineers and teams are mostly responsible for sprints and plans. Leadership is primarily responsible for seasons and strategies.
The following diagram illustrates Microsoft planning strategy:
This planning structure also helps maximize learning while doing planning. Teams are able to get feedback, find out what customers want, and implement customer requests quickly and efficiently.
Implement a multi-crew model
Previous methods fostered an "interrupt culture" of bugs and live site incidents. Microsoft teams came up with their own way to provide focus and avoid distractions. Teams self-organize for each sprint into two distinct crews: Features (F-crew) and Customer (C-crew).
The F-crew works on committed features, and the C-crew deals with live site issues and interruptions. The team establishes a rotating cadence that lets members plan activities more easily. For more information about the multi-crew model, see Build productive, customer focused teams.
Improve code health practices
Before switching to Agile methodologies, teams used to let code bugs build up until code was complete at the end of the development phase. Teams then discovered bugs and worked on fixing them. This practice created a roller coaster of bugs, which affected team morale and productivity when teams had to work on bug fixes instead of implementing new features.
Teams now implement a bug cap, calculated by the formula # of engineers x 5 = bug cap. If a team's bug count exceeds the bug cap at the end of a sprint, they must stop working on new features and fix bugs until they are under their cap. Teams now pay down bug debt as they go.
Foster transparency and accountability
At the end of each sprint, every team sends a mail reporting what they've accomplished in the previous sprint, and what they plan to do in the next sprint.
Objectives and key results (OKRs)
Teams are most effective when they're clear on the goals the organization is trying to achieve. Microsoft provides clarity for teams through objectives and key results (OKRs).
Objectives define the goals to achieve. Objectives are significant, concrete, action oriented, and ideally inspirational statements of intent. Objectives represent big ideas, not actual numbers.
Key results define steps to achieve the objectives. Key results are quantifiable outcomes that evaluate progress and indicate success against objectives in a specific time period.
OKRs reflect the best possible results, not just the most probable results. Leaders try to be ambitious and not cautious. Pushing teams to pursue challenging key results drives acceleration against objectives and prioritizes work that moves towards larger goals.
Adopting an OKR framework can help teams perform better for the following reasons:
Every team is aligned on the plan.
Teams focus on achieving outcomes rather than completing activities.
Every team is accountable for efforts on a regular basis.
OKRs might exist at different levels of a product. For example, there can be top-level product OKRs, component-level OKRs, and team-level OKRs. Keeping OKRs aligned is relatively easy, especially if objectives are set top-down. Any conflicts that arise are valuable early indicators of organizational misalignment.
OKR example
Objective: Grow a strong and happy customer base.
Key results:
Increase external net promoter score (NPS) from 21 to 35.
Key results are only as useful as the metrics they're based on. Microsoft uses leading indicators that focus on change. Over time, these metrics build a working picture of product acceleration or deceleration. Microsoft often uses the following metrics:
Change in monthly growth rate of adoption
Change in performance
Change in time to learn
Change in frequency of incidents
Teams avoid metrics that don't accrue value toward objectives. While they may have certain uses, the following metrics aren't helpful for tracking progress toward objectives:
Accuracy of original estimates
Completed hours
Lines of code
Team capacity
Team burndown
Team velocity
Number of bugs found
Code coverage
Before Agile and after Agile
The following table summarizes the changes Microsoft development teams made as they adopted Agile practices.
Before
After
4-6 month milestones
3-week sprints
Horizontal teams
Vertical teams
Personal offices
Team rooms and remote work
Long planning cycles
Continual planning and learning
PM, Dev, and Test
PM, Design, and Engineering
Yearly customer engagement
Continual customer engagement
Feature branches
Everyone works in the main branch
20+ person teams
8-12 person teams
Secret roadmap
Publicly shared roadmap
Bug debt
Zero debt
100-page spec documents
PowerPoint specs
Private repositories
Open source or InnerSource
Deep organization hierarchy
Flattened organization hierarchy
Install numbers define success
User satisfaction defines success
Features ship once a year
Features ship every sprint
Key takeaways
Take Agile science seriously, but don't be overly prescriptive. Agile can become too strict. Let the Agile mindset and culture grow.
Celebrate results, not activity. Deploying functionality outweighs lines of code.
Ship at every sprint to establish a rhythm and cadence and find all the work that needs to be done.
Build the culture you want to get the behavior you're looking for.
This certification measures your ability to accomplish the following technical tasks: Design and implement processes and communications, design and implement a source control strategy, design and implement build and release pipelines, develop a security and compliance plan, and implement an instrumentation strategy.