Agile Leadership, Facilitation and Stakeholder Management

Introduction

Agile product development is often described through frameworks, events, artefacts and delivery practices. Yet the success of an agile product organisation depends at least as much on leadership behaviour and stakeholder relationships as on process mechanics. A team may use Scrum correctly and still fail if leaders create fear, stakeholders bypass prioritisation, conflicts remain unresolved, or evidence is communicated in ways that encourage premature certainty.

Agile leadership is therefore not simply the authority to make decisions. It is the ability to create the conditions in which teams can make good decisions quickly, learn from evidence and remain accountable for outcomes. This requires servant leadership, coaching, facilitation, psychological safety, disciplined negotiation and communication adapted to different audiences.

For product managers, these capabilities are strategic. Product managers operate across customers, executives, designers, engineers, operations, finance, sales and compliance functions. They rarely control all these groups through formal authority. Their effectiveness depends on influencing decisions, clarifying trade-offs and maintaining trust while uncertainty remains high.

Learning Objectives

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

1. Explain the principles and limits of servant leadership in agile product development.
2. Distinguish leadership, coaching, mentoring and facilitation.
3. Create conditions for psychological safety and constructive challenge.
4. Select and apply facilitation techniques for common Scrum and product situations.
5. Diagnose and manage interpersonal and structural conflict.
6. Negotiate scope, priorities, risks and expectations using evidence.
7. Communicate product evidence effectively to executives, customers and delivery teams.
8. Evaluate the ethical and governance implications of stakeholder influence and product decisions.

Leadership in an Agile Product Organisation

From command and control to enabling leadership

Traditional project environments often centralise decisions in a manager who assigns work, monitors compliance and approves changes. Agile environments decentralise many decisions to cross-functional teams because the people closest to the work usually possess the most current technical and customer knowledge. This does not eliminate leadership; it changes its focus.

An agile leader establishes direction, constraints and decision rights while enabling teams to determine how best to achieve the intended outcome. The leader protects the product goal, removes systemic impediments, makes trade-offs visible and ensures that accountability is not confused with surveillance.

A useful distinction is:

• Direction: Why the product matters and what outcome is sought.
• Boundaries: Constraints involving time, budget, safety, regulation, architecture or brand.
• Autonomy: The team’s discretion over implementation and day-to-day coordination.
• Accountability: Responsibility for making commitments visible and learning from results.

Autonomy without direction produces local optimisation. Direction without autonomy produces dependency and slow decision-making. Agile leadership balances both.

Servant leadership

Servant leadership places the growth, effectiveness and well-being of people at the centre of leadership practice while retaining responsibility for organisational purpose and results. In Scrum-related work, servant leadership commonly involves:

• clarifying the product goal and decision context;
• helping the team remove impediments;
• protecting focus from unnecessary disruption;
• encouraging ownership rather than prescribing solutions;
• making information transparent;
• developing capability through coaching and feedback; and
• addressing organisational barriers that the team cannot solve alone.

Servant leadership is not passive helpfulness. A leader who refuses to make difficult decisions, challenge poor performance or resolve harmful behaviour is not serving the team. Service includes setting clear standards, confronting avoidance and escalating risks appropriately.

Leadership as a system of conditions

Team behaviour is shaped by the surrounding system. If executives reward only delivery speed, teams may hide quality problems. If a product manager changes priorities daily, a team may appear uncommitted when the real problem is unstable governance. If incentives reward individual utilisation, collaboration may decline.

Consequently, leadership should examine system conditions rather than attributing every problem to individual attitude. Useful diagnostic questions include:

• What behaviour does the reward system encourage?
• Which decisions are unclear or repeatedly revisited?
• Where does information become distorted as it travels upward?
• Which dependencies prevent the team from acting independently?
• Are goals stated as outputs, activities or customer and business outcomes?

Coaching, Mentoring and Facilitation

These practices overlap but are not interchangeable.

A product leader should choose deliberately. Coaching is useful when the team has the capacity to solve a problem but needs reflection. Mentoring is useful when a person would benefit from relevant experience. Facilitation is useful when group dynamics or process are obstructing progress. Direct management is appropriate where safety, ethics, legal obligations or urgent business continuity require decisive action.

A practical coaching sequence

A concise coaching conversation can follow this sequence:

