Foundations OF Agile practice questions

Requiring a signature for every small change

Why wrong: This is bureaucratic, not agile.

Strict adherence to a detailed yearly budget

Why wrong: This is traditional, not agile governance.

The type of software used for scheduling

Why wrong: Tools are not the primary driver of agility.

The name of the project manager

Why wrong: This is irrelevant to team agility.

Starting the development of the next major release.

Why wrong: This is not the focus of the Transition phase.

multi_select

Why wrong: ...

Writing all the requirements documentation for the next phase.

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

multi_select

Why wrong: ...

Conducting a final design review with external auditors.

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

It eliminates the need for project managers

Why wrong: Project management is still required, though the role may evolve.

It requires less documentation than waterfall

Why wrong: Documentation needs are determined by context, not just the delivery approach.

It ensures that all team members are always busy

Why wrong: Utilization is not the goal; throughput and value delivery are.

It guarantees that no changes will be made to requirements

Why wrong: The opposite is true; iteration expects and welcomes change.

Extend the sprint duration to allow more time for analysis

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

Switch to a full Kanban system without any planning

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

Mandate a strict waterfall phase gate review

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

Outsource the technical debt resolution to a different team

Why wrong: The original team is best equipped to resolve their own technical debt.

Ignore the debt until the project is near completion

Why wrong: This risks massive system failure at the end of the project.

Create a separate 'technical debt sprint' once a year

Why wrong: This delays the problem rather than integrating quality into daily work.

Hire a dedicated business analyst to write detailed documentation

Why wrong: This adds a layer of indirect communication rather than improving direct collaboration.

Lock down the scope for the next six months

Why wrong: Locking scope is a waterfall practice that conflicts with Agile's need for adaptability.

Ignore the stakeholders until the product increment is finished

Why wrong: Ignoring stakeholders contradicts the principle of stakeholder collaboration.

Wait for the end of the year to reassess

Why wrong: Delaying adaptation increases risk and wasted effort.

Ask the stakeholders to force the team to continue

Why wrong: This ignores the team's professional expertise and the reality of the situation.

Stick to the original plan to show commitment

Why wrong: Rigid adherence to an invalid plan results in poor product outcomes.

Copy the processes of the most successful competitors

Why wrong: Context matters; copying others' processes without understanding context is a mistake.

Follow the Scrum guide verbatim

Why wrong: DA encourages tailoring, not dogmatic adherence.

Focus exclusively on speed of delivery

Why wrong: Quality and value delivery are just as important as speed.

The tenure of the team members

Why wrong: While helpful, it is not the primary driver for lifecycle selection.

The total budget allocated to the project

Why wrong: Budget is a constraint, not a determinant of the delivery lifecycle.

The seniority of the stakeholders

Why wrong: Stakeholder seniority does not dictate the appropriate work lifecycle.

Eliminating all documentation throughout the lifecycle

Why wrong: Agile does not forbid documentation, it just prioritizes working software.

Strict adherence to the project charter

Why wrong: This is a traditional project management practice, not an Agile mindset.

Reducing the team size to improve velocity

Why wrong: Team size is a structural decision, not a primary mindset shift.

Use automated dashboards as the only source of feedback

Why wrong: Tools are helpful, but human feedback is essential.

Collect feedback only at the end of the project

Why wrong: Late feedback is too expensive to act upon.

Limit feedback to the internal team members only

Why wrong: Internal feedback is insufficient; external stakeholder input is critical.

To replace the need for project manager oversight

Why wrong: It helps manage quality but does not remove the need for management.

To tell the team how long a task should take

Why wrong: DoD defines quality, not duration.

To act as a contract for external vendors

Why wrong: It is an internal team quality standard.

To avoid all documentation

Why wrong: Documentation is managed, not avoided.

To ensure the project manager has total control

Why wrong: Control is distributed in Agile teams.

To allow the team to work on different projects simultaneously

Why wrong: Focus is better than multitasking.

Predictive planning is not allowed in Disciplined Agile

Why wrong: Predictive is one of many options in the DA toolkit.

Predictive planning is better for high-uncertainty projects

Why wrong: Predictive planning fails in high-uncertainty environments.

Adaptive planning is always faster than predictive

Why wrong: Speed depends on the context and complexity.

To force team members to work faster

Why wrong: Lean focuses on flow, not forcing individuals to work faster.

To replace all agile practices with kanban

Why wrong: Kanban is a lean practice, not a replacement for agile.

To increase the number of team meetings

Why wrong: Unnecessary meetings are considered 'waste' (muda).

Creating a detailed project plan for the next 2 years

Why wrong: This is a waterfall/predictive practice.

Requiring all changes to go through a formal committee

Why wrong: This is a bureaucratic/traditional practice.

Assigning tasks to individuals by the manager

Why wrong: Agile teams prefer self-selection of tasks.

Mandate that all teams use the exact same tool

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

Reduce the number of meetings for the teams

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

Assign a single project manager to control all communication

Why wrong: This creates bottlenecks and removes autonomy.

A set of strict, compliance-driven checkpoints

Why wrong: This is traditional, heavy governance.

Something that happens only during the final release

Why wrong: Governance is continuous, not a one-time event.

The responsibility of a separate audit department

Why wrong: Governance is a team responsibility in DA.

Follow the original plan strictly to reduce risk

Why wrong: Sticking to a plan in high uncertainty is a high-risk strategy.

Outsource the uncertain parts of the project

Why wrong: Outsourcing doesn't resolve the underlying uncertainty.

Delay the uncertain work until the end of the project

Why wrong: Delaying high-risk work makes it harder to fix later.