Hard Difficulty Questions

Move the blocked items back to the 'Development' column.

Why it fails: Returning blocked items to Development hides the blockage and reverses flow, breaching the pull system's purpose. Moving work backwards is valid only when items genuinely need rework, not to disguise third-party dependencies that should be surfaced and swarmed.

Increase the WIP limit to 4 to accommodate the new item.

Why it fails: Raising the limit to 4 discards the constraint that exposes the blockage, defeating the purpose of a WIP limit. Limits are adjusted deliberately after flow data justifies it, not reactively to accommodate work pushed past a third-party dependency.

Ask the Product Owner to prioritize the next task for the developer.

Why it fails: Prioritising the next task sidesteps the WIP breach entirely; the developer's capacity is not the constraint, the blocked Testing column is. Product Owner prioritisation governs backlog order, which is the right lever when choosing what to build next, not when resolving a flow blockage.

Allow the fourth item to move into testing to keep developers busy.

Why it fails: Exceeding the WIP limit hides blocked work and inflates cycle time, exactly what the limit exists to expose. The agile response is to swarm on the blocked items or escalate the third party, not to pull new work. Allowing the move would be right only if the limit itself were being deliberately revised.

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.

Ask the team to work overtime to finish the backlog faster.

Why it fails: Overtime increases output volume, not alignment; the backlog itself encodes the outdated priorities, so faster delivery reproduces the same mismatch. It appeals because visible effort feels responsive. Re-prioritising the backlog with the product owner would be correct when the issue is delivery pace rather than content.

Update the release burn-down chart to reflect current progress.

Why it fails: A burn-down chart reports remaining work over time; updating it changes only the displayed progress, not which features are built, so alignment stays broken. It tempts because stakeholders often cite stale charts. Refreshing burn-downs is correct when reporting accuracy, not priority mismatch, is the underlying issue.

Change the definition of done to speed up delivery.

Why it fails: Redefining done lowers the quality bar; it does not reorder work toward current organisational priorities, so delivered features remain misaligned. It tempts because accelerating throughput appears to address stakeholder dissatisfaction. Tightening or relaxing done is correct when the team's quality standard, not the backlog's ordering, is the actual problem.

Increasing the number of meetings.

Why it fails: Adding meetings multiplies interruptions and fragments focus further, directly worsening context switching. Meetings are tempting because they synchronise information and unblock decisions, and a short daily stand-up genuinely helps a team coordinate — but as a technique for reducing task-switching they achieve the opposite.

Assigning multiple tasks to each person.

Why it fails: Parallel task assignment forces each person to juggle several workstreams, increasing switching between them. It is tempting because it appears to keep everyone busy and balance workload across a team, and it can suit independent, low-cognitive-load chores — but it directly contradicts the single-piece flow that limits work in progress.

Disband the team and create new ones.

Why it fails: Replacing the team discards the shared learning from the failed release and does not address the underlying behaviour, so the same blame dynamic recurs. Re-forming a team is appropriate when persistent dysfunction cannot be resolved, not as a first response to a blame game.

Identify the individual responsible for the failure.

Why it fails: Naming an individual to blame entrenches the fear and defensiveness that caused the blame game, so the team never reaches the psychological safety Agile depends on. Assigning ownership is legitimate during a blameless root-cause review, but only for the process failure, never for a person.

Ask the manager to provide disciplinary actions.

Why it fails: Escalating to disciplinary action reinforces command-and-control management and drives problems underground, preventing the transparency and self-organisation Agile requires. Manager-led corrective action would be appropriate for deliberate policy breaches, not for facilitating a mindset shift after a failed release.

Hire more developers.

Why it fails: Headcount does not create the automated pipeline, trunk-based integration and deployment automation that continuous delivery requires; adding developers to a manual release process increases coordination overhead and merge conflicts. Hiring is tempting because capacity feels like the bottleneck, but it is the right answer when throughput is limited by people, not by release mechanics.

Lower the security standards.

Why it fails: Continuous delivery requires automated testing, version control and deployment pipelines; lowering security standards removes controls without enabling faster releases and increases risk. It is tempting as a shortcut to speed delivery, and would be correct only if the stem asked how to reduce compliance overhead, not what technical capability enables continuous delivery.

Stop all documentation.

Why it fails: Documentation is orthogonal to deployment frequency; continuous delivery demands automated build, test and deployment pipelines with version-controlled artefacts. Halting documentation removes the audit trail and knowledge transfer that regulated releases rely on, and does nothing to shorten the release cycle. It tempts teams who equate agile with minimal paperwork, but documentation reduction is a team-practise decision, not a technical prerequisite.

Asking the highest-paid person to make the decision.

Why it fails: Seniority does not resolve technical trade-offs; the highest-paid person may lack the relevant architectural knowledge, so the conflict persists without addressing the design merits. It is tempting because escalation to a single authority can break deadlock quickly, and that approach suits governance or budget decisions rather than architecture debates.

