Leadership practice questions

Choose one product owner to follow.

Why it fails: Unilaterally following one product owner silences the other, so their stakeholders' requirements go unrepresented and the underlying priority conflict persists. It is tempting because it restores a single direction quickly, which is the correct choice when one owner has clearly delegated authority for that product area.

Ask the team to decide between them.

Why it fails: Delegating the decision to the team pushes a product-priority conflict onto developers, who lack the authority to arbitrate competing business owners. It is tempting because teams self-organise on technical work, which is the correct choice when the disagreement concerns how to implement agreed backlog items.

Ignore the conflict.

Why it fails: Ignoring the disagreement leaves competing priorities unresolved, so the team keeps receiving conflicting direction and delivery stalls. It is tempting because deferring can let tempers cool, which is the correct choice only for trivial, self-resolving disagreements that do not affect backlog ordering.

Attend every technical meeting to provide guidance.

Why it fails: The leader's presence in every technical meeting shifts technical decisions toward their opinion, so the team defers rather than chooses. Attending is tempting because hands-on guidance genuinely helps when a team is newly formed or lacks a skill the leader holds.

Require all decisions to be approved by the leadership team.

Why it fails: Approval gates block the team from making its own commitments, so decisions stall at the leadership layer instead of emerging from those doing the work. It is tempting because governance and sign-off are genuine controls in regulated or high-risk delivery, where a leader must retain accountability for outcomes.

Create detailed task lists for every team member.

Why it fails: Detailed task lists assign work top-down, removing the team's authority to choose how it delivers, which is the opposite of self-organisation. Task lists suit a command-and-control or crisis-recovery context where a leader must direct work explicitly.

Ignore the behavior, as it will resolve itself.

Why it fails: Ignoring persistent negativity lets it damage team morale and psychological safety, so it does not resolve itself. Avoidance is tempting when a leader hopes to prevent confrontation, but it would only be defensible for a one-off remark that the team has already addressed.

Call them out during the daily stand-up.

Why it fails: Public criticism during a stand-up humiliates the individual in front of peers, entrenching defensiveness and derailing the ceremony's purpose. It is tempting because stand-ups are frequent and visible, but the leader's first step is a private conversation to surface the cause, not public confrontation.

Ask the team to vote on whether to keep them in the squad.

Why it fails: Putting a person's membership to a team vote turns a private coaching matter into public exclusion, damaging safety and giving no diagnostic information. It is tempting because agile teams do self-organise, but that autonomy covers how work is done, not expelling a colleague before any conversation occurs.

Assign a mentor to watch every task developers perform.

Why it fails: Surveillance-style mentoring removes autonomy and signals distrust, undermining the self-organisation agile teams need to improve. Mentoring suits genuine skill gaps, offered by choice. The effective route is facilitated retrospectives where the team diagnoses impediments and commits to its own changes.

Analyze the velocity data and set higher targets for the next sprint.

Why it fails: Raising targets from velocity data ignores the root causes of missed goals and removes the team's ownership of improvement. Velocity is a forecasting measure, not a lever. Retrospective-driven process change, where the team identifies and owns fixes, is the empowering route.

Replace the team members who are underperforming.

Why it fails: Replacing members treats symptoms and destroys psychological safety, so the team loses the empowerment to self-correct. Removing people suits genuine capability gaps after coaching. Here the team should inspect its process in a retrospective and own the improvement actions.

Set up a shared document repository for everyone to read.

Why it fails: A shared repository distributes artefacts for reading; it creates no interaction, so siloed members remain siloed. It is tempting because it is cheap and looks like knowledge sharing, and it is the right choice when the problem is document discoverability rather than collaboration. Fostering collaboration requires techniques that force joint work.

Implement individual performance bonuses for the fastest developers.

Why it fails: Individual bonuses reward personal output, actively discouraging the mutual help and shared ownership that break silos. It is tempting because incentives do change behaviour, and individual rewards suit contexts where independent throughput is the goal. Here they intensify competition between members who already work alone.

Require daily status reports from every developer.

Why it fails: Daily status reports are one-way reporting to a manager; they add coordination overhead without creating interaction between developers. It is tempting because it feels like improved communication, and reporting suits environments needing visibility of progress. Collaboration requires joint problem-solving, not individual written updates.

Ask the developers to work overtime to accommodate the request.

Why it fails: Overtime masks the disruption rather than protecting the sprint goal; the Product Owner should negotiate scope with the stakeholder and let the team decide. Overtime suits genuine short-term capacity gaps, not unplanned scope injection, and sustained overtime degrades quality and velocity.

