Foundations OF Agile practice questions

Mandate that all teams use the exact same tool

Why it fails: While helpful, it is not the primary coordination concept in DAD.

Reduce the number of meetings for the teams

Why it fails: Coordination often requires effective, well-planned meetings.

Assign a single project manager to control all communication

Why it fails: This creates bottlenecks and removes autonomy.

Requiring a signature for every small change

Why it fails: This is bureaucratic, not agile.

Strict adherence to a detailed yearly budget

Why it fails: This is traditional, not agile governance.

The type of software used for scheduling

Why it fails: Tools are not the primary driver of agility.

The name of the project manager

Why it fails: This is irrelevant to team agility.

The team works longer hours

Why it fails: Small Releases shorten feedback cycles and reduce deployment risk; they do not extend working hours. Longer hours describe crunch, which small releases actively reduce by keeping changes incremental. The benefit sought is faster feedback, not increased effort.

Increased complexity of the release process

Why it fails: Small Releases deliberately simplify deployment by shrinking change size, lowering coordination and rollback effort. Increased complexity contradicts that aim. Complexity grows with large, infrequent releases, so this describes the problem small releases solve, not a benefit.

Increased documentation requirements

Why it fails: Increased documentation requirements contradict Small Releases, which reduce the documentation overhead tied to each deployment by shrinking the change set. It is tempting because regulated or audited environments genuinely demand thorough records, and heavier documentation would be the right answer where compliance evidence per release is the stated goal.

Maintain the original project plan in the enterprise scheduling tool.

Why it fails: Static plans do not provide true visibility in an agile, changing environment.

Schedule weekly steering committee meetings for every project.

Why it fails: This is a traditional, high-overhead approach.

Require daily detailed status reports from every developer.

Why it fails: This creates high overhead and reduces productivity.

Starting the development of the next major release.

Why it fails: This is not the focus of the Transition phase.

multi_select

Why it fails: ...

Writing all the requirements documentation for the next phase.

Why it fails: DA minimizes documentation and favors just-in-time delivery.

multi_select

Why it fails: ...

Conducting a final design review with external auditors.

Why it fails: Design reviews happen throughout the lifecycle, not just at transition.

Increase the frequency of status reports to management.

Why it fails: More status reports do not improve coordination within the team; they add bureaucracy and can exacerbate silos by focusing on upward reporting rather than peer collaboration. DA emphasizes team-level communication and transparency, not management reporting as a coordination mechanism.

Implement a 'Scrum of Scrums' meeting with representatives from each location.

Why it fails: Scrum of Scrums is a scaling technique for multiple teams, not primarily for coordinating locations within one team. While it can help, it adds overhead and may not address the root cause of silos within a single distributed team. DA suggests more direct communication and tooling for distributed teams.

Require all team members to relocate to a single location.

Why it fails: While co-location can improve communication, it is often impractical and not a DA strategy for distributed teams. DA acknowledges that distribution is a reality and provides ways to work effectively without forcing relocation. This option is unrealistic and ignores the context.

It eliminates the need for project managers

Why it fails: Iterative delivery still needs coordination, so project managers are not removed; their focus shifts to facilitating increments and removing blockers. It is tempting because self-organising teams sound manager-free, but the actual benefit is earlier delivery and feedback, not the elimination of the management role.

It requires less documentation than waterfall

Why it fails: Iterative delivery does not reduce documentation relative to waterfall; it typically adds artefacts such as backlogs and increment reviews. It is tempting because shorter cycles feel lighter, but the actual benefit is earlier feedback and the ability to adjust scope as understanding grows, not less paperwork.

It ensures that all team members are always busy

Why it fails: Iterative delivery does not keep everyone continuously occupied; teams still wait on dependencies, reviews and integration. It is tempting because frequent increments appear to smooth workload, but the real benefit is early, incremental delivery of value with feedback, not utilisation of every team member at all times.

It guarantees that no changes will be made to requirements

Why it fails: Iterative delivery deliberately welcomes requirement change between increments, so freezing requirements contradicts its purpose. It is tempting because stable scope sounds like reduced risk, but the genuine benefit is delivering working increments early so feedback can reshape later work before full build completion.

Extend the sprint duration to allow more time for analysis

Why it fails: Extending sprints often leads to more analysis paralysis rather than resolution.

Switch to a full Kanban system without any planning

Why it fails: Even Kanban requires some level of planning and prioritization.

Mandate a strict waterfall phase gate review

Why it fails: This increases delay and does not address the cause of paralysis.

Outsource the technical debt resolution to a different team

Why it fails: Outsourcing separates debt repayment from the team that incurred it, so the codebase knowledge and ownership needed to fix root causes stay elsewhere; Disciplined Agile places repayment with the owning team. It is tempting when the team lacks specialist skills, which suits isolated legacy remediation, not ongoing iteration work.

