Select Two (Multi-Select) Questions

Increase the number of project managers

Why it fails: Adding project managers increases coordination overhead without changing team structure or delivery flow, so it does not scale Agile. It tempts because coordination roles appear necessary at scale, yet frameworks such as SAFe scale through aligned teams, shared backlogs and cadence, not extra managers.

Ensure each team uses a different framework

Why it fails: Differing frameworks per team fragment terminology, ceremonies and backlog structure, preventing cross-team dependency management and shared cadence. It is tempting because framework diversity suits autonomous teams with unrelated products, where no shared planning or integration is required.

The ability to perfectly match supply with demand.

Why it fails: Push systems schedule production against forecasts, so they cannot perfectly match supply with demand; that alignment is what pull systems achieve through actual demand signals. Perfect matching is the goal, not a pitfall, which makes this tempting as an idealised benefit rather than a documented shortcoming.

High levels of team satisfaction.

Why it fails: Push systems typically produce inventory buffers, idle work and blame cultures, which erode rather than raise team satisfaction. High satisfaction is a genuine outcome of pull systems, where demand-driven flow reduces overproduction pressure, so the option describes a benefit of the alternative approach.

Automatic elimination of defects.

Why it fails: Push systems cannot automatically eliminate defects; they signal abnormalities for human action, so defects are detected rather than removed. It tempts because push systems do surface errors promptly, but elimination requires corrective work, which is the pull system's replenishment discipline, not automatic.

Mandatory 12-hour work days.

Why it fails: Lean treats excessive overtime as waste that harms quality, safety and morale, so mandating 12-hour days contradicts respect for people and continuous improvement. It is tempting because long hours can look like commitment, and extended shifts would be correct only where demand genuinely justifies them without eroding sustainable flow.

Centralized, hierarchical decision-making.

Why it fails: Lean pushes decision-making to the people closest to the work through respect for people and continuous improvement, so centralised hierarchy contradicts its principles. It is tempting because clear authority structures appear orderly, and centralisation would be correct where standardisation and tight control outweigh local autonomy.

A mandate from upper management to cut costs.

Why it fails: Cost-cutting mandates don't supply the process knowledge, cross-functional participation or current-state data a mapping session requires; they can even distort it. A mandate is genuinely useful for authorising dedicated staff time and overcoming departmental resistance, but the session itself needs a defined product family and scope, not a savings target.

An external facilitator to enforce rigid rules.

Why it fails: An external facilitator imposing rigid rules can suppress the cross-functional candour that mapping depends on; the essential component is a knowledgeable facilitator, not an authoritarian outsider. It is tempting because neutral facilitation genuinely helps, and would be correct if the question asked how to reduce internal bias during workshops.

A requirement to automate the whole process.

Why it fails: Automating the entire process is an outcome some teams pursue afterwards, not a session component; mapping must capture the current state including manual and wasteful steps. It is tempting because automation is a common improvement goal, and would be correct if the question asked about a target-state design objective.

The preferred color of the workspace

Why it fails: Workspace colour is cosmetic and has no bearing on lifecycle selection. Appearance settings matter for user adoption and branding once a lifecycle is chosen, but the decision rests on release frequency, governance and team structure instead.

The office location of the stakeholders

Why it fails: Stakeholder office location does not determine lifecycle mechanics; distributed teams can follow any model. Location influences communication and ceremony scheduling, which is relevant when planning collaboration, but lifecycle choice depends on delivery cadence, risk and regulatory constraints.

Mandating a fixed-price contract

Why it fails: Fixed-price contracts impose a single agreed cost regardless of delivered scope, which contradicts Lean's flow-based, pull-driven delivery where scope and value are decided incrementally. It is tempting because fixed pricing controls budget, and it would suit a well-defined, stable-scope procurement where cost certainty outweighs flexibility.

Forcing team members to work long hours

Why it fails: Long hours increase defect rates and burnout, directly opposing Lean's respect-for-people principle and its emphasis on sustainable pace and eliminating waste. It is tempting because extended effort appears to accelerate delivery, and it would fit a short, exceptional crisis push rather than routine DA work.

Maximizing the number of features in a release

Why it fails: Maximising features per release contradicts Lean's core aim of eliminating waste, since excess scope creates partially completed work and delays feedback. It is tempting because batching features can reduce deployment overhead in plan-driven delivery, where a fixed, fully specified release is contractually required and iterative value delivery is not the objective.

Improved team collaboration.

Why it fails: Unaddressed bottlenecks create pressure, blame and workarounds between teams, degrading collaboration rather than improving it. Improved collaboration is tempting because shared problem-solving sometimes emerges under strain, but that is a deliberate intervention outcome, not a passive side effect of neglect.

Faster delivery of high-priority items.

Why it fails: Bottlenecks throttle the whole process, so high-priority items queue behind constrained capacity and delivery slows. Faster delivery is tempting because prioritisation and expediting can accelerate selected items, but that requires actively resolving the constraint, not leaving it unaddressed.

