Scaling Agile and Organizational Transformation

Introduction and Context

Agile methods were originally designed for small, closely collaborating teams. Modern digital products, however, may involve hundreds of specialists distributed across countries, suppliers, platforms, and regulatory environments. A single product can require coordinated work in software engineering, user experience, cybersecurity, data, operations, legal compliance, and customer support. Scaling Agile is therefore not simply the multiplication of Scrum teams. It is the design of organizational structures, integration mechanisms, decision rights, technical practices, and leadership behaviours that preserve empirical learning while coordinating interdependent work.

Scaling also creates a strategic problem. Team-level agility is valuable only when teams are solving the right problems, delivering an integrated product, and learning from real users. Organizational transformation consequently involves more than adopting a framework. It may require changes to funding, governance, performance management, architecture, procurement, career structures, and organizational culture.

This chapter evaluates four influential approaches—Nexus, Large-Scale Scrum (LeSS), Scrum@Scale, and the Scaled Agile Framework (SAFe)—and examines their use in transformation, portfolio alignment, leadership, distributed work, and resistance to change.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Explain why multi-team coordination creates scaling challenges.
2. Compare Nexus, LeSS, Scrum@Scale, and SAFe in terms of structure, governance, and appropriate use.
3. Design mechanisms for cross-team planning, integration, dependency management, and product alignment.
4. Analyse the relationship between Agile transformation, leadership, culture, and organizational design.
5. Evaluate distributed-team practices, resistance to change, and ethical or governance risks.
6. Select meaningful measures for assessing flow, quality, value, and learning without encouraging dysfunctional behaviour.

Why Agile Becomes Difficult at Scale

A Scrum Team can often communicate through direct conversation and integrate its work continuously. As the number of teams increases, several coordination problems become more likely:

• Dependencies: one team cannot complete work until another team provides an interface, service, decision, or component.
• Integration risk: separately developed increments may work in isolation but fail when combined.
• Competing priorities: teams may optimise local backlogs rather than a shared product outcome.
• Architectural fragmentation: independent decisions can create incompatible designs and technical debt.
• Decision latency: approvals and escalation paths become slower as hierarchy expands.
• Inconsistent quality: teams may interpret “Done” differently.
• Loss of customer feedback: layers of management can separate developers from users.
• Coordination overhead: meetings and reporting can consume the capacity intended for delivery.

A useful distinction is between scale of delivery and scale of complexity. A large number of people does not automatically require a large framework. Conversely, a small number of teams working on a tightly coupled, safety-critical product may require substantial coordination. The appropriate response depends on product architecture, regulatory obligations, dependencies, team autonomy, and the cost of failure.

Coordination and Flow

Agile organizations should seek fast, reliable movement of valuable work from idea to usable outcome. Little’s Law provides a useful conceptual relationship for a stable system:

Here, L is the average work in progress (items), λ is the average throughput (items per unit of time), and W is the average time an item spends in the system (the same time unit). The relationship assumes a sufficiently stable system over the period measured: items entering and leaving are broadly balanced, and averages are meaningful. It is not a promise that reducing work in progress alone will increase throughput; bottlenecks, quality, and variability also matter. The equation shows why excessive parallel work tends to increase waiting time when throughput is constrained.

At scale, coordination should reduce uncertainty and integration risk rather than create a second bureaucracy. A dependency board, for example, is useful only if it helps teams remove dependencies or redesign the work so that dependencies become less frequent.

Principles for Multi-Team Coordination

Several principles apply regardless of the framework selected.

One Product Goal and One Product View

Teams need a shared understanding of the product, users, desired outcomes, and constraints. Multiple teams may maintain individual backlogs, but prioritisation should reflect a coherent product strategy. A product goal is stronger than a list of projects because it describes the improvement sought for users or the business.

Integrated Increments

The primary integration mechanism should be technical and continuous wherever feasible. Teams should integrate code frequently, use automated tests, maintain compatible interfaces, and demonstrate a product increment rather than isolated component completion. A large integration event at the end of a release is a warning sign, not a substitute for continuous integration.

Explicit Quality Standards

A shared Definition of Done should address coding, testing, security, accessibility, documentation, data protection, and deployability as appropriate. Teams may add stricter local criteria, but they should not weaken the product-wide standard.

Appropriate Decentralisation

