Mindset practice questions

Agile processes should be as complex as possible

Why it fails: Simplicity is encouraged.

Maximize the amount of work not done

Why it fails: The principle is 'simplicity—the art of maximizing the amount of work not done—is essential'.

Stop doing retrospectives to save time for coding.

Why it fails: Retrospectives are the team's inspect-and-adapt mechanism for surfacing why over-commitment recurs; cancelling them removes the feedback loop that would correct estimation and capacity planning. It tempts teams under delivery pressure because it frees immediate coding time, but that treats the symptom, not the cause.

Assign tasks to members by seniority to ensure speed.

Why it fails: Assigning work by seniority ignores self-organisation and collective ownership of commitments, so over-commitment persists because the team never inspects and adjusts its forecast. It tempts because pairing experienced staff with complex items can raise throughput, and it would fit a skills-gap scenario, not a chronic over-commitment problem.

Increase the sprint length to provide more time.

Why it fails: Lengthening the sprint dilutes the feedback cadence without addressing the estimation error driving over-commitment, so the same shortfall simply recurs over a longer window. It appeals when velocity looks capacity-constrained, yet the stem describes over-commitment, not insufficient duration.

Tell the team they must adapt to the manager's style.

Why it fails: Telling the team to adapt endorses the micromanagement rather than removing it, leaving morale unaddressed. It is tempting because accommodating a manager appears cooperative, yet a servant leader's role is to challenge the behaviour causing the impediment and protect the team's autonomy.

Report the team for lack of productivity.

Why it fails: Reporting the team contradicts the servant leader's duty to remove impediments and shield the team from micromanagement. It is tempting when productivity metrics look poor, but a servant leader addresses the manager's behaviour, coaching rather than escalating blame onto the team.

Become the manager and direct all work.

Why it fails: Becoming the manager and directing all work replaces one micromanager with another, deepening the morale problem. It is tempting because direct control appears to restore order quickly, but servant leadership means enabling self-organisation, not centralising decisions and command.

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.

Implement mandatory overtime to finish tasks.

Why it fails: Mandatory overtime extends working hours without limiting concurrent work, so context switching continues and quality drops. Overtime is a legitimate lever only for a short, fixed recovery of a committed date, never as a servant-leader response to focus problems.

Mandate daily status reports to the PMO.

Why it fails: Status reports to the PMO add reporting overhead and external control, increasing interruptions rather than reducing context switching. Such reporting is appropriate where governance demands formal progress visibility, not for fostering team focus through limiting work in progress.

Assign specific tasks to individuals without team input.

Why it fails: Assigning tasks unilaterally removes the team's ownership of its own workflow, which is the mechanism that sustains focus; the stem asks for a servant-leader step, and dictating work contradicts that. It is tempting because directive assignment suits crisis command-and-control, where a single coordinator must allocate work quickly.

Accept the change and extend the sprint duration.

Why it fails: Agile teams protect the sprint's timebox; a mid-sprint requirement is negotiated with the product owner and either swapped for equal-sized work or deferred to the backlog. Extending the sprint is tempting because it appears accommodating, but altering the timebox destroys the cadence and velocity data that planning depends on.

Refuse all changes immediately.

Why it fails: Refusing all changes contradicts Agile's embrace of evolving requirements; the product owner alone decides backlog priority, so the team should negotiate scope rather than block. Refusal suits fixed-scope waterfall contracts, where a change control board gates alterations, not an Agile sprint.

Ask the stakeholders to approve the change first.

Why it fails: Stakeholder approval is a waterfall change-control gate; in Agile the product owner owns backlog ordering and can reprioritise mid-sprint directly. Escalating to stakeholders suits PRINCE2 or contractual governance, where scope changes require formal sign-off beyond the product owner's authority.

Publicly reprimand the team member during the next meeting.

