Scaling Agile Framework is relevant when multiple teams must continuously integrate their work efforts to deliver customer value. The core challenge all frameworks must address is how they expose, manage, and resolve dependencies.

The dependency management mechanisms embedded in the design of these scaling frameworks directly impact the cost of change, making it easier or harder to change work products for better customer outcomes. Understanding dependency management mechanisms gives us structural insights to look beyond the facade.

Categorizing based on Governing/Enabling Constraints

A governing/enabling constraint is a rule or a code of conduct (expected behavior) that people agree to use and expect to be governed by so the collective benefits.

Using governing constraints gets us closer to the design intent of the Scaling Framework so that we can evaluate it on its judgment parameters. This is important because it helps us to filter out personal biases.

There are three distinct sets of Governing constraints.

(1) Empirical Goal-Based:

Increment quality, Time-box, Whole product focus 

Scaling frameworks that scale or extend the Scrum Framework fall into this category. We will evaluate Large Scale Scrum (LeSS) and Nexus in this category of Scaling Frameworks.

(2) Empirical Flow-Based:

WIP limits, Pull signals, and Explicit Policies.

This is not a Scaling Framework but principles from Lean Thinking and the Theory of Constraints (ToC) that can help multiple teams visualize and improve their workflows. It is better to call it a Scaling Approach or a Method rather than a framework. We will evaluate Integrated Kanban Boards in this category.

(3) Deterministic Plan-Based:

Scope, Budet, Date

These are Scaling frameworks that create big-upfront plans for managing dependencies. We will evaluate the Scaled Agile Framework (SAFe) in this category.

When the rubber meets the road.

Regardless of whether you are buying a toy car for your child or a people-sized vehicle for transportation. As a customer, you do not want to receive delivery of your car one part at a time. You would want the whole car.

In Scaled settings, multiple teams collaborate to deliver a service/product/project to the customer; the final deliverable must be cohesive. In other words, for all the teams involved, there is a single source of truth for the product so that they can deliver it to customers. 

The Agile Scaling Framework that, by design, supports and encourages the behavior of integrating continuously across teams is better at delivering an integrated product/service. This is because active and frequent management of dependencies leads to less frustration in continuously delivering value to customers. 

Empirical goal-based frameworks, LeSS and Nexus, are intentionally designed to support the behavior of continuous integration across teams because it requires all teams to have an integrated increment at the end of each Sprint.

Similarities

LeSS and Nexus maintain the same governing constraints at scale by having.

• Single Product Owner and Single Product Backlog for multiple Scrum teams.
• All Scrum teams synchronize to start and end sprint time box together.
• Single (Product) Increment at the end of Sprint.

Based on the Scrum Framework, Nexus and LeSS use different dependency management structures.

Differences in dependency management structures

Nexus

Nexus uses the construct of the Nexus Integration Team. The single Product Owner is a member of the Nexus Integration Team, and members of the Nexus Integration Team have first and foremost accountability to ensure that an integrated increment is produced at least once a sprint. They offer mentorship and assistance with task completion to other Scrum teams.

A key distinguishing aspect of Nexus’s way of scaling is to have named individuals be members of the Nexus Integration Team who provide a focal point for integration. This is likely to be a top-down assignment of accountability. The Nexus Integration team membership may change over time depending on situational challenges. The focal Nexus Integration team helps scrum teams adopt tools and practices that contribute to their ability to deliver useful integrated increments. (1)

LeSS

In contrast, LeSS does not have a separate Integration team construct. LeSS values decentralized, self-organized coordination and integration. The LeSS principle of Whole Product Focus requires everyone involved to actively take ownership of developing an integrated increment at least once every sprint.

LeSS encourages emergent groupings of people across Scrum team boundaries at all times and emphasizes the use of integration practices such as “leading team,” “communicate in code,” “just talk,” etc., for situational handling of dependencies.

The more decentralized approach in LeSS reduces dependency on key personnel to manage integration responsibilities. LeSS does not disallow the formation of a named integration team membership or the team members who mentor others on technology components and or guide adoption of agile practices.

Impact on cost of change