Decisions should be made by the people with the best relevant information, while strategic boundaries remain clear. Centralised decisions are justified when consistency, safety, legal compliance, or economies of scale are important. Unnecessary centralisation creates queues and reduces ownership.

Fast Feedback Across Boundaries

Customer research, operational telemetry, product analytics, technical reviews, and retrospectives should inform subsequent decisions. At scale, feedback must travel across teams and organizational layers, not remain within isolated ceremonies.

Four Scaling Approaches

The frameworks below are not interchangeable products. Each expresses different assumptions about autonomy, coordination, and organizational design. Their official guidance changes over time; organisations should consult current versions and treat implementation as context-dependent.

Nexus

Nexus is an extension of Scrum intended to coordinate approximately three to nine Scrum Teams working on a single product. Its central concern is reducing cross-team dependencies and ensuring that an integrated increment is produced.

A Nexus includes a Nexus Integration Team, which supports integration, identifies systemic issues, and helps establish practices that enable teams to integrate continuously. It does not become a permanent technical team that integrates everyone’s work on their behalf. The Nexus also adds coordination events, including a Nexus Sprint Planning process, a Nexus Daily Scrum, a Nexus Sprint Review, and a Nexus Sprint Retrospective structure. Teams continue to conduct their own Scrum events where necessary.

Strengths: relatively light extension of Scrum; strong emphasis on integration; useful for a single product with a modest number of teams.

Limitations: it does not provide a complete enterprise portfolio or budgeting model; its effectiveness depends on genuine technical integration and product ownership; organisations may misunderstand the integration team as a separate testing department.

Large-Scale Scrum (LeSS)

LeSS scales Scrum while attempting to preserve simplicity and reduce specialist coordination layers. Its basic form applies to two to eight teams, while LeSS Huge supports a larger product group through requirement areas and additional coordination structures. A key principle is one Product Backlog, one Product Owner, one Definition of Done, and one potentially shippable product increment.

LeSS encourages feature teams that can deliver customer-valued outcomes across the product rather than component teams that hand work from one specialist group to another. It also challenges organisational structures that create functional silos, advocating fewer roles, fewer additional meetings, and more direct interaction with users.

Strengths: clear product focus; reduced bureaucracy; strong encouragement of organisational redesign and feature teams.

Limitations: difficult where teams are deeply component-specialised, products are highly regulated, or management expects extensive separate reporting; transition can expose uncomfortable structural and political problems.

Scrum@Scale

Scrum@Scale describes a modular network of Scrum teams and “Scrum of Scrums” coordination. It distinguishes a Scrum Master Cycle, concerned with how teams coordinate and improve their delivery system, from a Product Owner Cycle, concerned with product discovery, prioritisation, and value. These cycles connect through an executive-level or organisational alignment mechanism.

The approach is intended to scale by composing networks rather than prescribing one fixed organisational design. A Scrum of Scrums can coordinate representatives from teams, while a MetaScrum can coordinate product owners and stakeholders. The exact design should reflect the organisation’s scale and complexity.

Strengths: modularity; explicit separation of delivery coordination and product prioritisation; compatibility with gradual expansion.

Limitations: “Scrum of Scrums” can become a status-reporting meeting rather than a problem-solving forum; the model may be implemented superficially without changing incentives, architecture, or product decision-making.

Scaled Agile Framework (SAFe)

SAFe provides a more extensive operating model with levels and roles for team, program, large solution, and portfolio work. Its concepts include Agile Release Trains, Program Increments, value streams, Lean Portfolio Management, architectural coordination, and portfolio strategy. Exact configurations vary, and organisations should avoid treating every element as mandatory.

SAFe can be attractive to large enterprises because it supplies common language, planning cadences, role descriptions, governance practices, and training pathways. It can help coordinate complex products involving many teams, suppliers, compliance obligations, and investment decisions.

Strengths: broad coverage from teams to portfolio; useful for organisations needing explicit governance and large-scale planning; provides mechanisms for budgeting and strategic alignment.

Limitations: extensive roles and events can reproduce hierarchy and bureaucracy; fixed planning increments may encourage batch delivery; organisations may claim to be Agile while retaining annual project funding, command-and-control decisions, and output-based performance measures.

Comparative Evaluation