1. Contract: Agree on the purpose and time available.
2. Explore: Establish what is happening, what matters and what assumptions exist.
3. Reflect: Identify patterns, tensions and alternative interpretations.
4. Act: Agree on a specific next step, owner and review point.
5. Learn: Revisit the result and update the mental model.

Questions should be specific rather than performatively open. “What evidence would change our current prioritisation?” is more useful than “Any thoughts?”

Psychological Safety and Productive Challenge

Psychological safety is a shared belief that a team can take interpersonal risks—such as asking for help, admitting an error, disagreeing with a senior person or reporting a concern—without being humiliated or punished. It does not mean that all ideas are accepted, that standards are lowered or that conflict disappears. A psychologically safe team can challenge ideas strongly while treating people with dignity.

Building psychological safety

Leaders can strengthen safety by:

• acknowledging uncertainty and their own mistakes;
• responding appreciatively when risks or bad news are raised;
• separating the quality of an idea from the worth of its proposer;
• inviting dissent before a decision is final;
• ensuring that quieter or less senior participants are heard;
• following up on concerns rather than merely thanking people; and
• applying behavioural standards consistently.

Psychological safety is undermined when leaders ask for honesty but punish the messenger, conduct “blameless” retrospectives while privately assigning blame, or permit dominant participants to interrupt others.

Safety and accountability together

Safety and accountability are complementary. A useful leadership stance combines high standards with high support. High standards without support create fear; high support without standards creates stagnation. In practical terms, teams should be able to say, “This approach failed,” while still being expected to investigate why, repair consequences and improve the system.

Retrospectives are particularly important. A good retrospective examines events, decisions, conditions and assumptions. It avoids both individual scapegoating and vague system language that prevents ownership. A balanced analysis may ask:

• What did we expect to happen?
• What actually happened?
• Which signals did we notice or miss?
• What conditions influenced the decision?
• What experiment will we run next?

Facilitation for Agile Collaboration

Facilitation is the intentional design and management of a group process so that participants can understand a situation, contribute relevant knowledge and make a sound decision. It is not merely chairing a meeting.

Design before facilitating

Before a workshop or Scrum event, clarify:

• the decision or outcome required;
• who has relevant knowledge and who has decision authority;
• what information participants need beforehand;
• which disagreements are likely;
• how the session will be structured; and
• how the decision and follow-up actions will be recorded.

A meeting without a defined outcome often becomes a status ritual. A meeting with too broad a participant list may become slow and politically cautious. A meeting with too few perspectives may produce a fast but fragile decision.

Facilitation techniques

Working agreements. The group agrees on behaviours such as listening without interruption, criticising assumptions rather than people, making decisions explicit and respecting time limits.

Round robin. Each participant speaks in turn. This is useful when hierarchy or personality causes uneven participation.

Silent writing. Participants first record ideas individually before discussion. This reduces anchoring and allows reflective participants to contribute.

Affinity mapping. Similar observations or ideas are grouped to reveal themes without prematurely debating every item.

Five whys. The group repeatedly examines causes. It should not be used mechanically; complex failures often have multiple contributing conditions rather than one linear root cause.

Fist-to-five. Participants show a level of confidence, for example from zero to five. It reveals disagreement or uncertainty but does not replace discussion.

Decision log. The decision, date, owner, rationale, evidence, assumptions and review condition are recorded. This reduces repeated debates and makes learning possible.

Parking lot. Important but out-of-scope questions are recorded for later treatment rather than allowed to derail the current objective.

Facilitating Scrum events

In Sprint Planning, facilitation should connect the Product Goal, Sprint Goal, available capacity, historical evidence and forecast. The event should not become a product manager assigning tasks to developers.

In the Daily Scrum, the focus should be adaptation toward the Sprint Goal. A facilitator should discourage reporting upward to a manager and instead support peer coordination.

In the Sprint Review, the product increment is inspected with stakeholders. The session should emphasise evidence, feedback and adaptation rather than theatrical acceptance of completed tasks.

In the Retrospective, the facilitator protects candour and helps the team identify a small number of actionable improvements. A long list of unowned actions is less valuable than one experiment that is actually reviewed.

Conflict: Diagnosis and Intervention

Conflict is not inherently harmful. Task conflict can expose assumptions and improve decisions. Relationship conflict, however, can damage trust and reduce information sharing. Process conflict concerns roles, methods, timing and responsibilities. These forms can coexist, so leaders should diagnose before intervening.