Why it fails: Public reprimand escalates defensiveness and models the very behaviour undermining safety, so the retrospective's open-dialogue purpose is defeated. It appeals as visible enforcement of ground rules, and would be defensible only for deliberate, repeated violations after private coaching, never as a first intervention during a retrospective.

Ignore the behavior to avoid conflict.

Why it fails: Ignoring the criticism lets the defensive atmosphere persist and signals that ground rules are unenforced, so psychological safety keeps eroding. It appeals as conflict avoidance, and would be reasonable for a single mild remark better handled privately afterwards, not for a consistent pattern the facilitator must actively address.

Remove the team member from the project immediately.

Why it fails: Removing the member addresses behaviour's symptom by eliminating the person, not the retrospective dynamic, and destroys the safety the facilitator is meant to build. It is tempting as a decisive response to persistent disruption, and would fit only after documented, repeated breaches of team working agreements where coaching and private feedback have failed.

Agree to the terms but plan to change them later.

Why it fails: Agreeing while secretly planning later changes is deception, not the transparency Agile influence requires, and it destroys trust. It is tempting because incremental scope refinement is legitimate in Agile contracts, but that happens through explicit renegotiation, not concealed intent.

Refuse to work on the project.

Why it fails: Refusing the work abandons the servant-leadership and negotiation the question tests, delivering no influence at all. It is tempting when a stakeholder's demand genuinely violates Agile principles irreconcilably, but the stem asks how to demonstrate mindset and influence, not when to walk away.

Submit a formal complaint to the executive board.

Why it fails: Escalating to the executive board bypasses the stakeholder dialogue Agile influence depends on, so it coerces rather than demonstrates mindset. It is tempting as governance escalation genuinely resolves deadlocked contractual disputes, but here the goal is collaborative negotiation, not adjudication.

Rejecting all feedback until the next project phase.

Why it fails: Feedback rejection prevents the inspection and adaptation that embracing change requires, so the team cannot respond to new information between phases. It is tempting because deferring feedback to a phase gate resembles controlled change management, which suits regulated waterfall projects with formal baseline approvals.

Changing the team members every sprint.

Why it fails: Rotating team members each sprint destroys the stable, self-organising team that sustains iterative delivery; it is churn, not responsiveness to product feedback. It is tempting because reshuffling skills resembles adapting team composition, which is valid when a genuine capability gap or dependency demands it.

Strictly following the initial project roadmap.

Why it fails: Following the roadmap rigidly ignores emerging feedback and learning, directly contradicting the value of responding to change. It is tempting because a roadmap provides direction and stakeholder alignment, which is appropriate when the domain is stable and requirements are genuinely well understood.

To report to the board on team failure.

Why it fails: Servant leaders shield the team and address failure through coaching and system improvement, not escalation to the board. Reporting failures upward describes a governance or audit accountability path, which applies when executive oversight of delivery outcomes is formally required.

To command and control the team.

Why it fails: Command and control contradicts servant leadership, which shifts authority to the team and has the leader serve its needs by clearing blockers and fostering growth. Command and control describes a traditional directive manager, appropriate where strict hierarchical oversight, not self-organisation, is the operating model.

To make all technical decisions.

Why it fails: A servant leader removes impediments and coaches the team so members own technical decisions themselves; making them all concentrates authority and blocks self-organisation. It would fit a command-and-control or technical-lead role, not the servant-leadership stance Agile teams rely on.

Report the developer to HR.

Why it fails: Escalating to HR bypasses the team's own coaching responsibility and treats a skills gap as misconduct. It is tempting when frustration is high, but HR handles conduct and policy breaches, not pairing technique; a PMI-ACP practitioner would coach or pair the developer directly.

Force the developer to pair against their will.

Why it fails: Coercing pairing ignores the developer's concerns and damages trust without addressing the underlying skill gap. It is tempting because pairing is a team standard, but agile coaching requires consent and support; forcing compliance is not how norms are adopted.

Ask them to work alone until they are more comfortable.