The appropriate choice should follow the problem. If the main issue is technical integration among a small number of teams, Nexus may be sufficient. If the organisation is willing to redesign around a single product, LeSS may be more coherent. If networks of teams need flexible coordination, Scrum@Scale may be useful. If portfolio governance and regulatory coordination dominate, SAFe may offer relevant mechanisms—but only if its controls support learning rather than merely documenting plans.

Agile Transformation as Organizational Change

An Agile transformation is a sustained change in how an organisation creates and governs value. It is not equivalent to training people in Scrum terminology or appointing Agile coaches. Transformation commonly affects five connected dimensions:

1. Strategy: outcomes, customer segments, product goals, and investment choices.
2. Structure: product-aligned teams, reporting lines, communities of practice, and supplier relationships.
3. Process: discovery, prioritisation, development, deployment, governance, and learning loops.
4. Technology: architecture, automation, observability, security, and platform capabilities.
5. Culture: trust, transparency, experimentation, accountability, and attitudes toward failure.

A useful transformation sequence is diagnostic rather than prescriptive:

• Establish the problem through evidence, such as long lead times, escaped defects, delayed decisions, or low customer adoption.
• Define a measurable outcome rather than declaring a framework rollout as the goal.
• Start with a representative product or value stream and create conditions for learning.
• Remove structural impediments, not merely coach teams to work around them.
• Expand patterns that demonstrate value while stopping practices that create overhead.
• Review the transformation itself through regular leadership and team retrospectives.

Transformation should be treated as an adaptive change programme. Leaders cannot specify every future solution in advance because the organisation is learning about its own constraints.

Portfolio Alignment and Funding

Portfolio alignment connects strategic intent with product decisions and delivery capacity. Traditional project portfolios often approve temporary projects, allocate annual budgets, and judge success by scope, schedule, and expenditure. This can encourage teams to deliver outputs even when evidence shows that the intended outcome is no longer valuable.

An Agile portfolio instead tends to:

• fund persistent products or value streams where possible;
• express strategy as a small number of outcome-oriented themes;
• use lightweight investment horizons and explicit economic assumptions;
• empower product leaders to reorder work as evidence changes;
• review outcomes, risks, and learning rather than only plan conformance;
• maintain governance for security, privacy, accessibility, safety, and legal obligations.

Portfolio agility does not mean unlimited autonomy or the absence of controls. It means that controls are designed around risk and value. For example, a high-risk medical feature may require formal verification, traceability, and approval, while a low-risk interface experiment may be governed through automated testing and controlled release.

Useful portfolio measures include time from validated idea to customer use, outcome achievement, product quality, operational reliability, and the proportion of capacity devoted to strategic themes. These measures should be interpreted together. A short delivery time with poor reliability is not genuine performance.

Leadership and Culture

Agile leadership is often misunderstood as being passive or allowing teams to do anything they wish. Effective leaders provide direction, boundaries, resources, and rapid removal of systemic obstacles while avoiding unnecessary control over implementation details.

Important leadership behaviours include:

• articulating a clear product and organisational purpose;
• making priorities visible and limiting conflicting initiatives;
• rewarding learning, collaboration, quality, and customer outcomes;
• modelling transparency about uncertainty and failure;
• developing technical and product competence;
• protecting people who raise quality, safety, or ethical concerns;
• changing policies that contradict Agile principles.

Culture is not an abstract mood separate from systems. If managers say that experimentation is encouraged but punish every failed experiment, the actual culture is risk avoidance. If teams are told to collaborate but are ranked against one another using local utilisation, competition is likely to result.

Psychological safety is particularly important. Team members must be able to report defects, challenge assumptions, and discuss unrealistic commitments without fear of humiliation or retaliation. Psychological safety does not remove accountability; it makes accurate information more likely to surface so that accountability can be directed toward improvement.

Distributed and Hybrid Agile Teams

Distributed teams can be effective, but distance increases the need for deliberate communication design. Relevant dimensions include time zones, language, cultural expectations, internet reliability, employment arrangements, and access to environments or equipment.

Recommended practices include:

• maintain a shared digital workspace for decisions, requirements, diagrams, and working agreements;
• document important decisions with context, alternatives, and owners;
• establish predictable overlap hours while protecting local working time;
• use asynchronous updates for routine information and synchronous meetings for ambiguity, conflict, and collaborative design;
• rotate inconvenient meeting times across locations;
• use remote-friendly facilitation even when some participants are co-located;
• invest in automated build, test, deployment, monitoring, and environment provisioning;
• meet periodically in person when relationship formation or complex design warrants it, while avoiding exclusion of remote colleagues.