Reject the request immediately as it violates the sprint commitment.

Why it fails: Sprint backlogs can absorb change when capacity allows, so an outright refusal ignores the product owner's authority to reorder and the team's option to swap equivalent work. Immediate rejection suits only a genuinely fixed-scope contract sprint; otherwise the agile response is to negotiate scope with the product owner.

Add the work to the sprint backlog immediately.

Why it fails: Adding work mid-sprint breaks the sprint backlog's stability and the team's forecast; the Product Owner should refine and order the item for a future sprint instead. Immediate addition suits urgent production defects, where the sprint goal itself is renegotiated with the team.

Make the decision yourself to prevent further delay.

Why it fails: Imposing your own architecture choice removes the team's ownership of technical decisions, which Agile practise assigns to the developers, and leaves the underlying disagreement unresolved. Deciding unilaterally suits a genuine deadlock threatening a hard deadline, but here facilitation techniques should first surface the trade-offs and build consensus.

Ask the product owner to decide the architecture.

Why it fails: The product owner owns value and backlog priority, not technical architecture, so delegating this decision exceeds their remit and still leaves the disagreement unresolved. It is tempting because the product owner can arbitrate scope trade-offs, and that would be correct for deciding which feature ships first.

Vote on the approaches and go with the majority.

Why it fails: Voting settles the decision by headcount, not by evaluating the architectural trade-offs, so the underlying disagreement persists and the minority disengages. Majority voting suits low-stakes, reversible choices where speed outweighs analysis; here the team needs collaborative consensus-building to resolve a technical impasse.

Update the Scrum Guide to include strict penalties for stakeholders.

Why it fails: The Scrum Guide is a framework document that cannot be amended with penalties, and doing so does not address the stakeholder's behaviour. Adding governance penalties is correct in regulated or contractual settings where formal escalation paths exist, not for coaching a stakeholder on Product Owner authority.

Instruct the developers to ignore the stakeholder's requests.

Why it fails: Telling developers to ignore the stakeholder leaves the underlying authority conflict unresolved and damages the relationship the coach must repair. Ignoring requests is correct only when a request is genuinely outside the team's remit, not when a stakeholder is bypassing the Product Owner and needs coaching on the agile model.

Have the developers log the work as 'technical debt' to keep track of it.

Why it fails: Logging the work as technical debt records the symptom without restoring the Product Owner's authority over prioritisation, so the bypass continues. Technical debt tracking is correct for capturing deferred rework in the backlog, not for redirecting a stakeholder who is assigning tasks directly to developers.

Cancel the daily stand-up until the team matures.

Why it fails: Cancelling the stand-up removes the team's daily synchronisation and lets the conflict go unaddressed, hiding rather than resolving it. It is tempting because pausing a ceremony feels like protecting the team, and would be correct only if the meeting itself were the sole cause and a replacement inspection mechanism existed.

Report the conflict to the functional manager to handle disciplinary action.

Why it fails: Escalating to a functional manager for discipline transfers ownership outside the team and contradicts servant leadership. The agile leader facilitates resolution within the team, coaching members to address behaviour directly. Manager-led disciplinary action fits a formal conduct or HR matter, not routine stand-up friction.

Force the individuals to move to different squads.

Why it fails: Reassigning individuals removes the people, not the conflict, and destroys the team's self-organising capability. An agile leader coaches the team to resolve friction directly, perhaps through working agreements or retrospectives. Moving people suits a structural reorganisation where skills are mismatched, not interpersonal friction during ceremonies.

Mandate that the team increase their velocity by 20% next sprint.

Why it fails: Mandating a 20% velocity increase treats velocity as a target, which corrupts the metric and pressures the team to inflate estimates rather than improve. The appeal is a quick visible number for the Product Owner, yet velocity is a planning output, not a performance lever. Mandating increases would be defensible only if the team were genuinely under-loaded and idle.

Change the story point estimation technique to something faster.

Why it fails: Switching estimation technique does not address inconsistent velocity; the variation usually stems from unclear acceptance criteria, unplanned work or uneven story sizing, which coaching should surface through retrospectives. Faster estimation is tempting because it appears to reduce overhead, but estimation speed is irrelevant to predictability. Changing technique is correct only when the current method genuinely mis-sizes work.

Ask the team to stop using story points.

Why it fails: Velocity instability stems from inconsistent story-point estimation and unclear acceptance criteria, not from the metric itself; removing story points discards the team's capacity signal without addressing root causes. Story points are correctly abandoned only when a team deliberately switches to flow-based metrics such as cycle time and throughput.