In the long run, LeSS fairs better at minimizing the overall cost of change to products/services. This is because dependency management is always a shared responsibility. The enterprise management cannot fix “blame” on a small group of integration team members. This focuses management accountability on improving systems (tools, policies, code management practices) for developing products/services at Scale.

In dysfunctional organizations, the Nexus Integration Team may get blamed, or the political ‘cop-out’ may be to conclude that we did not have the right people involved. The overall responsiveness to changing needs can experience bottlenecks with the Nexus Integration Team’s ability to integrate output or respond in a timely manner when many scrum teams involved.

Another factor that impacts the overall cost of change is the learning potential for Scrum team members.

LeSS encourages any Scrum team member to take on challenging integration tasks and grow their competency. In Nexus, the Nexus Integration Team is accountable; therefore, it gets first rights to work on integration problems.

Fit-for-purpose

LeSS adoptions are multi-year journeys that begin with C-Level buy-in and commitment to transform for the long haul. It has the most potential for growing a learning organization that can continue to inspect and adapt at scale.

Nexus aims to extend the Scrum framework minimally and recommends additional practices that support Scaling Scrum. Enterprises that frequently employ intermittent vendor teams to develop sub-systems or components of the overall product can benefit from a designated Nexus Integration Team with experienced staff. This will allow the enterprise to engage and disengage with vendor teams for specialized work. In theory, the enterprise has developed internal capability in the Nexus Integration Team to make future integration changes independent of disengaged vendor teams.

If developing products/services at scale is your enterprise’s purpose, then Nexus or LeSS are great starting points. And I think Nexus can be a good incremental step before committing to adopt LeSS fully.

What about Scrum @ Scale?

The Scrum@Scale Guide states,

“In order to begin implementing Scrum@Scale, it is essential to be familiar with the Agile Manifesto and the 2020 Scrum Guide.”

Primary mechanisms in Scrum@Scale are based on replicating Scrum framework events, roles, and artifacts of the single Scrum team for the Scrum of Scrum (SoS) team. This means that 5 Scrum Teams, with 1 SoS team, will have One “common backlog” with One Chief Product Owner for the SoS and Product Owners for each Scrum Team.

“Each team’s Product Owner is accountable for the composition and prioritization of their team’s Sprint backlog.”

This structure contradicts the Scrum Guide 2020 statement.

“If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”

Similarly, many other contradictions make it difficult to tell how dependencies are managed.

Scrum@Scale uses ”Scrum of Scrums” and “Scrum of Scrum of Scrums” to develop an integrated product each sprint, and the SoS operates.

“as if it were a Scrum team, with scaled versions of Scrum accountabilities, events, and artifacts.”

This approach to scaling seems to increase the number of hierarchical hops to escalate up and down the chain of related artifacts, events, and accountabilities. 

While the Scrum@Scale guide claims that it is designed to minimize “decision latency,” its reliance on SoS and SoSoS and centralization of more critical concerns up the hierarchy chain is no different than the telephone game that multi-layered managerial hierarchies play. 

My gut call – It’s turtles all the way down! It starts innocent but is likely to run out of control with layers of events, artifacts, and accountabilities. Scrum is everywhere and for everyone.

Build your own

Build collaborative and trust-based (agile) interactions where feasible.

Empirical Flow-Based approaches start with visualization of the end-to-end flow of work through state changes and then pursue continuous incremental, evolutionary change to build agile interactions where feasible.

For example, a requirement or opportunity moves from Discovery to Develop to Delivered/Monitoring states.

First, visualize the flow of work items on the task board so everyone involved understands the end-to-end workflow. Then, collaboratively make targeted incremental improvements to utilize constraints through appropriate WIP limits and Explicit Policies.

Compared to Empirical Goal-Based systems, no defined time-boxes exist when new work items are selected. Each work item is started whenever capacity frees up for the first team and makes ‘ready for’ the next-in-line team downstream, who then pulls to get it ‘ready for’ the next-in-line team, until the work item in finished state is ready for pull by the customer who is at the end of the value chain.

In well-functioning flow systems, downstream and upstream teams frequently review empirically derived flow measures and manage improvements and stakeholder expectations.

Integrated Kanban Boards