A natural reduction in project costs.

Why it fails: Unresolved bottlenecks constrain throughput, so work queues and carrying costs grow; costs do not naturally fall. Reduced expenditure is tempting because removing constraint-related overtime or expediting fees can cut spend, but that only follows deliberate remediation, not neglect.

Budget approval meeting

Why it fails: Budget approval is a financial governance gate owned by sponsors or finance, not a recurring team ceremony such as sprint planning, daily standup, review or retrospective. It is tempting because it is a scheduled meeting with attendees, but it lacks the inspect-and-adapt purpose that defines Agile ceremonies.

Project planning meeting (held once at the start)

Why it fails: A one-off upfront planning meeting contradicts Agile's iterative approach, where planning recurs each sprint rather than being fixed at project start. It is tempting because traditional waterfall projects begin with a single comprehensive planning phase, but Agile ceremonies repeat every iteration to incorporate feedback.

Weekly status report to executives

Why it fails: Executive status reporting is a governance and stakeholder communication activity, not a timeboxed team event with a defined purpose such as sprint planning, daily standup, review or retrospective. It is tempting because regular reporting cadences feel ceremonial, but Agile ceremonies are team-level inspect-and-adapt events.

Code reviews

Why it fails: Code reviews are deliberate quality work that catches defects early, not muda; the seven wastes include partially done work, extra features, and handoffs. Reviews become waste only when excessive or unstructured, which is not the general case.

Team collaboration

Why it fails: Team collaboration is essential communication that reduces rework and misalignment, so it is not muda. The wastes are waiting, handoffs, and context switching; collaboration would only count as waste if it were excessive, unplanned meetings displacing delivery work.

Outsourcing non-core tasks to a specialized vendor.

Why it fails: Outsourcing moves work across organisational boundaries, creating additional handoffs between vendor and internal teams. It tempts because offloading non-core work can reduce internal workload, but handoff count is about transfer points, not task ownership; the correct approaches eliminate transfers within the value stream instead.

Adding an extra layer of management to monitor transfers.

Why it fails: Adding management layers inserts further approval and transfer points, increasing handoffs rather than reducing them. It tempts because governance feels like control, but the goal is fewer transfers between people or teams; the correct approaches restructure work so one person or team completes a task end to end.

The color of the team's office walls.

Why it fails: Office wall colour has no bearing on lifecycle selection, which depends on delivery cadence, solution complexity and organisational constraints. It is tempting only as an obviously irrelevant distractor, yet it tests whether candidates recognise that lifecycle choice is driven by project and technical factors rather than workplace aesthetics.

The salary of the team members.

Why it fails: Team salaries are a cost consideration, not a determinant of which lifecycle the DA toolkit prescribes; lifecycle selection turns on factors such as project size, risk and delivery approach. It is tempting because budget clearly matters to projects, but compensation levels do not alter the recommended lifecycle.

Deferring testing until the end of the project.

Why it fails: Deferring testing to the end lets defects accumulate undetected, contradicting Build Quality In, which requires testing continuously as work is completed. It is tempting because end-of-project testing feels like thorough verification, and it would fit a stage-gated waterfall approach rather than Lean continuous delivery.

Relying on manual testing by an external team.

Why it fails: External manual testing separates quality from the team creating the work and delays feedback, so defects are found late rather than prevented. It is tempting because independent verification sounds rigorous, and it would be appropriate where regulatory separation of duties demands an independent test function.

Teams should rely on external consultants to define their process.

Why it fails: Disciplined Agile expects the team itself to own and evolve its Way of Working through guided continuous improvement, so outsourcing that definition to consultants removes the team's ownership. Consultants can advise, but relying on them to define the process would be appropriate only when the team genuinely lacks the capability to self-organise.

Teams should adopt a new framework every quarter to stay modern.

Why it fails: Disciplined Agile expects teams to inspect and adapt their Way of Working incrementally, guided by context and retrospectives, not to swap frameworks on a fixed quarterly cadence. Replacing the framework every quarter discards the empirical learning DA relies on; wholesale framework replacement suits a deliberate, evidence-driven pivot, not routine modernisation.

Teams should skip retrospectives to maximize delivery time.

Why it fails: Retrospectives are the mechanism by which a team inspects and adapts its Way of Working, so skipping them removes the very feedback loop that drives evolution. Dropping them would only make sense if another structured inspect-and-adapt ceremony were genuinely substituting for that learning.

Command and Control

Why it fails: Command and Control is a management style, not a DA governance aspect; governance covers decision rights, policies, standards and oversight of data and analytics assets. It is tempting because strong direction sounds like good governance, but centralised command conflicts with the federated accountability and stewardship structures governance requires.

Manual and heavy

Why it fails: Manual and heavy describes an implementation anti-pattern, not a governance aspect; governance instead demands automated, repeatable controls with clear ownership and auditability. It is tempting because immature governance often becomes manual and burdensome, but that burden is the symptom being remediated, not a characteristic to adopt.

The personal preference of the executive sponsor.