Imposing your own preferred architecture to end the debate.

Why it fails: Imposing a preferred architecture suppresses the disagreement rather than resolving it, so the team never evaluates the technical trade-offs and buy-in is lost. It is tempting because a decisive leader can unblock delivery fast, which suits a genuine deadlock where the team has already exhausted collaborative options.

Letting the conflict continue until one side gives up.

Why it fails: Allowing the conflict to run until one side capitulates leaves the architecture undecided and damages team trust, so the technical trade-offs are never actually examined. It is tempting because avoidance sometimes lets emotions cool, which suits trivial disagreements that genuinely resolve themselves without architectural consequences.

Number of coffee breaks taken.

Why it fails: This is irrelevant to performance.

Employee age.

Why it fails: This is irrelevant to performance.

Dictate the team's schedule and daily working hours.

Why it fails: Dictating schedules directly removes the team's authority over how and when work is organised, which contradicts self-organisation. It is tempting because imposing working hours is a legitimate management tool for coordinating shift-based or regulated operational teams, where coverage and compliance genuinely require fixed rosters rather than team discretion.

Approve every task assignment to ensure it is handled correctly.

Why it fails: Approving every task assignment reinstates directive control, so decision authority stays with the leader rather than the team, directly blocking self-organisation. It is tempting because approval gates genuinely suit compliance-regulated or safety-critical work where segregation of duties is mandated. Here, the stem demands empowerment, which requires the team to allocate its own work.

Stop all work until the dependencies are resolved.

Why it fails: Halting all work converts a coordination problem into a delivery stoppage, wasting capacity while dependencies remain unresolved. Dependencies are handled by making them visible, sequencing work and coordinating through Scrum of Scrums or dependency boards. Stopping suits a genuine blocking impediment, not routine cross-team dependencies.

Assign a single manager to direct all four teams.

Why it fails: A single directing manager reinstates command-and-control, removing the teams' self-organisation and delaying decisions to one person. Dependency management at scale uses Scrum of Scrums or a shared dependency board, where representatives coordinate across teams. A single manager suits a small, co-located team lacking direction.

Merge all teams into one large team to simplify communication.

Why it fails: Merging four teams into one enlarges communication paths and destroys the small-team structure that enables self-organisation. Cross-team dependencies are managed through Scrum of Scrums, shared backlogs and dependency boards while teams stay intact. Merging suits a team too small to hold all needed skills.

Do nothing.

Why it fails: Ignoring persistent lateness leaves the behaviour unaddressed and erodes team norms, so no corrective action occurs. It is tempting when the lateness seems trivial or the facilitator avoids confrontation, but doing nothing is only defensible once the team has explicitly agreed the behaviour is acceptable and self-corrected.

Start the meeting without them every time.

Why it fails: Starting without the member normalises the behaviour and removes any consequence, so the underlying cause is never surfaced. It is tempting as a way to respect the time of those present, but a team working agreement with a private conversation is the correct route, not silent exclusion.

Bring it up in the daily stand-up.

Why it fails: Raising an individual's conduct in the daily stand-up breaches the forum's purpose of synchronising work, and public criticism damages psychological safety. It is tempting because stand-ups are frequent and visible, but private, direct conversation is the correct channel for interpersonal issues.

Assign a dedicated project manager to track every individual task across all teams.

Why it fails: Task-level tracking by a project manager reinstates command-and-control, creating a bottleneck and delaying dependency resolution. It tempts because visible ownership feels like coordination, and it would suit a predictive programme with stable scope; agile scaling instead needs teams to negotiate dependencies directly at shared planning events.

Combine all five teams into one large daily stand-up meeting.

Why it fails: A single five-team stand-up destroys the daily coordination cadence each team needs and creates a bottleneck, since cross-team dependencies require a separate Scrum of Scrums or ART sync. One combined stand-up would suit a single small team, not five interdependent teams scaling a product.

Mandate that all teams use the same velocity reporting tool.

Why it fails: Standardising velocity reporting changes measurement, not coordination; velocity is team-relative and cannot expose or sequence cross-team dependencies. It tempts because shared tooling feels like alignment, and it would suit organisations needing consistent portfolio metrics rather than end-to-end flow across interdependent teams.

Request that teams ignore dependencies until the final integration sprint.

Why it fails: Deferring dependencies to a final integration sprint guarantees late discovery of cross-team conflicts, when rework cost peaks. It is tempting because it preserves each team's independent flow, which suits loosely coupled products; here five teams share one product, so dependencies must be surfaced and resolved continuously.

The sprint duration is too short.

Why it fails: Sprint length governs feedback cadence, not whether the backlog addresses customer needs; shorter sprints deliver the wrong increments faster. It is tempting because frequent reviews expose misalignment, and shortening sprints would be correct where feedback loops are too slow to catch requirement drift.

The team is lacking a project manager.