Why it fails: Isolating the developer removes the very practice they must learn and lets the team avoid the problem. It is tempting as a low-conflict pause, but pairing is a team norm; the correct action is supported coaching and gradual pairing, not exemption from it.

Let the team struggle indefinitely without guidance.

Why it fails: Leaving the team to flounder with no coaching or boundary-setting abandons the servant leader's duty to remove impediments, so the confusion persists. Allowing teams to struggle briefly can build capability, but indefinite struggle without guidance is neglect; the leader should facilitate agreement on who decides what.

Make all decisions for the team.

Why it fails: Deciding everything centrally makes the servant leader the bottleneck and strips the team of the autonomy that clarifies ownership. A servant leader removes impediments and coaches the team towards self-organisation; directive decision-making is appropriate only in genuine emergencies or when the team is newly formed and lacks context.

Ask the client to make every decision.

Why it fails: Delegating every decision to the client removes the team's ownership of its own work and recreates the confusion about authority rather than resolving it. Client involvement is right for prioritising backlog value and accepting outcomes, but not for deciding how the team organises and executes its tasks.

Fire the individual.

Why it fails: This is not a collaborative leadership action.

Ignore it since the individual is productive.

Why it fails: Tolerating the hoarding lets the single point of failure persist and blocks the team's self-organising flow. It tempts because the individual's output looks strong on velocity charts, but agile practise values collective capability over individual throughput, so the behaviour must be addressed directly.

Promote the high-performer to a lead role.

Why it fails: A lead role formalises the bottleneck rather than removing it, since the individual keeps sole ownership of critical knowledge. It tempts because promotion rewards productivity, yet the agile remedy is pairing, mob programming and shared ownership so knowledge spreads across the team.

Ask them to provide their own plan.

Why it fails: Asking the stakeholder to produce their own plan transfers the team's planning responsibility and yields no shared, prioritised backlog. It is tempting as a way to surface their underlying priorities, but agile practice has the team own estimation and planning, then communicate the rolling release forecast collaboratively.

Tell them to wait for the final product.

Why it fails: Deferring the stakeholder until the final product withholds the roadmap and release forecast they legitimately need for planning, damaging transparency. It is tempting when scope is genuinely uncertain, but agile answers uncertainty with a prioritised backlog and iterative release plan, not silence until delivery.

Create a detailed plan to satisfy them.

Why it fails: Agile teams plan in iterations, so a fixed six-month detailed plan contradicts empirical delivery; the stakeholder needs a product roadmap with rolling-wave refinement instead. It tempts because detailed plans suit predictive projects with stable, fully-elaborated scope, where baselining long-term schedules is genuinely correct.

Start asking all the questions yourself.

Why it fails: The Scrum Master or coach asking every question converts the stand-up into a status report to one person, removing team self-organisation and ownership. Facilitation by questioning suits a brand-new team still learning the format, not an experienced team that finds the ceremony wasteful.

Tell them they have to do it because it is required.

Why it fails: Mandating attendance addresses compliance, not the underlying dysfunction, so the waste persists and engagement drops further. Authority-based enforcement suits a contractual or regulatory obligation, whereas here the team's feedback signals the stand-up's purpose or format needs revisiting with them.

Cancel the stand-up.

Why it fails: Cancelling removes the inspect-and-adapt event that surfaces impediments and synchronises the team, leaving problems hidden. Stand-ups are abandoned only when work genuinely needs no daily coordination, such as a single-person effort, not when the team finds the current format ineffective.

Continue the current path to avoid missing the sprint deadline.

Why it fails: Persisting with a known-failing approach wastes the sprint and delivers unworkable increments, contradicting Agile's empirical inspect-and-adapt cycle. Continuing suits stable, validated designs where change carries real cost; here the team already knows the approach cannot succeed.

Hide the issue and fix it next sprint.

Why it fails: Concealing the problem breaches transparency, the foundation of Agile's empirical process, and defers rework into a later sprint. Deferring suits low-impact cosmetic items logged in the backlog, not a blocking technical failure that invalidates the current sprint's approach.