Why it fails: One sponsor's personal taste is not a tailoring factor; Disciplined Agile tailors to team size, geographic distribution, compliance regime, product type and organisational culture. Sponsor preference is tempting because executives wield authority, yet it would only be decisive when selecting between equally viable options during governance approval.

The specific software vendor of your project management tool.

Why it fails: Tool vendor does not shape team roles, ceremonies or lifecycle; Disciplined Agile tailors to team size, geographic distribution, compliance and product type. Vendor choice is an implementation detail, tempting because tooling feels foundational, yet it would only matter when selecting or integrating a specific ALM platform.

The time of year the project starts.

Why it fails: Calendar timing has no bearing on team structure, delivery cadence or governance; Disciplined Agile tailors to factors such as team size, distribution, compliance and product criticality. Start date is tempting because scheduling feels project-defining, yet it would only be relevant when planning release windows or fiscal constraints.

Increasing management oversight

Why it fails: Adding management oversight layers introduces approval gates and monitoring rather than removing the non-value-adding steps that process improvement targets. Oversight is warranted in control-critical or regulated processes where segregation of duties is mandatory, not as a general improvement mechanism.

Ignoring all feedback

Why it fails: Discarding feedback removes the defect data that process improvement depends on, so variation and root causes stay hidden. Feedback is deliberately solicited in improvement cycles such as DMAIC; ignoring it is the opposite of the analyse-and-improve intent.

Reducing team size

Why it fails: Cutting team size reduces capacity without altering the process itself, so the same steps and handoffs remain and throughput falls. Downsizing belongs to cost-reduction or resource-optimisation initiatives, not to process improvement, which targets flow, waste and cycle time.

Stakeholders only reading the final report

Why it fails: Reading a final report is passive, one-way communication after delivery, giving the team no opportunity to act on feedback. It is tempting because it is a form of stakeholder engagement, but Active Stakeholder Participation requires ongoing collaboration, such as reviewing each Increment and helping shape the Product Backlog.

Stakeholders dictating the team's internal coding style

Why it fails: Coding style is the Developers' technical decision; stakeholders dictating it removes the team's self-management and delivers no product value. It is tempting because it is direct involvement, but Active Stakeholder Participation concerns providing feedback on the product and collaborating on requirements, not prescribing internal engineering practise.

Stakeholders attending daily stand-up meetings

Why it fails: Stand-ups are the delivery team's internal coordination event; attendance alone supplies no product direction or feedback on the Increment. It is tempting because daily presence looks engaged, yet Active Stakeholder Participation means collaborating on requirements and reviewing working software, not observing team ceremonies.

Elimination of all documentation.

Why it fails: Iterative development still requires documentation, though often lighter and produced incrementally alongside each release; eliminating it entirely is neither a benefit nor accurate. It tempts because agile methods favour working software over comprehensive documentation, which is a shift in emphasis, not removal.

Guaranteed delivery of all original requirements on day one.

Why it fails: Iterative delivery releases working increments each cycle, so requirements evolve and are never fixed at the outset; guaranteeing all original requirements on day one contradicts that. It tempts because waterfall's upfront specification appears to promise complete scope, yet iterative trades fixed scope for adaptive, incremental value.

Reduced focus on software quality.

Why it fails: Iterative approaches deliberately raise quality through frequent testing, review and refactoring each cycle; reducing quality focus is a drawback, not a benefit. It tempts because rapid iterations can look like corners are cut, but the short feedback loops actually surface defects earlier than waterfall's single late test phase.

The code is fully documented

Why it fails: Thorough documentation signals deliberate design and maintainability, the opposite of debt. It tempts because documentation is often neglected, so its presence feels notable. Technical debt instead shows as undocumented, hard-to-change code, accumulated shortcuts, and rising defect or change-failure rates.

The team delivers features faster than ever before

Why it fails: Debt usually slows down development over time.

The team uses a new IDE for coding

Why it fails: Adopting a new IDE is a tooling preference with no bearing on accumulated design shortcuts or deferred rework. It tempts because unfamiliar tooling can feel like a codebase problem. Technical debt is evidenced by code smells, brittle tests, and slowing delivery, not by which editor the team uses.

They must be followed in a specific order.

Why it fails: Process Goals are selected and tailored by each team to suit its context, with no prescribed sequence; teams adopt them in whatever order fits. They would be the right concept when a team needs guiding agreements on how it works, not a mandated step-by-step method.

They eliminate the need for retrospectives.

Why it fails: Process Goals are the team's own agreed working agreements, reviewed and refined through retrospectives, so they cannot remove that feedback loop. They would be relevant when establishing how a team intends to collaborate, but they never replace the inspect-and-adapt ceremony that keeps those agreements current.

They are only for the Inception phase.

Why it fails: Process Goals apply across the whole delivery lifecycle, not just Inception; teams revisit them during construction and transition too. They would be the correct concept when establishing working agreements that persist throughout delivery, rather than a phase-specific checklist confined to initial planning.