Distributed work also raises privacy and surveillance concerns. Monitoring keyboard activity or webcam presence is a poor substitute for evaluating outcomes and may damage trust. Organisations should collect only necessary data, explain its purpose, restrict access, and comply with applicable employment and privacy law.

Resistance to Change

Resistance is not always irrational obstruction. It may signal legitimate concerns about job security, workload, loss of expertise, poor sequencing, previous failed initiatives, or unclear decision rights. A productive analysis distinguishes:

• cognitive resistance: disagreement with the proposed logic;
• emotional resistance: fear, loss, or distrust;
• structural resistance: incentives, policies, reporting lines, or technology that make the new behaviour difficult;
• political resistance: perceived loss of authority, budget, or status.

Leaders should listen before labelling. A practical response includes transparent reasons for change, participation in design, realistic training, protected experimentation time, visible removal of impediments, and fair treatment of roles affected by restructuring. Transformation should not use Agile language to intensify work, eliminate due process, or shift responsibility downward without authority.

Metrics and Governance

Metrics should support decisions and learning, not become targets detached from purpose. Useful measures may include:

• lead time and cycle time;
• throughput and work in progress;
• deployment frequency and change failure rate;
• escaped defects and reliability;
• customer adoption, satisfaction, retention, or task success;
• team health and psychological safety;
• progress toward product outcomes.

Velocity is a local planning aid, not a valid cross-team productivity currency. Comparing teams by velocity encourages estimation inflation and destroys the meaning of the measure. Similarly, utilisation near 100 percent can increase queues and reduce responsiveness.

Governance should make risk visible and decisions traceable. In regulated contexts, Agile teams can maintain evidence continuously through automated test records, code review history, threat modelling, accessibility checks, approval workflows, and release documentation. Compliance is not inherently anti-Agile; late, manual, disconnected compliance work is the problem.

Illustrative Case: Northstar Digital Services

Background

Northstar Digital Services, a fictional retail organisation, operated four Scrum Teams building a mobile commerce platform. Customer-facing teams delivered features rapidly, but releases were delayed because a platform team controlled shared APIs and a separate security group performed testing near the end of each release. Product managers maintained competing roadmaps, and executives funded projects annually.

Problem

The organisation had frequent integration failures, a growing queue of security findings, and declining confidence in delivery forecasts. Management proposed adopting SAFe immediately across the entire company. Interviews revealed that the central problems were not a lack of ceremonies but component boundaries, unclear product ownership, late security involvement, and project-based funding.

Analysis

A value-stream map showed that work spent only a few days in active development but waited weeks for API decisions, security review, and release approval. Little’s Law suggested that reducing the number of concurrent initiatives would reduce waiting time if throughput remained stable. The analysis also showed that teams were measured on feature completion rather than customer adoption or operational quality.

Approach

Northstar created one product goal and a single prioritised product backlog for the commerce platform. It formed cross-functional feature teams, embedded security expertise into discovery and refinement, and defined a shared Definition of Done including automated security tests and accessibility checks. The platform team shifted from ticket approval to enabling self-service APIs with documented contracts. Executives replaced several annual project budgets with quarterly product-value-stream reviews. A lightweight Nexus-style integration arrangement was piloted because the immediate problem involved four teams delivering one integrated product; the organisation did not adopt a complete enterprise framework.

Distributed teams used asynchronous decision records and rotating overlap hours. Leadership stopped comparing team velocities and reviewed lead time, escaped defects, adoption, and reliability instead.

Outcome

After several improvement cycles, integration defects declined, security issues were discovered earlier, and teams could release smaller changes. Forecasts remained probabilistic rather than perfectly precise, but stakeholders received earlier evidence about what was working. Some managers initially resisted the loss of project-level control, and the organisation addressed this through explicit portfolio boundaries, risk reviews, and transparent outcome reporting.

Learning Points

The case illustrates that scaling should begin with diagnosis. A framework can provide useful structures, but it cannot compensate for fragmented ownership, unsuitable architecture, conflicting incentives, or delayed feedback. Northstar selected a limited coordination pattern for a specific product problem and changed funding and leadership behaviour alongside team practices.

Challenges and Limitations of Scaling Frameworks

No framework eliminates complexity. Common limitations include:

