Scaling Smart: When to Use (or Remove) Leadership Action Teams and Leadership MetaScrums

par Avi Schneier and Dee Rhoda | May 1, 2023 | Blog

Every business leader considering - or implementing - an Agile transformation must answer a difficult question; how much do you redesign your organizational structure? The answer here can seem as challenging as it is important. 

While maintaining some semblance of the current reporting and decision structure is easy, it is also a major pitfall. Especially if the existing structure includes excessive amounts of bureaucracy and oversight which inhibit business agility. This is often the case. 

Yet, redesigning the entire structure is a massively disruptive effort, akin to tearing down an entire building and reconstructing it from the ground up when all it really needed was a renovation.  

The goal should be a Bureaucratie minimale viable, which enables the fastest decision-making possible to gain and maintain a competitive advantage and is the north star for any organizational redesign. Anything more is a waste. Anything less is ineffective. 

With more than 20+ years of helping everything from startups to Fortune 100 companies realize business agility, we know how to find that balance. We know when to build supporting structures to accelerate an Agile implementation - and, more importantly - we know how to identify when those same supporting structures have become unnecessary. 

Organizational Hurdles

The most successful transformations start with leadership, but it isn’t always easy. These leaders gained their position and status by mastering the process now being replaced. That is a difficult proposition to grasp. 

The same is true for the organization itself. 

The difficulty of working beyond the constraints of the current structure is directly correlated to an organization's size and age. Older organizations tend to be more invested in traditional patterns of working. Larger organizations tend to be more reliant on management fiefdoms to operate. Combined, these compound the resistance to change. 

This is especially true when approaching topics as broad as fiduciary responsibility, process compliance, and impediment removal. 

The leading practice we derived is to provide upper management with supporting structures for decisions in these areas while the organization works to remove those constraints and the associated hierarchy. 

This can be accomplished by using a framework like Scrum@Scale and increasing the decision rights within the groups of teams doing the actual work.

Key Benefits of Scrum@Scale

Scrum@Scale is a powerful and effective framework for achieving business agility. It offers several key benefits for organizations undergoing continuous improvement or full-on Agile transformations. Here are some of the most important ones we’ve seen:

1. Scalability: Scrum@Scale provides a framework for scaling Agile practices across an entire organization, from small teams to entire value streams.
2. Transparency: Scrum@Scale promotes transparency at all levels of the organization, allowing teams to collaborate more effectively and make better decisions based on real-time data.
3. Flexibility: Scrum@Scale is highly flexible, allowing organizations to adapt their Agile practices to their specific needs and circumstances.
4. Faster Time-to-Market: By enabling faster decision-making and more efficient coordination between teams, Scrum@Scale helps organizations bring products to market more quickly.
5. Reduced Risk: Scrum@Scale provides a structured framework for managing risk, enabling organizations to identify and address potential problems before they become major issues.
6. Improved Quality: By promoting collaboration and transparency, Scrum@Scale helps teams identify and address quality issues more quickly, improving overall product quality.

However, there is a common misunderstanding about the Scrum@Scale framework that we frequently encounter. When Scrum@Scale Practitioners use the term "Scrum@Scale," people who are unfamiliar with it often assume that it refers exclusively to an organizational structure. The Scrum@Scale framework consists of 12 distinct components that are divided into two cycles. And so it has a dual use in conversation.

Scrum@Scale’s components are not physical, per se; rather, they are sets of questions each organization must answer to ensure a proper flow of information that yields the completed integrated work desired by customers. 

The Product Owner (PO) Cycle focuses on everything around deciding what a group of teams is going to make while the Scrum Master (SM) Cycle deals with everything around coordinating how they deliver it together.

 

Scrum@Scale and Organizational Design

In a Scrum@Scale organization, individual teams with a need to coordinate are grouped together into a Scrum of Scrums (SoS), wherein they pull work from a commonly shared backlog. These teams are supported by two complementary groups: a PO Team and a group of SMs. 

Just as a team’s PO curates the team’s backlog, we have a PO Team for curating the shared backlog with a Chief Product Owner (CPO) whose accountability is its overall order. That order, and the resulting issues around budget, staffing, and product viability, are decided at a MetaScrum (MS) by the PO Team in conjunction with relevant product stakeholders and leadership. Relevant stakeholders include not just people who desire work to be done by the teams, but also representatives from the SM organization so the considerations of staffing, necessary skills, training, and capacity can be taken into account. This creates the bridge between strategy and execution.

The group of SMs who support the SoS optimally meet daily at a Scaled Daily Scrum (SDS) to address impediments and dependencies in real-time. The SDS is facilitated by a Scrum of Scrums Master (SoSM), who is the counterpart of the CPO. Just as the SoSM attends the MS, a member of the PO Team should attend the SDS making that bridge between strategy and execution bi-directional. 