Ignore the debt until the project is near completion

Why it fails: Ignoring debt until near completion lets interest accumulate, raising rework and defect rates precisely when schedule pressure peaks; Disciplined Agile expects debt to be made visible and repaid each iteration. It is tempting when deadlines dominate, but deferral is only defensible for consciously accepted, low-impact debt.

Create a separate 'technical debt sprint' once a year

Why it fails: Deferring debt to an annual sprint leaves it compounding across every iteration, contradicting Disciplined Agile's guidance to address debt continuously within the team's workflow. It is tempting because a dedicated sprint gives focused capacity, which suits large-scale remediation programmes rather than routine iteration-level repayment.

Hire a dedicated business analyst to write detailed documentation

Why it fails: Disciplined Agile favours lightweight, collaborative requirement capture with continuous stakeholder involvement, not documentation-heavy handoffs. A dedicated analyst writing detailed specs adds delay and distance between team and stakeholders, so unclear requirements persist. This role suits regulated, contract-driven contexts where formal traceability is mandated.

Lock down the scope for the next six months

Why it fails: Freezing scope for six months prevents the team from responding to clarified or changing requirements, which Disciplined Agile expects throughout delivery. Scope creep stems from unclear requirements, and locking scope addresses timing, not clarity. Fixed-scope baselines suit contractual, plan-driven engagements with stable, well-understood requirements.

Ignore the stakeholders until the product increment is finished

Why it fails: Ignoring stakeholders removes the feedback loop that resolves ambiguity, so requirements stay unclear and scope creep continues unchecked. Disciplined Agile deliberately keeps stakeholders engaged throughout delivery. Deferring engagement suits only genuinely disinterested parties with no decision rights over the increment.

Wait for the end of the year to reassess

Why it fails: Deferring reassessment to year-end leaves the team executing a plan the market has already invalidated, accruing wasted spend. Reassessment belongs in the next review cycle once change is identified. Waiting suits stable portfolios where annual planning cycles remain valid and no triggering event has occurred.

Ask the stakeholders to force the team to continue

Why it fails: Directing stakeholders to compel continuation transfers the decision without addressing the invalidity, producing sunk-cost delivery against a dead business case. Stakeholder authority is properly used to approve a revised plan; forcing continuation suits only cosmetic schedule pressure, not genuine market invalidation.

Stick to the original plan to show commitment

Why it fails: Persisting with an unviable plan wastes budget and delivers obsolete outcomes, since market change invalidates the original business case. Commitment is demonstrated through transparent replanning; sticking rigidly suits stable environments where the baseline assumptions still hold and variance is minor.

Copy the processes of the most successful competitors

Why it fails: Copying competitors' processes ignores context: the Disciplined Agile Mindset treats process as something you tailor to your own team's situation, not transplant. It is tempting because benchmarking rivals is genuinely useful for identifying improvement ideas, but that is inspiration, not adoption of their process wholesale.

Follow the Scrum guide verbatim

Why it fails: Following the Scrum guide verbatim fixes one prescribed method regardless of context, whereas the Disciplined Agile Mindset expects teams to choose and tailor their way of working. It is tempting because Scrum is genuinely a proven framework for many teams, but the mindset rejects treating any guide as mandatory.

Focus exclusively on speed of delivery

Why it fails: Speed alone is one dimension; the mindset weighs process against value, risk and team context rather than optimising a single metric. It is tempting because faster delivery is genuinely a goal in competitive markets, yet pursuing it exclusively sacrifices the deliberate choice the mindset requires.

The tenure of the team members

Why it fails: Team tenure does not determine lifecycle choice; the deciding axis is whether requirements are stable and well understood. A long-tenured team can still run predictive projects. Tenure would matter when selecting team composition or estimating velocity, not when choosing between adaptive and predictive approaches.

The total budget allocated to the project

Why it fails: Budget size does not dictate lifecycle; scope stability and requirement volatility do. Large budgets routinely fund predictive programmes, and small ones can be adaptive. Budget would be the correct criterion when deciding procurement approach or funding gates, not the adaptive-versus-predictive selection itself.

The seniority of the stakeholders

Why it fails: Stakeholder seniority is irrelevant to lifecycle selection; the choice depends on solution uncertainty and requirements stability, not who is sponsoring it. It is tempting because senior stakeholders often influence project decisions, and would matter for governance or approval, not methodology selection.

Eliminating all documentation throughout the lifecycle

Why it fails: Disciplined Agile tailors documentation to context rather than eliminating it; regulatory, audit or coordination needs still demand artefacts. The option tempts as a reaction against heavyweight traditional documents, but the critical first-iteration shift is embracing deliberate agility and choosing your WoW, not removing all records.

Strict adherence to the project charter