Blame the architect for the bad design.

Why it fails: Blaming the architect assigns fault rather than resolving the technical impasse, which stalls the sprint and violates Agile's focus on inspect-and-adapt. It is tempting when frustration peaks and accountability feels warranted, but the correct response is to swarm, spike or re-plan with the team.

Tell them to work faster.

Why it fails: Telling the team to work faster addresses none of the systemic causes — unclear acceptance criteria, oversized stories or hidden dependencies — and treats a flow problem as a motivation problem. It is tempting because speed sounds like the obvious fix, and would be right only if the team were deliberately pacing slowly despite clear, small, ready work.

Assign more work to fill their time.

Why it fails: Assigning more work increases pressure and worsens the unfinished-stories problem, contradicting Agile's sustainable-pace principle and hiding the real constraint. It is tempting because idle capacity looks wasteful, and would be appropriate only when the team is genuinely underutilised and has proven it can absorb additional scope.

Extend the sprint.

Why it fails: Extending the sprint merely stretches the same timebox, masking the underlying impediment and delaying feedback rather than addressing why stories remain unfinished. It is tempting because more calendar time feels like relief, and would be correct only when scope is genuinely fixed and the team's capacity estimate was demonstrably wrong.

The team always completes 100% of the work.

Why it fails: Completing 100% of committed work every iteration suggests scope is being kept safely small or padded, not that the team is healthy; healthy teams sometimes miss and learn. It tempts because consistent delivery looks like reliability, and a stable velocity is genuinely useful for release forecasting.

No one ever disagrees.

Why it fails: Absent disagreement signals avoidance or suppressed dissent, not health; agile teams surface conflict over ideas to improve decisions. This option is tempting because harmony feels pleasant, yet psychological safety is demonstrated by productive debate. A healthy team disagrees constructively and resolves it.

The team follows the manager's instructions.

Why it fails: Deferring to a manager's instructions describes a command-and-control team, whereas healthy agile teams self-organise and decide how to do the work themselves. It tempts because clear direction does prevent chaos, and following a manager is legitimate where a directive, non-agile governance model is genuinely in force.

Replacing people faster.

Why it fails: Replacing leavers faster treats the symptom, not the cause; the servant leader must remove the impediments driving attrition, such as unsustainable pace or unresolved conflict. Rapid backfilling suits a stable, well-understood process where demand is predictable and skills are interchangeable, not a team whose turnover signals systemic dysfunction.

Lowering the performance expectations.

Why it fails: Lowering performance expectations removes the team's shared standard rather than addressing the causes of turnover, such as workload pressure, unclear goals or lack of support. It is tempting when a servant leader wants to relieve stress, but reducing expectations is correct only where targets were genuinely unachievable, not as a retention response.

Hiring more senior developers.

Why it fails: Hiring senior developers does not address why people leave; the servant leader should investigate and remove the root causes of attrition. Recruiting seniority is the right lever when capability gaps, not retention, limit delivery — for example, a team lacking architectural experience on a technically demanding product.

To satisfy auditors.

Why it fails: Transparency exists so teams and stakeholders can inspect progress, impediments and decisions, enabling empirical adaptation. Framing it as audit compliance inverts that purpose: it serves external verification, not internal self-correction. Auditors may benefit incidentally, but satisfying them is a governance by-product, never the reason Agile prescribes transparency.

To make the team work harder.

Why it fails: Transparency exposes progress, impediments and decisions so inspection and adaptation can occur; it does not increase effort or productivity. It is tempting because visible work can motivate teams, and would be correct if the goal were boosting output rather than enabling empirical process control.

So everyone knows who to blame.

Why it fails: Transparency makes work, progress and impediments visible so the team can inspect and adapt; it is not a mechanism for assigning blame, which destroys the safety Agile depends on. Blame-oriented reporting is tempting where governance demands accountability, but that is a management concern, not Agile transparency.