• frameworks may be adopted as branded checklists;
• additional roles and meetings may increase coordination cost;
• standardisation can suppress local learning;
• frameworks may assume a product structure that the organisation does not possess;
• scaling can amplify poor product strategy and technical debt;
• supplier contracts may reward scope delivery rather than collaboration;
• global adoption may ignore local labour law and cultural differences;
• framework certification can create a false impression of organisational capability.

A critical evaluator therefore asks: What problem is this practice solving? What evidence shows improvement? What new cost or risk does it create? Can the practice be removed when it no longer adds value?

Contemporary Developments and AI

Platform engineering, internal developer platforms, cloud automation, observability, trunk-based development, feature flags, and continuous delivery increasingly support scalable flow. These technologies reduce manual coordination but do not remove the need for product decisions or ethical governance.

Artificial intelligence can assist with code suggestions, test generation, documentation, dependency analysis, incident summarisation, and backlog exploration. However, AI-generated outputs require human review for security, licensing, privacy, accessibility, bias, reliability, and accuracy. Teams should define approved tools, protect confidential data, record material AI assistance where required, and retain human accountability for decisions. AI should reduce toil and improve learning, not become a surveillance mechanism or a justification for unrealistic workload increases.

Best-Practice Decision Guide

A sound scaling decision follows these steps:

1. Define the product or value stream and the outcome requiring coordination.
2. Measure current delays, dependencies, quality problems, and decision queues.
3. Improve team boundaries and architecture before adding governance layers.
4. Choose the lightest coordination mechanism that addresses the demonstrated problem.
5. Establish integrated quality and a shared product goal.
6. Align funding, incentives, leadership behaviour, and compliance with the desired way of working.
7. Use outcome and flow measures, interpreted in context.
8. Inspect and adapt the scaling design itself.

Chapter Summary

Scaling Agile is an organisational design challenge, not merely a larger version of team-level Scrum. Effective scaling coordinates dependencies, integrates work continuously, preserves product focus, and enables fast feedback. Nexus emphasises integrated increments among a small group of Scrum Teams; LeSS emphasises simplicity and a single product structure; Scrum@Scale provides modular networks with distinct product and delivery cycles; and SAFe offers extensive enterprise, value-stream, and portfolio mechanisms.

Agile transformation reaches strategy, funding, structure, technology, process, leadership, and culture. Portfolio agility aligns investment with outcomes while retaining proportionate governance. Leaders create conditions for autonomy, transparency, psychological safety, and system-level improvement. Distributed teams require deliberate asynchronous communication, inclusive collaboration, automation, and respect for privacy. Resistance should be understood as information about fear, incentives, structures, and power—not dismissed automatically.

The central professional judgement is to select and adapt mechanisms according to evidence. A framework is valuable only when it improves value delivery, quality, learning, and sustainable working conditions.

Key Terms

Agile transformation: Sustained change in how an organisation creates, governs, and learns from value.

Agile Release Train: A coordinated group of teams and stakeholders used in SAFe to deliver value on a shared cadence.

Backlog: An ordered list of work, opportunities, defects, and learning activities.

Definition of Done: Shared quality criteria that must be satisfied for work to be considered complete.

Dependency: A relationship in which one team, component, or decision relies on another.

Distributed team: A team whose members work across locations, time zones, or organisational boundaries.

Feature team: A cross-functional team capable of delivering customer-valued functionality across component boundaries.

Flow: The movement of work from idea or request to a usable outcome.

LeSS: Large-Scale Scrum, an approach emphasising one product, one Product Owner, and organisational simplicity.

Little’s Law: The stable-system relationship L = λW between work in progress, throughput, and time in system.

Nexus: A framework for coordinating multiple Scrum Teams producing one integrated product increment.

Outcome: A measurable change in user, customer, operational, or business conditions.

Portfolio alignment: Connecting strategy, investment, products, risks, and delivery capacity.

Psychological safety: A shared belief that people can speak up, question decisions, and report problems without interpersonal punishment.

Scrum@Scale: A modular scaling approach connecting networks of Scrum Teams and product decision-makers.

SAFe: Scaled Agile Framework, an enterprise-oriented framework covering team, value-stream, solution, and portfolio concerns.

Technical debt: Future cost created by expedient or inadequate technical decisions.

Value stream: The activities and resources required to deliver a product or service outcome.

Velocity: A team-specific planning measure of completed estimated work; not a universal productivity measure.