Sources of conflict

Common sources include:

• competing goals or incentives;
• ambiguous decision rights;
• scarce capacity;
• incompatible professional assumptions;
• dependencies between teams;
• perceived inequity;
• different risk tolerances;
• status or identity threats; and
• incomplete or asymmetrical information.

A useful first step is to distinguish positions from interests. A designer may positionally request more discovery time, while the underlying interest is reducing usability risk. A sales leader may request a feature for a major customer, while the underlying interest is protecting revenue or credibility. Interests create more possible solutions than positions.

A conflict intervention sequence

1. Stabilise: Address harmful behaviour and ensure people can participate safely.
2. Separate facts from interpretations: Identify what is observed, inferred and assumed.
3. Surface interests: Ask what each party is trying to protect or achieve.
4. Define the decision: Clarify whether the issue requires information, negotiation or an authority decision.
5. Generate options: Seek alternatives before evaluating them.
6. Agree and document: Record the decision, rationale, owner and review point.
7. Repair relationships: Confirm how participants will work together after disagreement.

Leaders should not force artificial consensus. Consensus can be inappropriate when the cost of agreement is delay or when a clear accountable decision-maker exists. The goal is informed commitment: people understand the decision, its rationale and their responsibilities, even when their preferred option was not selected.

Negotiating Scope and Expectations

Agile development does not mean that scope is infinitely flexible or that commitments have no meaning. It means that plans are treated as hypotheses and adapted in response to learning, while the product goal and constraints remain explicit.

The scope–time–capacity relationship

A delivery conversation should distinguish at least four variables:

• Scope: The outcomes, capabilities or work included.
• Time: A deadline or timebox.
• Capacity: The people, skills and technical capability available.
• Quality and risk: Reliability, security, compliance, maintainability and other standards.

If time and capacity are fixed, scope is the principal variable that can be adjusted. However, reducing scope does not justify reducing non-negotiable quality or safety standards. A product manager should negotiate which valuable outcome can be delivered within the constraints, not merely ask a team to work faster.

Evidence-based negotiation

A disciplined negotiation can use the following structure:

1. State the shared objective.
2. Make constraints visible.
3. Present evidence and uncertainty separately.
4. Identify options and their consequences.
5. Agree on a decision rule.
6. Define what will be reviewed and when.

For example, instead of saying, “Engineering must include the integration this quarter,” a product manager might say, “The business outcome is reducing failed onboarding. We have evidence that identity verification is a major drop-off point. Given the fixed regulatory work and current capacity, we can either deliver a smaller verification improvement this quarter or defer it and test an alternative intervention. Which option best protects the outcome?”

Managing expectations

Expectation management begins before a commitment is made. Communicate:

• what is known;
• what is assumed;
• what is not yet decided;
• what could change the plan;
• the confidence level of the forecast; and
• the next evidence point.

Avoid false precision. A date presented without assumptions is often interpreted as a guarantee. A more responsible statement is: “The team’s current forecast is completion within four to six weeks, assuming the payment-provider interface remains stable and no additional compliance requirements emerge.”

Communicating Product Evidence to Different Stakeholders

Evidence is not self-explanatory. Different audiences require different levels of abstraction, decision relevance and detail.

Executive communication

Executives generally need a concise relationship between evidence and decision. A strong update answers:

1. What outcome are we pursuing?
2. What has changed since the last update?
3. What evidence supports the interpretation?
4. What risks or uncertainties remain?
5. What decision or support is required?

A dashboard should not be treated as a substitute for judgement. Metrics need definitions, time periods, segments and caveats. For example, an increase in feature usage may reflect genuine value, forced workflow changes or measurement errors.

Customer communication

Customers should receive honest accounts of capability, limitations and expected change. Product demonstrations should distinguish between a prototype, an experiment and production functionality. Customer evidence should also be treated critically: a loud request from one customer is not automatically representative of the broader market.

Delivery-team communication

Delivery teams need the problem context, user evidence, constraints, decision rationale and space to challenge assumptions. They do not need every executive conversation, but they do need enough information to make sound implementation decisions. “Why” is not a motivational luxury; it is an input to design and technical trade-offs.

Measuring Leadership and Stakeholder Effectiveness

No single metric captures leadership quality. A balanced evidence set may include:

