Scaling Agile to large teams
Many people wouldn't use the words big and Agile in the same sentence. Large software organizations have earned the reputation of being big and slow to change. However, that is changing. Many large organizations are successfully making the transformation to Agile. They are learning to scale Agile principles with our without popular frameworks such as SAFe, LeSS, or Nexus.
One such group, the Azure DevOps organization at Microsoft, builds the products and services shipped under the Azure DevOps brand. They have 35 feature teams that release to production every three weeks.
Every team within Azure DevOps owns everything 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 autonomy over their day-to-day execution. But autonomy without alignment would result in chaos. Dozens of teams working independently would not produce a unified, high-quality product. Alignment gives teams their purpose. Alignment ensures the teams 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.
Defining a taxonomy
A clearly defined taxonomy defines the nomenclature for an organization.
An Agile team needs clearly defined backlog to be successful. So does the larger Agile organization it belongs to. Teams will struggle to succeed if the organizational goals are unclear.
An Agile organization needs to clearly define its goals and state how each team needs to contribute to those goals. To accomplish this, the organization needs to define a taxonomy.
A common taxonomy is epics, features, stories, and tasks.
Epics declare initiatives important to the organization's success. Epics may take several teams and several sprints to accomplish, but they are not 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 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 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 breakdown into tasks.
Tasks define the work required to complete a story.
This taxonomy is not a one-size-fits-all. 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 fairly close to being industry standard.
Line of Autonomy
Once a taxonomy is set, define the Line of Autonomy. The Line of Autonomy is the point at which the team is the clear owner and management doesn't interfere.
The example below has drawn the Line of Autonomy below features. Management owns epics and features, which provide alignment. Teams own stories and tasks and have autonomy on how they execute.
Management doesn't extend ownership below the Line of Autonomy. For example, management doesn't tell the team how to decompose stories, plan their sprint, or execute their 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.
To scale Agile planning, a team needs a plan for each level of the taxonomy. Rolling wave planning is key. 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 6 months.
Here is an example of planning methods for each level of a taxonomy: epics, features, stories, tasks.
The vision is expressed through epics and sets the long-term direction of the organization. Management owns the plan and calibrates it every 6 months. Epics define what the organization wants to complete in the next 18 months. The vision is presented at an all-hands meeting. As the vision is intended to be ambitious and a lot can change for an Agile organization over that period of time, expect to accomplish about 60% of the vision.
A season is described through features and sets the strategy for the next 6 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.
The 3-sprint plan defines the stories and features the team will finish over the next 3 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.
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
The Line of Autonomy is drawn to show where teams have planning autonomy. The above planning process draws the Line of Autonomy as follows:
As stated above, management doesn't extend ownership below the Line of Autonomy. They provide guidance using the vision and season plans and give 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 team plans align with the organizational goals. It also helps management stays informed on what the team is doing. While the 3-sprint plan is calibrated every sprint, feature chats are held as-needed, usually every 1-3 sprints.
A feature chat meeting allocates 15 minutes to each team. With twelve feature teams, these meetings can be scheduled in about three hours. Each team prepares a 3-slide deck, with the following slides:
The features the team will light up in the next 3 sprints.
How the team is managing their 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 # bugs/engineer, % unit tests passing, and performance goals.
Anything that impacts the team's progress. 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 it 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 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 are 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 will find that Agile can scale very well.
There are many ways for a team of any size to start seeing benefits today. Check out some of these practices that scale.
Microsoft is one of the world's largest Agile companies. Learn more about how Microsoft scales DevOps planning.