Work in progress: Items started but not yet completed.

Review Questions

Short Answer Questions

1. Why is scaling Agile more than multiplying the number of Scrum Teams?
2. What is the principal purpose of a shared Definition of Done?
3. State the assumptions underlying the use of Little’s Law in flow analysis.
4. Identify one strength and one limitation of LeSS.
5. Why should team velocity not be used to compare teams?

Long Answer Questions

1. Compare Nexus, LeSS, Scrum@Scale, and SAFe in terms of coordination, product ownership, governance, and likely organisational fit.
2. Explain how portfolio funding and governance can either support or undermine Agile transformation.
3. Analyse the leadership and cultural conditions required for sustainable organisational agility.
4. Discuss the principal challenges of distributed Agile teams and propose appropriate responses.
5. Explain why resistance to change should be analysed rather than simply suppressed during transformation.

Analytical / Application Questions

1. An organisation has six teams developing one product. Releases fail because integration occurs at the end of every quarter. Which coordination principles and scaling approach would you investigate first, and why?
2. A company reports high velocity, 98% staff utilisation, and declining customer adoption. Analyse what these measures may be hiding and recommend a better measurement set.
3. Design a transformation experiment for a regulated digital service. Specify the product boundary, governance controls, leadership behaviours, outcome measures, and criteria for expanding or stopping the experiment.

Multiple Choice Questions with Answers

Question 1

Which problem is Nexus primarily designed to address?

A. Enterprise-wide annual budgeting

B. Integration and coordination among several Scrum Teams working on one product

C. Replacing all product ownership with project management

D. Managing individual employee performance ratings

Correct Answer: B. Integration and coordination among several Scrum Teams working on one product

Question 2

Which characteristic is most closely associated with LeSS?

A. One product, one Product Owner, and one Product Backlog

B. A mandatory hierarchy of four organisational levels

C. Separate products for every component team

D. Annual integration performed by a central testing department

Correct Answer: A. One product, one Product Owner, and one Product Backlog

Question 3

In Scrum@Scale, the Product Owner Cycle primarily concerns:

A. Network infrastructure maintenance

B. Product direction, prioritisation, and value

C. Individual salary decisions

D. Replacing all Scrum events with status reports

Correct Answer: B. Product direction, prioritisation, and value

Question 4

Which is a potential limitation of SAFe when implemented mechanically?

A. It provides no portfolio concepts

B. It cannot be used in large organisations

C. Its roles and events may reproduce bureaucracy

D. It prohibits governance and compliance

Correct Answer: C. Its roles and events may reproduce bureaucracy

Question 5

In Little’s Law, L = λW, what does L represent?

A. Average work in progress

B. Average throughput

C. Average time in the system

D. The number of teams

Correct Answer: A. Average work in progress

Question 6

Which practice best supports continuous integration at scale?

A. Integrating all work only at the end of a release

B. Using automated tests and integrating changes frequently

C. Allowing each team to define incompatible quality standards

D. Assigning all integration to a separate permanent handoff team

Correct Answer: B. Using automated tests and integrating changes frequently

Question 7

Why is comparing teams by velocity generally inappropriate?

A. Velocity has no relationship to completed work within a team

B. Velocity is intended as a local planning aid and varies by team

C. Velocity is a legally regulated measure

D. Velocity can only be calculated for individual developers

Correct Answer: B. Velocity is intended as a local planning aid and varies by team

Question 8

Which leadership behaviour is most consistent with Agile transformation?

A. Maximising utilisation of every person

B. Hiding uncertainty until plans are complete

C. Providing direction while removing systemic impediments

D. Punishing teams for reporting defects

Correct Answer: C. Providing direction while removing systemic impediments

Question 9

Which response is most appropriate to distributed-team time-zone challenges?

A. Require every meeting to occur at the same location’s convenient time

B. Eliminate written documentation

C. Use asynchronous communication and rotate inconvenient meeting times

D. Measure commitment through webcam presence

Correct Answer: C. Use asynchronous communication and rotate inconvenient meeting times

Question 10

What is the most appropriate first step when selecting a scaling approach?

A. Purchase the most comprehensive framework immediately

B. Diagnose the product, dependency, flow, and governance problem

C. Mandate identical ceremonies for every department

D. Compare teams by estimated story points

Correct Answer: B. Diagnose the product, dependency, flow, and governance problem