Force them to present every week.

Why it fails: Mandatory weekly presentations impose pressure without addressing the underlying cause of hesitation, likely entrenching withdrawal. It is tempting because repeated exposure is a recognised confidence-building technique, and would be correct for someone whose reluctance stems from lacking platform opportunities rather than fear.

Ask them in front of the group why they are so quiet.

Why it fails: Publicly singling out a quiet member in front of peers raises anxiety and damages psychological safety, reducing the openness coaching requires. It is tempting because surfacing the issue feels direct and fast, and would suit a team with established trust where a member's silence is blocking a decision.

Ignore them until they are ready to participate.

Why it fails: Active inclusion is better than waiting for passive engagement.

Tell the team to be more vocal.

Why it fails: Instructing people to be more vocal increases speaking volume without removing the conformity pressure that causes groupthink; dominant members still set the frame. Exhortation suits teams whose problem is silence, not convergence. The fix is a structured technique that collects independent input before debate, such as silent brainstorming or fist-of-five.

Ask the team to vote by a show of hands.

Why it fails: A show-of-hands vote aggregates preferences publicly, so early majority signals pressure dissenters to conform, reinforcing groupthink rather than surfacing independent judgement. Voting suits low-stakes, reversible decisions where speed matters. Divergent thinking needs anonymous or written input first, such as fist-of-five or silent brainstorming.

Call on each person one by one to give their opinion.

Why it fails: Sequential verbal polling still exposes each answer to the group, so later speakers anchor on earlier opinions and self-censor, which sustains groupthink. Round-robin suits gathering status updates where influence is not a concern. Breaking conformity requires anonymous written input collected before any discussion, such as silent brainstorming or a brainwriting round.

Tell the team to just say 'no' to any incoming requests.

Why it fails: A blanket refusal ignores prioritisation: requests must be evaluated against value and capacity, not rejected outright, and the team may lack authority to decline stakeholders unilaterally. It tempts because saying no does reduce interruptions, but the agile coach's role is to establish a visible, agreed intake and prioritisation process with the product owner.

Instruct the team to work longer hours to finish.

Why it fails: Longer hours do not reduce the number of concurrent tasks pulling the team apart; fatigue typically worsens switching and throughput. It tempts because extra capacity appears to absorb the overload, yet the constraint is unfinished work in progress, addressed by limiting concurrent items and protecting focus, not by extending the working day.

Create a formal document requiring all requests to be approved by you.

Why it fails: A formal approval document adds a gatekeeping layer rather than removing the competing demands causing context switching; it also shifts the servant-leader role into command-and-control. It tempts because controlling intake sounds like limiting work in progress, but that is achieved by agreeing explicit WIP limits with the team, not by centralising sign-off.

Tell the stakeholder that you are the decision-maker for features.

Why it fails: On agile teams the product owner owns backlog ordering, so asserting personal decision authority over features contradicts that accountability and bypasses value-based prioritisation. It is tempting because someone must decide, but the correct response routes the request to the product owner for prioritisation against the backlog.

Ask the team to add it to the current sprint.

Why it fails: Injecting work mid-sprint violates the sprint goal and the team's protected timebox; the product owner alone reorders the backlog between sprints. It is tempting because urgent requests feel responsive, and this would be correct only if the item were an emergency defect the product owner explicitly swapped in.

Agree to add the feature if it seems simple.

Why it fails: Agreeing based on apparent simplicity ignores value, effort, risk, and the product owner's backlog ordering, so it commits work without prioritisation. It is tempting because it appears responsive and collaborative, but the correct response refers the request to the product owner for value-based prioritisation.

Stop the project until the stakeholder is available.

Why it fails: Halting work removes the team's ability to deliver value and does not create the feedback channel the stakeholder is failing to provide, so the impediment worsens. It is tempting because it forces escalation, and it would suit a genuine blocker where progress without stakeholder input is impossible and unsafe.

Send the stakeholder a daily summary of the work.

Why it fails: A daily written summary is one-way reporting; it does not elicit the dialogue, questions or reactions that constitute feedback, so the underlying engagement problem persists. It is tempting because it keeps the stakeholder informed, and it would suit a stakeholder who only needs status visibility rather than active collaboration.

Assume the stakeholder is not interested and proceed without them.

Why it fails: Abandoning the stakeholder removes the feedback loop entirely, so the team ships on unvalidated assumptions and risks building the wrong increment. It is tempting when repeated outreach fails, since deprioritising a silent party feels pragmatic, but the correct response is to change the engagement channel or escalate through the product owner.

