Scaling Agile to large teams

The words big and Agile aren't often used in the same sentence. Large organizations have earned the reputation of being slow moving. However, that's changing. Many large software organizations are successfully making the transformation to Agile. They're learning to scale Agile principles with or without popular frameworks such as SAFe, LeSS, or Nexus.

At Microsoft, one such organization uses Agile to build products and services shipped under the Azure DevOps brand. This group has 35 feature teams that release to production every three weeks.

Every team within Azure DevOps owns features from start to finish and beyond. They own customer relationships. They manage their own product backlog. They write and check code into the production branch. Every three weeks, the production branch is deployed and the release becomes public. The teams then monitor system health and fix live-site issues.

According to Agile principles, autonomous teams are more productive. An Agile organization wants their teams to have control over their day-to-day execution. But autonomy without alignment would result in chaos. Dozens of teams working independently wouldn't produce a unified, high-quality product. Alignment gives teams their purpose and ensures that they meet organizational goals. Without alignment, even the best performing teams would fail.

To scale Agile, you must enable autonomy for the team while ensuring alignment with the organization.

To manage the delicate balance between alignment and autonomy, DevOps leaders need to define a taxonomy, define a planning process, and use feature chats.

Define a taxonomy

An Agile team, and the larger Agile organization it belongs to, need a clearly defined backlog to be successful. Teams will struggle to succeed if organizational goals are unclear.

In order to set clear goals and state how each team contributes to them, the organization needs to define a taxonomy. A clearly defined taxonomy creates the nomenclature for an organization.

A common taxonomy is epics, features, stories, and tasks.

Epics

Epics describe initiatives important to the organization's success. Epics may take several teams and several sprints to accomplish, but they aren't without an end. Epics have a clearly defined goal. Once attained, the epic is closed. The number of epics in progress should be manageable in order to keep the organization focused. Epics are broken down into features.

Features

Features define new functionality required to realize an epic's goal. Features are the release-unit; they represent what is released to the customer. Published release notes can be built based on the list of features recently completed. Features can take multiple sprints to complete, but should be sized to ensure a consistent flow of value to the customer. Features are broken down into stories.

Stories

Stories define incremental value the team must deliver to create a feature. The team breaks the feature down into incremental pieces. A single completed story may not provide meaningful value to the customer. However, a completed story represents production-quality software. Stories are the team's work unit. The team defines the stories required to complete a feature. Stories optionally break down into tasks.

Tasks

Tasks define the work required to complete a story.

Initiatives

This taxonomy isn't a one-size-fits-all system. Many organizations introduce a level above epics called initiatives.

The names of each level can be tailored to your organization. However, the names defined above (epics, features, stories) are widely used in the industry.

Line of autonomy

Once a taxonomy is set, the organization needs to draw a line of autonomy. The line of autonomy is the point at which ownership of the level passes from management to the team. Management doesn't interfere with levels that are owned by the team.

The following example shows the line of autonomy drawn below features. Management owns epics and features, which provide alignment. Teams own stories and tasks, and have autonomy over how they execute.

In this example, management doesn't tell the team how to decompose stories, plan sprints, or execute work.

The team, however, must ensure their execution aligns with management's goals. While a team owns their backlog of stories, they must align their backlog with the features assigned to them.

Planning

To scale Agile planning, a team needs a plan for each level of the taxonomy. However, it's important to iterate and update the plan. This process is called rolling wave planning.

The plan provides direction for a fixed period of time with expected calibration at regular intervals. For example, an 18-month plan could be calibrated every six months.

Here's an example of planning methods for each level of a taxonomy: epics, features, stories, tasks.

Vision

The vision is expressed through epics and sets the long-term direction of the organization. Epics define what the organization wants to complete in the next 18 months. Management owns the plan and calibrates it every six months.

The vision is presented at an all-hands meeting. As the vision is intended to be ambitious and a lot can change over that period of time, expect to accomplish about 60% of the vision.

Season

A season is described through features and sets the strategy for the next six months. Features determine what the organization wants to light up for its customers. Management owns the seasonal plan and presents the vision and seasonal plans at an all-hands meeting. All team plans must align with management's seasonal plan. Expect to accomplish about 80% of the seasonal plan.

3-sprint plan

The 3-sprint plan defines the stories and features the team will finish over the next three sprints. The team owns the plan and calibrates it every sprint. Each team presents their plan to management via the feature chat (see below). The plan specifies how the team's execution aligns with the 6-month seasonal plan. Expect to accomplish about 90% of the 3-sprint plan.

Sprint plan

The sprint plan defines the stories and features the team will finish in the next sprint. The team owns the sprint plan and emails it to the entire organization for full transparency. The plan includes what the team accomplished in the past sprint and their focus for the next sprint. Expect to accomplish about 95% of the sprint plan.

Line of autonomy

In this example, the line of autonomy is drawn to show where teams have planning autonomy.

As stated above, management doesn't extend ownership below the line of autonomy. Management provides guidance using the vision and season plans, and then gives the teams autonomy to create 3-sprint and sprint plans.

Feature chats: Where autonomy meets alignment

A feature chat is a low-ceremony meeting where each team presents their 3-sprint plan to management. This meeting ensures that team plans align with organizational goals. It also helps management stay informed about what the team is doing. While the 3-sprint plan is calibrated every sprint, feature chats are held as-needed, usually every one-to-three sprints.

A feature chat meeting allocates 15 minutes to each team. With 12 feature teams, these meetings can be scheduled to last about three hours. Each team prepares a 3-slide deck, with the following slides:

Features

The first slide outlines the features that the team will light up in the next three sprints.

Debt

The next slide describes how the team manages technical debt. Debt is anything that doesn't meet management's quality bars. The director of engineering sets the quality bars, which are the same for all teams (alignment). Example quality bars include number of bugs per engineer, percentage of unit tests passing, and performance goals.

Issues and dependencies

The issues and dependencies listed on the final slide include anything that impacts team progress, such as issues the team can't resolve or dependencies on other teams that need escalation.

Each team presents their slides directly to management. The team presents how their 3-sprint plan aligns with the 6-month seasonal plan. Leadership asks clarifying questions and suggests changes in direction. They can also request follow-up meetings to resolve deeper issues.

If a team's plan fails to align with management's expectations, management may request a re-plan. In this rare event, the team will re-plan and schedule a second feature chat to review it.

Trust: The glue that holds alignment and autonomy together

When practicing Agile at scale, trust is a two-way street:

• Management must trust teams to do the right thing. If management doesn't trust the teams, they won't give teams autonomy.

• A team earns trust by consistently delivering high-quality code. If teams aren't trustworthy, management won't give them autonomy.

Management must provide clear plans for teams to align with and then trust their teams to execute. Teams must align their plans with the organization and execute in a trustworthy manner.

As organizations look to scale Agile to larger scenarios, the key is to give teams autonomy while ensuring they're aligned with organizational goals. The critical building blocks are clearly defined ownership and a culture of trust. Once an organization has this foundation in place, they'll find that Agile can scale very well.

Next steps

There are many ways for a team of any size to start seeing benefits today. Check out some of these practices that scale.

Learn about Azure DevOps features for portfolio management and visibility across teams.

Microsoft is one of the world's largest Agile companies. Learn more about how Microsoft scales DevOps planning.