If the complexity of the product grows, and more teams are needed, SoSs can be added in an organic way growing into a Scrum of Scrum of Scrums (SoSoS) or even larger, into Scrum of Scrum of Scrum of Scrums (SoSoSoS) encompassing entire value streams. Here we would find multiple MS and multiple groups having SDSs. 

To facilitate cross-value stream coordination from an enterprise backlog perspective, we create an Executive MetaScrum (EMS). For coordinating the transformation itself and removing impediments and dependencies, we create an Executive Action Team (EAT). 

Scaffolding and Scaling

Let’s go back to that analogy of either renovating a structure or tearing it down to rebuild it from scratch. Many people compare an Agile Transformation to a ground-up approach. In reality, most transformations we’ve encountered are actually inside of already existing organizations - a renovation, not a total rebuild. 

Just as with construction, scaffolds are often needed during the work. These are temporary structures that enable phases of work but are removed when the work is complete.

In larger transformation efforts inside of traditional organizations, this normally requires the insertion of a middle layer of Leadership MetaScrums (LMS) and Leadership Action Teams (LAT) between the MS and EMS and SDS and EAT. 

The LMS and LATs provide a macroscopic view of what is going on in the individual MS & SDS to the EMS and EAT, and a microscopic view of what is going on in the EMS and EAT to the MS & SDS. 

This entire mechanism allows for coordinating the teams doing the work with the highest fidelity despite the added bureaucracy and hierarchy. LMS and LATs can also help accelerate the transformation by removing barriers to change. 

At a large company with over $1 billion in annual sales, we saw there was tremendous resistance to modifying the existing hierarchy. The only way managers and leadership would make room for a transformation was to preserve traditional reporting lines. Therefore, when we undertook the effort, we made care to respect the existing tiers while forming cross-functional teams so that they could work faster but no one felt their title nor their position was in jeopardy.

That company is now well down the path of business agility.

When larger and older companies transform, they sometimes need the support of LMS and LATs for both the PO and SM Cycles of the S@S framework to coordinate seamlessly. 

Over the last few years, we have seen faster and greater degrees of success when putting these supporting structures into place for some organizations to overcome the initial impediments to beginning their Agile transformation journey and establish real impediment removal paths and decision forums around backlogs. These structures should be temporary. 

Leadership MetaScrums and Leadership Action Teams: Needed or Not?

When organizations attempt to keep reporting structures and decision channels as close to what they once were, you’ll see LMS and LATs pop up everywhere without a clear understanding of their intent and purpose. 

There is a dysfunction in creating these to keep the hierarchy and bureaucracy that S@S works to remove in creating your MVB. The major issue they create is increasing decision latency (time to make a decision), which is a known driver of project failure and cost overrun (Chaos Report, 2020). Therefore, the introduction of these Leadership teams should be considered carefully. 

Sometimes there is just such a problem.

In a Fortune 50 Technology company, we were tasked with keeping strict ISO governance intact while creating an innovative Transformation Model to support it. This was solved with initially overlapping Leadership teams for both Product and Process. This enabled the organization to focus on where they could incorporate empowerment to reduce decision latency in the build/test arena while adhering to the constraining practices of compliance. Once completed, the goal became to refine their delivery approach to match the internal ISO compliance needs while reducing the overhead of their common stage gates.  

However, we do not promote their establishment unless there is a problem they solve.

Knowing When to Remove LMS and LATs

The decision to remove LMS and LATs needs to be made as carefully as the decision to implement them. 

The main purpose of LMS and LATs is to enhance the speed of decision-making and impediment removal. Therefore, if their removal would only increase decision latency, it’s not the right time. 

When the data shows that an LMS and LAT are actually slowing down decision-making and impediment removal, it's time to remove the scaffolding. At this point, the EMS and EAT must create and coordinate their backlogs (strategy and execution) to enable the teams within the SoS and their corresponding MS and SDS to pull those decisions into their purview. Once this is accomplished, the LMS and LAT can be disbanded and the individuals comprising them can focus their efforts elsewhere.

At one global manufacturer with over $16 billion in annual sales, multiple LMS and LATs were needed at the outset due to geographical considerations and political concerns. As these needs subsided due to better global collaboration, these forums unfortunately only increased decision latency. They became a new gated process requiring sign-offs not needed earlier in the transformation. This is a red flag. It signifies that it’s time for the removal of these supporting structures when they no longer meet their transformation goal and are now being misused for power plays. 

In Conclusion

We believe there can be an obvious purpose and place for these leadership teams. We caution that they should be created to solve specific organizational problems and reduce decision latency.. When the bureaucratic processes they create outweigh the value they provide, then it’s time to eliminate them. This is the “when” to remove the scaffold responsibly and increase business agility.

Therefore, a good strategy is to create the backlog items needed to eliminate them while creating the backlog items to construct them, which is why we compare them to a construction scaffold.

*This article was co-authored by Dee Rhoda, a Registered Scrum@Scale and Scrum trainer and fellow, and Scrum Inc.'s Avi Schneier.