• decision lead time;
• number and age of unresolved impediments;
• rework caused by unclear requirements;
• proportion of retrospective actions reviewed;
• stakeholder attendance and quality of review participation;
• team-reported safety and clarity;
• escaped defects and service incidents; and
• outcome measures such as activation, retention or task success.

These measures must be interpreted carefully. A shorter decision time could indicate empowerment, or it could indicate rushed decisions. High retrospective attendance does not prove candour. A team survey can provide useful signals but should not be used to rank individuals or create pressure to report positive results.

Illustrative Case: Northstar Health Scheduling

Background

Northstar Health, a fictional digital health provider, is developing an appointment-scheduling product. The executive sponsor has promised a reduction in call-centre volume within one quarter. The product team includes a product manager, designer, engineers, a data analyst and a compliance specialist. Customer support reports that patients struggle to find suitable appointment times.

Problem

The sponsor requests a complete redesign of the scheduling journey in six weeks. Engineering estimates that the requested integration with a hospital availability system alone may require most of that period. The compliance specialist is concerned that proposed changes could expose sensitive patient information. During planning meetings, the sponsor’s representative frequently interrupts engineers, while engineers have begun to withhold concerns until after meetings.

Analysis

The product manager diagnoses several connected problems:

• a desired outcome has been translated into an oversized solution;
• decision rights between the sponsor and product team are unclear;
• psychological safety is low;
• the integration contains regulatory and technical uncertainty; and
• the team lacks a shared evidence baseline.

The product manager conducts a short discovery review using call-centre transcripts, funnel data and usability observations. The evidence indicates that many patients abandon the process when no suitable appointment appears, but it does not prove that a complete redesign is necessary.

Approach

First, the product manager facilitates a working agreement for stakeholder sessions: participants may challenge ideas, interruptions are avoided and unresolved concerns are recorded. Second, the team defines the outcome as reducing avoidable scheduling calls while maintaining privacy and appointment accuracy.

Third, the team separates non-negotiable constraints from negotiable scope. Privacy controls and accurate availability are non-negotiable. A new visual design, multiple reminder channels and several administrative enhancements are negotiable.

Fourth, the team proposes a staged approach. In the first stage, it will test clearer availability messages and a guided alternative when no appointment is available. In parallel, engineering will investigate the hospital integration and compliance implications. The product manager communicates to executives that the first stage is a learning and risk-reduction step, not a claim that the final solution is complete.

Finally, the Sprint Review is redesigned around evidence. Stakeholders observe the tested flow, examine call deflection and task-completion signals, and record decisions in a decision log. The sponsor retains authority over investment, while the cross-functional team retains authority over implementation within agreed boundaries.

Outcome

The initial test reduces avoidable scheduling calls in the pilot segment, although the result is not yet generalisable to all hospitals. The integration investigation identifies a data-refresh constraint that would have created misleading availability. Engineers report concerns earlier in subsequent sessions because the facilitation norms are consistently enforced. Executives approve a larger experiment but do not treat the early signal as proof of long-term impact.

Learning points

The case demonstrates that leadership is expressed through system design: clarifying outcomes, protecting candour, separating constraints from preferences and making uncertainty visible. It also shows why evidence must be communicated with confidence limits and why stakeholder alignment is an ongoing practice rather than a one-time approval meeting.

Ethical, Governance and Contemporary Considerations

Agile leaders influence whose knowledge is heard and whose interests are prioritised. Ethical stakeholder management therefore requires attention to power, inclusion and consequences. Customers with limited digital access, minority language users, people with disabilities and operational staff may be underrepresented in executive discussions but strongly affected by product decisions.

Important governance practices include:

• documenting material decisions and assumptions;
• protecting confidential customer and employee information;
• ensuring accessibility and non-discrimination are considered in discovery and testing;
• distinguishing correlation from causal evidence;
• avoiding manipulation of metrics or selective reporting;
• identifying who is accountable for risk acceptance; and
• providing escalation routes for safety, security and compliance concerns.

Artificial intelligence can assist with meeting transcription, theme clustering, sentiment analysis and stakeholder-question generation. It should not be treated as a neutral judge of team morale or conflict. Automated sentiment systems may misinterpret cultural communication styles, disability-related speech patterns or disagreement. Sensitive transcripts require consent, access controls, retention rules and human review. AI-generated summaries should be checked against the original conversation, particularly where decisions, commitments or allegations are involved.