Why it fails: Velocity measures output volume, not whether that output satisfies customer needs; a project manager would not align backlog items to value. The role is tempting because traditional projects centralise coordination there, and it would be correct where cross-team dependencies and scheduling lack an owner.

The team is not using enough automated tests.

Why it fails: Automated test coverage affects defect detection and regression safety, not whether delivered increments match customer needs; high velocity with poor fit points to weak product backlog refinement or absent customer feedback. It tempts because testing underpins quality, but here the gap is requirements validation, not verification.

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.

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.

Mandate a new process that they must follow.

Why it fails: Mandating a process removes the team's ownership of improvement, so retrospectives stay performative rather than self-directed. It is tempting because imposing a framework can jolt a stalled team, and it would fit a crisis where the team lacks any baseline discipline and needs a scaffold before it can self-organise.

Berate the team for their lack of progress.

Why it fails: Berating the team damages psychological safety, so members withhold the very observations a retrospective needs to surface. It is tempting because a leader may believe pressure produces accountability, and confrontation would be the correct choice only when addressing a specific individual's repeated, deliberate breach of agreed team norms.

Cancel the retrospectives until they have something to report.

Why it fails: Cancelling retrospectives removes the team's only structured improvement forum, so complacency persists and worsens. It is tempting when sessions feel unproductive, but retrospectives are correct precisely to surface impediments; the intervention should vary the format or facilitation to generate actionable improvements.

Reject the request because it was not in the roadmap.

Why it fails: A roadmap is a directional artefact, not a contractual baseline, so refusing outright ignores the product owner's remit to re-prioritise the backlog as value emerges. Rejection fits a fixed-price predictive contract where scope is baselined and change control governs additions.

Immediately add the feature to the current sprint.

Why it fails: Adding work mid-sprint undermines the sprint goal and the team's agreed commitment, since scope is fixed for the sprint's duration. This instinct suits urgent production defects, where an interrupt is negotiated with the product owner rather than assumed.

Refer the request to the project manager for approval.

Why it fails: In agile, the product owner owns and prioritises the backlog, so routing change requests to a project manager bypasses that authority. Escalation suits predictive governance, where a change control board or sponsor approves scope changes against a baselined plan.

Ask the team to work overtime to accommodate the new requirement.

Why it fails: Overtime masks a scope problem rather than resolving it, degrading quality and velocity while leaving the Sprint Goal commitment intact only on paper. It appeals when a deadline feels immovable, yet sustained overtime is a symptom of poor planning, not a change-management mechanism.

Immediately add the change to the current sprint backlog to satisfy the stakeholder.

Why it fails: Adding scope mid-sprint breaks the Sprint Goal commitment and undermines the team's forecast without renegotiation. It is tempting because urgent stakeholder requests do sometimes warrant backlog changes, but that happens at Sprint Planning or via the Product Owner reordering future work, not mid-sprint insertion.

Refuse the change entirely because the Sprint Plan is fixed.

Why it fails: Refusing outright ignores that Agile welcomes changing requirements, even late. The Sprint Goal provides focus, not a contractual freeze; the Product Owner can negotiate scope swaps or defer the change to the next Sprint. Blanket refusal is tempting when protecting the team, but it forfeits responsiveness.

Ignore the feedback if the project budget is depleted.

Why it fails: Ignoring feedback because the budget is depleted abandons empirical inspection and adaptation, leaving a known defect in the product. It tempts when funds are tight, yet the Product Owner should still record the flaw on the backlog and let the customer prioritise it.

Blame the development team for the flaw.

Why it fails: Blame contradicts the agile principle of team accountability and blameless retrospectives, and it produces no product decision. It tempts because defects do originate in development work, but the Product Owner's first step is to capture the feedback on the backlog and re-prioritise.

Immediately delete the feature from the product.

Why it fails: Deleting the feature bypasses backlog refinement and stakeholder validation, discarding potentially valuable scope without analysis. It tempts as decisive action, yet a Product Owner should first add the flaw to the product backlog and prioritise it with the team and customer.

Mandate attendance without explanation.

Why it fails: Mandating attendance addresses none of the underlying overload; ceremonies exist to create transparency and inspect increments, so forcing participation without explaining purpose deepens disengagement. It would suit a compliance-driven rollout where attendance itself is the deliverable, not a team genuinely struggling with process fatigue.

Increase the frequency of meetings.

Why it fails: Adding meetings increases the ceremony load the team is already struggling with, worsening the overwhelm rather than relieving it. It is tempting because more frequent stand-ups can help distributed teams synchronise, but that applies when communication gaps, not ceremony fatigue, are the problem.

Cancel all ceremonies.

Why it fails: Removing every ceremony discards the inspect-and-adapt feedback loops that deliver transparency and continuous improvement. It is tempting because cancelling meetings immediately reduces perceived burden, but that would be correct only if the ceremonies served no purpose and the team already had alternative feedback mechanisms.