Scaling into the program layer (part 2)

This is the second blog post in a series focusing on essential Agile practices that help you scale Agility through the three layers of an enterprise. If you missed the first one, you can read it here.

In this blog post, I’ll discuss the program layer, or “team of teams” layer, where work is organized and planned.

You will see how these key practices provide guidance and direction to the different teams and also begin to connect portfolio layer priorities to the execution of work being delivered.

Achieving closer alignment between portfolio management decision-making and the work teams deliver every sprint is at the core of why scaling Agility is so important.

Scaling through the program layer (team of teams)

Have a single, common backlog

One of the most important attributes that define a program team or team of teams is its backlog. 

Program teams should have only one common, agreed-upon backlog where all the work expected to be delivered is taken in and managed. This includes work being defined and prepared for planning along with what’s currently in progress.

Having work collected into a single program backlog provides several important benefits:

• It helps provide visibility for all work, no matter its status.
• It helps improve the timeframe from intake to the planning of work.
• It provides a single location for priority ranking and adjustments on an incremental basis.
• It can help align critical pieces of work to larger portfolio-driven initiatives and strategic objectives, providing relevance to the work teams are doing.

A common challenge with program backlogs is how to streamline the intake process that builds the backlog and balances it with portfolio-driven priorities. To ensure that the backlog doesn’t become a dumping ground for everything, you will need a filter system of sorts as part of the intake process.

This intake filter should allow for the portfolio communicated priorities to be broken down and planned alongside regular operations, product support, or tooling and process work that the teams are expected to undertake as part of their responsibilities.

Getting the balance for this right is an activity that takes place as part of the program cadence. The cyclical review of the balance provides a mechanism for making adjustments as and when required.

Program cadence and alignment to portfolio initiative forecasting

As with individual teams, having a regular program cadence is essential to scaling Agility.

The program team's cadence is often described as the heartbeat that drives the program and synchronizes the work across all teams. The cadence also provides a direct connection to the forecasted plans and priorities of the portfolio layer.

Some of the attributes that make the program cadence so important are listed below:

• It establishes clear timeframes for the program’s two tracks of ongoing work.

• • Execution of the planned work currently underway.
  • Preparation for the next upcoming increment.

• It allows for incremental work plans to be prepared and synchronized with the portfolio forecasts and funding models.
• It provides a regular cycle for the review of planned versus completed work to align the true capacity of the program team to the demand.
• It offers a temporal way to manage and coordinate dependent work between teams and other programs.
• It provides incremental opportunities to reflect upon outcomes, ways of working, planning, and overall delivery processes so changes can be made sooner.

Being able to plan effectively and synchronize work across all teams is how portfolio and operational priorities are balanced and aligned to business needs through the program layer as you scale.

Dependency management and visualization

Lack of dependency management and more importantly not having a means to visualize dependencies across teams is often a primary cause for delivery-related issues within programs. Getting a method in place to capture and manage them is critical for scaling Agility across teams.

Dependencies are simply complexities within the system of teams you have organized together. The more cross-dependencies there are between teams, the higher the chance of delay, frustration and reduced business value being delivered.

If you attempt to put a number on just how much time dependencies cost with respect to team productivity, that number alone can be motivating enough to make the case for establishing a method of managing them more urgent.

Below are some questions to ask as part of setting up a dependency management practice and visualizing them.

• How are they defined?

• • I would suggest any agreed-upon work needed by one team from another in order to complete a piece of work is a dependency.
  • One dependency between two teams only for each potential blocker.

• Where and when are they captured?

• • Ideally, as part of whatever incremental planning you are following and prior to the start of the increment.
  • I suggest dependencies be captured somewhere for all team members to review regularly and easily.

• Who is responsible for managing them? 

• • A form of ownership from within the dependent team and the team expected to deliver the dependent need is desirable. 

• • This should be assigned to a team role and potentially a program role for cross-program type dependencies.

Once you are able to capture, visualize, and track dependencies consistently, different issues in your system of teams may be more easily recognized. For example:

• Teams not having enough technical resources of a certain type.
• Overload of work expected from particular teams due to a concentration of core skills or as a pattern of behavior that has persisted over time.
• Too many non-program controllable pieces of work being defined and a lack of ability to influence non-program areas to align those efforts.

Dependencies will always be part of any IT delivery workflow and teams seeking to work with more Agility will always need a method to manage them effectively. This is why dependency management and visualization of them needs to be part of any scaling for the program team layer.

Connect work to investment themes and portfolio initiatives

When you connect work using parent-child relationships, it forms a backbone of sorts that supports your ability to scale through the different layers of the business in various ways.

The type of connection I’m referring to here will look something like this:

• Story (team) - Feature (program) - Initiative (portfolio).

                                            ….or….

• Story (team) - Feature (program) - Investment Theme (portfolio).

Parenting the smallest type of work item to a parental hierarchy has the benefit of communicating relevant information in several important ways.

1. It helps determine the timing for when forecasted work needs to be broken down and planned in the program layer and eventually for individual team sprints.
2. It provides a means to track the status of larger pieces of work based on whether incremental program planning is in alignment with portfolio and business expectations.
3. It creates a way to visualize how adjustments in planning or delivery outcomes will impact higher-level priorities and forecasting.
4. It can accurately convey whether the proper balance between initiatives and broader themes is represented proportionally.

The connection of smaller work items to their parents can also provide a means to track budget consumption for either portfolio initiatives or investment themes, particularly when work is differentiated by “run the business” and “grow the business” type themes.

Establishing good parent-child connections for work is not difficult. It’s really more a matter of habit. Expecting teams to do this as part of the work breakdown process and supporting the positive benefits of their doing so will help as you scale.

Scaling success from team to portfolio layers

Now, you may have some of these practices in place, or you may be in the process of just getting started with rolling them out across your different program areas. 

No matter where you are in your scaling journey, putting the effort into getting these cornerstones of program layer Agility in place will certainly provide you benefits.

They will help form a better structure of how the program team of teams operates and also put in place some foundational pieces that will support scaling upwards into the portfolio layer when you are ready.

So get busy!

• Organize your single backlog to achieve the right balance of work.
• Establish your program team cadence, not just around ceremonies but also to align with portfolio decision-making cycles.
• Get a firm hold on dependency management and focus on them aggressively.
• Finally, seek to build the connective structure of work from individual teams to higher level work initiatives.

Taken together, they all help communicate important information both up and down the layers of scale in your organization.

The final blog post in this series will cover the portfolio layer and explain how the practices we’ve discussed in the team and program layers connect to those that will help transform portfolios into more Agile ways of working.