Contemporary agile leadership increasingly involves distributed and hybrid teams. Effective practice requires asynchronous decision records, inclusive meeting design, explicit response expectations and attention to time-zone inequity. Remote collaboration can increase access to written evidence, but it can also conceal informal disagreement. Leaders should create deliberate channels for dissent and informal connection without assuming that visibility equals contribution.

Challenges and Limitations

Agile leadership practices have limits. Servant leadership may be misapplied as avoidance of authority. Psychological safety cannot compensate for inadequate skills, impossible workload or unsafe employment conditions. Facilitation cannot resolve conflicts caused by fundamentally incompatible incentives unless governance changes. Transparency can also become harmful if sensitive information is exposed without regard to privacy or power relationships.

Evidence-based management is similarly imperfect. Product metrics are proxies, often delayed and vulnerable to gaming. Qualitative research provides depth but may not estimate prevalence. Executive decisions may need to be made before evidence is conclusive. The appropriate response is not to wait for certainty but to state uncertainty explicitly, choose reversible actions where possible and establish review points.

Best-Practice Checklist

An agile product leader should:

• connect every major discussion to an outcome or decision;
• clarify who recommends, decides, contributes and executes;
• make assumptions and uncertainty visible;
• invite dissent before commitment, not after failure;
• protect people who raise risks;
• negotiate scope without trading away essential quality or safety;
• use facilitation methods appropriate to the group and purpose;
• document consequential decisions and review conditions;
• communicate evidence differently to executives, customers and delivery teams; and
• treat inclusion, privacy, accessibility and responsible AI use as product concerns.

Chapter Summary

Agile leadership creates the conditions for effective self-managing teams rather than replacing team judgement with command. Servant leadership combines support with standards, while coaching, mentoring, facilitation and management serve different purposes. Psychological safety enables people to raise concerns and challenge assumptions, but it must coexist with accountability.

Facilitation improves the quality of collaboration by clarifying outcomes, designing participation and recording decisions. Conflict can be productive when task disagreements are separated from personal hostility and addressed through interests, evidence and explicit decision rights. Scope and expectation negotiation requires visibility of time, capacity, quality, risk and uncertainty; agile does not mean unlimited scope or consequence-free commitments.

Stakeholder communication should be adapted to the audience while preserving evidential integrity. Executives need strategic implications and decisions, customers need honest value and limitations, and delivery teams need problem context and constraints. Ethical leadership requires attention to power, inclusion, privacy, accessibility and responsible use of technology. Ultimately, agile leadership is the disciplined practice of aligning people, evidence, decisions and learning around valuable product outcomes.

Key Terms

Agile leadership: Leadership that enables adaptive decision-making, learning and accountable team autonomy.

Servant leadership: A leadership approach centred on enabling people and removing barriers while maintaining responsibility for outcomes.

Psychological safety: A shared belief that interpersonal risks can be taken without humiliation or punishment.

Coaching: A process that helps individuals or teams generate insight and action through inquiry and reflection.

Mentoring: Developmental guidance based on the mentor’s relevant experience and judgement.

Facilitation: Designing and guiding group interaction to support participation and sound decisions.

Self-management: The team’s ability to organise its work and make appropriate decisions within agreed boundaries.

Stakeholder: A person or group that affects, is affected by or has an interest in a product decision.

Task conflict: Disagreement about ideas, evidence or solutions.

Relationship conflict: Interpersonal tension involving identity, trust or personal hostility.

Process conflict: Disagreement about roles, methods, timing or responsibilities.

Interest: The underlying need or concern that motivates a stated position.

Decision rights: Explicit authority to recommend, decide, contribute or execute.

Product evidence: Qualitative or quantitative information used to understand problems, outcomes and risks.

Decision log: A record of a decision, rationale, evidence, assumptions, owner and review conditions.

Outcome: A change in customer, user, business or operational condition, rather than merely completed work.

Working agreement: Explicit behavioural and collaborative norms established by a group.

Expectation management: Communicating commitments, assumptions, uncertainty and possible change responsibly.

Review Questions

Short Answer Questions

1. What is the central difference between servant leadership and command-and-control leadership?
2. Why is psychological safety not the same as the absence of accountability?
3. Distinguish coaching from facilitation.
4. Identify three variables that should be considered when negotiating scope.
5. Why should product evidence be communicated differently to executives and delivery teams?