Why it fails: Disciplined Agile treats the charter as an evolving artefact, refining scope as the team learns; rigid adherence blocks the inspect-and-adapt mindset. It tempts because traditional projects baseline scope formally. The critical shift is embracing deliberate agility and choosing the team's way of working, not defending an initial charter.

Reducing the team size to improve velocity

Why it fails: Shrinking the team does not create an agile mindset and can reduce the cross-functional skills Disciplined Agile relies on. It tempts because small teams often communicate faster. The critical first-iteration shift is embracing deliberate agility, self-organisation and choosing the team's way of working, not headcount reduction.

Use automated dashboards as the only source of feedback

Why it fails: Automated dashboards report metrics, not the qualitative insight Continuous Feedback requires; they cannot capture peer observations or improvement dialogue. Dashboards suit monitoring delivery performance, where trend visibility across pipelines is the goal. Here the scenario demands iterative human input, which telemetry alone cannot supply.

Collect feedback only at the end of the project

Why it fails: Gathering feedback only at project end prevents the team from acting on insights while work is still in progress, so defects and misalignments persist. End-of-project collection suits formal retrospectives or post-implementation reviews, where no further iteration is planned.

Limit feedback to the internal team members only

Why it fails: Restricting feedback to internal team members excludes customers and end users, whose input Continuous Feedback explicitly gathers to validate working software. It is tempting because internal retrospectives suit team-process improvements, but that is a different practise. Continuous Feedback requires external stakeholder perspectives, which this option omits entirely.

To replace the need for project manager oversight

Why it fails: The Definition of Done is a shared quality checklist that determines when an increment is complete; it does not remove or replace project manager oversight, which remains for coordination and impediment removal. It would be relevant when agreeing team quality standards, not for governing management responsibilities.

To tell the team how long a task should take

Why it fails: The Definition of Done states the quality criteria an increment must satisfy to be considered complete; it says nothing about task duration, which is handled through estimation and velocity. It would be the correct artefact when the team needs a shared quality bar, not a scheduling mechanism.

To act as a contract for external vendors

Why it fails: The Definition of Done is an internal team agreement on quality criteria for completed work, not a contractual instrument binding external vendors. Contracts with suppliers use statements of work and service-level agreements. A DoD would be the right artefact when the team itself needs a shared completion standard.

To avoid all documentation

Why it fails: Iterative development repeats cycles to refine a solution through feedback, not to eliminate documentation; documentation is still produced as required. It tempts because iteration reduces reliance on up-front specification, and would be correct if the objective were responding to evolving requirements.

To ensure the project manager has total control

Why it fails: Iterative development delivers working increments refined by feedback; it does not concentrate control in the project manager. It tempts because iteration requires active governance, and would be correct if the objective were tighter managerial oversight of delivery.

To allow the team to work on different projects simultaneously

Why it fails: Iterative development repeats cycles of build, test and refine to converge on requirements within one project; it does not enable parallel work across separate projects, which is programme or portfolio management. It is tempting because iterations are time-boxed, so teams assume the freed capacity supports concurrent initiatives.

Predictive planning is not allowed in Disciplined Agile

Why it fails: Predictive planning is permitted in Disciplined Agile; it is chosen when requirements are stable and work is well understood, while adaptive planning suits exploratory work. The option is tempting because Disciplined Agile favours adaptive approaches, but it does not prohibit predictive planning outright.

Predictive planning is better for high-uncertainty projects

Why it fails: Predictive planning suits stable, well-understood scope where baselines and change control work; adaptive suits high-uncertainty work. The stem asks how the two differ, not which copes with uncertainty, so this reverses the actual axis. It tempts because adaptive's iterative nature is often associated with volatile requirements.

Adaptive planning is always faster than predictive

Why it fails: Adaptive planning delivers value in short increments but carries no inherent speed advantage; predictive planning can complete faster when scope is fixed and known. The distinction concerns how scope and schedule are fixed, not delivery velocity. It tempts because iterative releases feel quicker, yet the stem asks for the defining difference.

To force team members to work faster

Why it fails: Lean addresses process waste and flow efficiency, not employee pace; compressing work without removing non-value-adding steps degrades quality. Its purpose is identifying value and eliminating muda. A team whose delivery is slowed by handoffs, rework or waiting would correctly apply Lean to those bottlenecks.

To replace all agile practices with kanban

Why it fails: Lean targets eliminating waste and maximising delivered value through continuous flow, not substituting kanban for agile practices; kanban is merely one visualisation technique Lean may inform. A team adopting kanban to manage work-in-progress limits while retaining agile ceremonies would find this framing apt.

To increase the number of team meetings

Why it fails: Lean seeks to reduce non-value-adding activity, and meetings are overhead unless they directly produce value; adding them contradicts the goal. It targets waste such as overproduction and waiting. A team drowning in coordination overhead would use Lean to cut meetings, not multiply them.