Empirical flow-based systems can be utilized at team, operational, and strategic levels for large enterprises or compressed into a single flow where work items move from Discovery to Delivery on a single board for a small or mid-sized product company.

In large enterprises, there are multiple streams of work.

For example, your team that services application support tickets is also involved in project work with other teams. This means different stakeholders and multiple project streams utilize your team’s capacity.

A novice mistake is to create various Kanban (task) boards for the team to pull work from. Since team capacity is constrained, the right thing to do is to build a team Kanban board that is the sole source of work items to pull from.

Integrated project/program Kanban boards are then built as higher-level boards. This helps to visualize the flow of work across multiple agile teams involved in the large program. Integrated Kanban board items are then linked to dependent sub-work items in the team-level Kanban board.

The ongoing prioritization challenges between immediate support requests and program deliverables timeline require continuous collaboration between the coordinators/managers of teams and program/project managers so the agile team can focus on utilizing its limited capacity for doing the work instead of navigating organizational politics. The norms for continuous collaboration are expressed as explicit policies that can govern the overall workflow.

Fit for purpose

End-to-end flow metrics are easy to measure, mean something, and can direct specific, measurable improvements. This approach removes ambiguity from coordination linkages between teams and opens up possibilities to flip coordination problems into collaborative problem-solving opportunities.

This approach for Scaling Agile is practical for enterprises with established workflows that are primarily fixed and not open to revolutionary change.

Tell us what to do – is it safe?

Large enterprises that have established silos for project management, requirements, architecture, development, and testing operate under deterministic plan-based governance controls. Project organizations evaluate progress by tracking variances against targeted scope, budget, and date.

Rather than take on the challenging journey of de-scaling and removing waste from their organization systems and practices, some organizations double down on bureaucratic complications and adopt the Scaled Agile Framework (SAFe).

The Scaled Agile Framework (SAFe)

This bureaucratic labyrinth is a behemoth that cannot be called a framework, let alone an agile one.

Lets limit our focus on dependency management approach for delivery. Let me explain briefly using SAFe terminology first:

The objective of SAFe is to develop a Solution by an Agile Release Train (ART) that aligns with stakeholders through quarterly PI Planning events, where each Agile team within the ART identifies risks and dependencies. These are then mapped on the ART Planning Board.

If your head is spinning with all the jargon in the paragraph above, your BS filter works. Now, let me explain it free from jargon.

Many teams, say 50-150 people, get together for a two-day planning event. They create a plan of work to be completed for the next 2 or 3 months. Each team commits to its objectives and the shared ”PI objectives” that apply to all the teams. Teams then identify dependencies on each other and adjust plans in the two days of planning so team backlog items for six two-week sprints can be provisionally scheduled for each team. 

The plan for the next three months is created based on talking about the work they will do. Teams use historic velocity to make an upfront plan for six iterations. This was never the intended use of velocity, but like everything else, SAFe manages to twist agile practices to suit deterministic plan-based pursuits.

Each team involved with the delivery of work has stakeholders who expect them to meet its commitments and another set of stakeholders who expect them to meet shared commitments with other teams. This is no different than a big batch of project requirements that get tossed to developers. Progress is then tracked against a plan that is created upfront.

What happens if a team experiences delays in completing its work? How does it impact other teams who are dependent on the team? Who will go back to the stakeholders and reset their expectations? 

These are the same problems that silo-ed Large enterprises already have, and they traded the old terminology of projects and relabeled these as Epics to end up in the same place as before.

Conclusion

Agility at scale requires a change in thinking and leadership courage to challenge assumptions so the resulting organizational structure is set up to learn and adapt faster. This is not easy, but it is doable. Re-labeling deterministic plan-based practices to agile terminology will not cut it. You must be prepared to descale, eliminate wasteful practices, and adopt collaborative practices for integrated problem-solving at all levels.

With our Certified Agile Skills – Scaling 1 workshop, we will guide your learning to discover proven journeys (trails) that have helped organizations to succeed safely with scaling agility. Join us for an upcoming workshop to learn and prepare your action plan to grow a learning organization for knowledge workers.

(1) Thanks to Venkatesh Rajamani (CST, PST) for clarifying the fluid membership of the Nexus Integration team.