Long Answer Questions

1. Explain how an agile leader can balance team autonomy with organisational direction and accountability.
2. Discuss the role of facilitation in Sprint Planning, Sprint Review and Retrospectives.
3. Analyse the relationship between psychological safety, conflict and product quality.
4. Explain an evidence-based approach to negotiating a fixed deadline with uncertain scope.
5. Evaluate the ethical risks involved in using AI tools to analyse stakeholder or team communication.

Analytical / Application Questions

1. A senior executive repeatedly changes priorities during a Sprint and then criticises the team for missing its goal. Diagnose the system-level causes and propose an intervention plan.
2. A customer urgently requests a feature, but available evidence comes from only one large account. How should the product manager assess the request, communicate uncertainty and decide whether to act?
3. A retrospective is silent after a serious production incident. Design a facilitation approach that protects psychological safety while producing accountable improvement actions.

Multiple Choice Questions with Answers

Question 1

Which statement best describes servant leadership in an agile product team?

A. The leader assigns every task and approves every technical decision.

B. The leader enables the team, removes barriers and maintains accountability for outcomes.

C. The leader avoids difficult decisions so that the team remains fully autonomous.

D. The leader measures individual utilisation as the primary indicator of performance.

Correct Answer: B. The leader enables the team, removes barriers and maintains accountability for outcomes.

Question 2

Psychological safety primarily means that team members can:

A. Avoid all criticism of their work.

B. Make interpersonal contributions and raise concerns without fear of humiliation or punishment.

C. Choose any work they want without regard to the Product Goal.

D. Expect all proposals to be accepted.

Correct Answer: B. Make interpersonal contributions and raise concerns without fear of humiliation or punishment.

Question 3

Which practice is most directly intended to reduce anchoring before group discussion?

A. Silent writing before discussion

B. Status reporting by each participant

C. Immediate voting by seniority

D. Removing all constraints from the agenda

Correct Answer: A. Silent writing before discussion

Question 4

A disagreement about who owns a decision is primarily an example of:

A. Relationship conflict

B. Process conflict

C. Customer validation

D. Psychological safety

Correct Answer: B. Process conflict

Question 5

When time and capacity are fixed, responsible agile scope negotiation should generally focus first on:

A. Reducing essential quality standards

B. Increasing individual working hours indefinitely

C. Selecting the most valuable outcome and adjusting negotiable scope

D. Hiding uncertainty from stakeholders

Correct Answer: C. Selecting the most valuable outcome and adjusting negotiable scope

Question 6

What information is especially important in an executive product update?

A. Every task completed by each developer

B. Strategic outcome, evidence, risks, trade-offs and the decision required

C. Only the team’s meeting attendance

D. A guarantee that no assumptions will change

Correct Answer: B. Strategic outcome, evidence, risks, trade-offs and the decision required

Question 7

Which statement about conflict is most accurate?

A. All conflict should be eliminated immediately.

B. Task conflict can expose assumptions, whereas relationship conflict can damage trust.

C. Conflict is always evidence of poor facilitation.

D. Consensus is required for every product decision.

Correct Answer: B. Task conflict can expose assumptions, whereas relationship conflict can damage trust.

Question 8

What should a decision log normally contain?

A. Only the final decision and the names of attendees

B. The decision, rationale, evidence, assumptions, owner and review conditions

C. A ranking of participants by influence

D. Unverified rumours about stakeholder preferences

Correct Answer: B. The decision, rationale, evidence, assumptions, owner and review conditions

Question 9

Why should AI-generated meeting summaries be reviewed by a human?

A. AI tools cannot produce any text.

B. Automated summaries may misrepresent context, commitments or sensitive concerns.

C. Human review guarantees that every decision is correct.

D. Review is needed only when the meeting has no decisions.

Correct Answer: B. Automated summaries may misrepresent context, commitments or sensitive concerns.

Question 10

In the Northstar Health case, why was a staged approach appropriate?

A. It avoided collecting any customer evidence.

B. It separated immediate learning from uncertain integration and compliance work.

C. It guaranteed that the final product would succeed.

D. It transferred all implementation authority to the executive sponsor.

Correct Answer: B. It separated immediate learning from uncertain integration and compliance work.