Issue a formal warning to the team member.

Why it fails: A formal warning is a command-and-control response that addresses the symptom through authority rather than surfacing why the member is late, which Agile coaching handles through the team's own working agreements. It is tempting because disciplinary escalation is standard in traditional management, and it would fit persistent misconduct after team-level dialogue fails.

Change the stand-up time to suit that member's schedule.

Why it fails: Moving the stand-up to suit one member lets an individual's schedule dictate the team's cadence and hides the underlying impediment instead of resolving it. It is tempting because stand-up timing is genuinely negotiable, and rescheduling would be right if the whole team agreed the current slot conflicted with a shared commitment.

Stop the stand-up whenever they are late.

Why it fails: Halting the stand-up whenever the member arrives late punishes the whole team for one person's behaviour and abandons the daily inspection of progress. It is tempting because it avoids direct confrontation, and pausing would be reasonable if a genuine production incident required immediate team attention.

Tell management that the team will work hard to make it happen.

Why it fails: Committing to an impossible date trades honesty for appeasement, hiding the real capacity constraint and setting the team up to fail. It tempts because it appears supportive, yet the coach's role is to surface data-driven forecasts and negotiate scope, not promise infeasible delivery.

Tell the team to stop providing estimates to management.

Why it fails: Withholding estimates removes the data management needs to make informed decisions and damages trust. It tempts as shielding the team, yet the correct response is to keep estimating transparently while coaching management on how velocity and uncertainty inform release forecasts.

Accept the date to avoid conflict with management.

Why it fails: Accepting the date silences the team's evidence and converts an estimate into a commitment the team cannot meet. It tempts as conflict avoidance, but the agile lead's duty is to protect the team and communicate transparently with management about uncertainty and trade-offs.

Merge the two teams into one large team.

Why it fails: Merging creates one larger team, but the dependency remains between the same people and coordination overhead grows, slowing delivery further. Dependencies are removed by decoupling interfaces or resequencing work. Merging suits small, tightly coupled teams where a single backlog genuinely reduces handoffs.

Assign a single manager to oversee both teams.

Why it fails: A manager adds a reporting layer but leaves the dependency itself intact, so neither team's delivery cadence changes. The dependency must be redesigned or decoupled. Appointing a coordinating manager suits programmes needing cross-team reporting, not removing a technical or backlog dependency blocking flow.

Tell the teams to stop relying on each other.

Why it fails: Ordering teams to stop relying on each other does not remove the shared deliverable; the dependency persists and work stalls. Dependencies are resolved by restructuring interfaces, sequencing or ownership. Simply forbidding reliance suits teams that are genuinely autonomous, not ones sharing a component or release.

Create your own vision for the team.

Why it fails: Inventing a vision usurps the Product Owner's accountability for maximising product value, creating competing direction and eroding trust. It is tempting because it produces an immediate shared narrative, and it would be appropriate only if you genuinely held the Product Owner role.

Ask the developers to interview the customers themselves.

Why it fails: Customer interviews gather raw needs but cannot substitute for the Product Owner's prioritisation and value decisions, so the team still lacks a shared direction. It is tempting because direct customer contact builds empathy, and it would be right when validating assumptions or refining detailed requirements.

Tell the team to just focus on completing their tasks.

Why it fails: Directing the team to ignore the vision removes the transparency Scrum depends on, so the underlying misunderstanding persists and surfaces later as rework. It is tempting because task focus restores short-term output, and it would fit a stable, well-understood backlog where priorities are already clear.

Ask the stakeholders to decide which technical tasks are important.

Why it fails: Deferring to stakeholders removes the team's ownership of technical decisions and stalls the argument without resolving it. It is tempting because stakeholder input matters for prioritisation, but this option would be correct only where business value trade-offs, not technical-debt handling, are the decision at hand.

Ignore the debt and focus on new features.

Why it fails: Ignoring technical debt lets it compound, slowing delivery and increasing defect rates, so the disagreement continues unchecked. It is tempting because protecting feature velocity feels productive, but this option would be correct only where the debt is genuinely trivial and deferring it carries no measurable cost.

Order the team to dedicate 50% of every sprint to technical debt.

Why it fails: Imposing a fixed 50% allocation removes the team's authority to self-organise, which PMI-ACP expects the facilitator to protect. It is tempting because reserving sprint capacity for technical debt is a legitimate technique when the team itself agrees on the proportion during backlog refinement.