Hard Difficulty Questions

It is cheaper to let teams choose their own.

Why it fails: Cost is not the toolkit's stated rationale; standardising one process across teams ignores that value delivery differs by context, so a single mandated workflow creates friction. It is tempting because shared tooling can reduce licensing and training spend, and would be correct where teams perform genuinely identical, repeatable work.

DA is a marketing tool that discourages standardization to sell more training.

Why it fails: DA is an open-source toolkit, not a commercial training product, so the profit motive is factually false; the guidance rests on context-dependent delivery. It is tempting because vendors do sometimes push frameworks to sell services, and that reasoning would be correct if DA were a paid certification scheme.

Standardization is technically impossible.

Why it fails: It is possible, just usually ineffective.

Force all teams to use the same lifecycle

Why it fails: Forcing one lifecycle across teams ignores that value streams differ in cadence, regulation and risk, so coordination collapses into a bottleneck at shared gates. It is tempting because a single process looks governable, and would be correct for a single team or where a regulatory mandate genuinely imposes one uniform lifecycle.

Appoint a single manager for all teams

Why it fails: A single manager for all teams centralises decision-making, so coordination becomes escalation and teams lose the local authority to align on shared outcomes. It is tempting because one accountable owner appears to guarantee consistency, and would be correct for a short, tightly coupled programme with a fixed end date.

Merge all teams into one large team

Why it fails: Merging teams into one large unit destroys the autonomy and independent delivery that coordination across teams exists to preserve, replacing alignment with a single backlog. It is tempting because it removes interface friction, and would be correct only where the work is genuinely one indivisible product with no separate ownership.

Assign it to a separate team

Why it fails: Isolating technical debt in a separate team removes it from the value streams that created it, so the debt is never addressed where it originated. It is tempting as a way to contain remediation effort, and would suit a dedicated platform team owning shared components, not enterprise-wide debt.

Ignore it until the project is over

Why it fails: Deferring debt until project completion lets interest compound: later remediation costs more and destabilises delivery. It is tempting because some teams do schedule a hardening phase, but that works only when debt is tracked continuously and repaid incrementally, not ignored.

Ban all technical debt

Why it fails: Banning technical debt outright is unenforceable and ignores that some debt is deliberately incurred for delivery speed, so it provides no handling mechanism. It is tempting as a zero-tolerance stance, and would suit a greenfield codebase with no legacy constraints, not an ongoing portfolio.

Switch to Kanban

Why it fails: Kanban manages flow within one team's existing process; it adds no mechanism for coordinating dependencies, funding or integration across multiple teams. It is the right choice when a single team wants to visualise and limit work in progress, not when the goal is scaling agile across the organisation.

Add a Program Manager

Why it fails: Adding a Program Manager introduces a coordinating role but changes no team structure, process or technical practice, so it cannot deliver the scaled agile capability DA describes. It suits programmes needing cross-team reporting and dependency tracking, not the foundational step of establishing disciplined delivery before scaling.

Implement SAFe immediately

Why it fails: SAFe is a prescriptive scaling framework applied after teams already practise disciplined agile delivery; adopting it first imposes structure on immature teams. It is the right choice for large enterprises needing portfolio-level alignment across many existing agile teams, not as the initial step when scaling efforts.

Increase the size of individual teams to 50+ members

Why it fails: DA keeps teams small, typically under ten to twelve people, because larger groups strain communication and self-organisation. It is tempting because scaling is often misread as enlarging teams, but DA scales by adding coordinated small teams, not by inflating headcount within one team.

Adopt a single framework like SAFe for all projects

Why it fails: Disciplined Agile advises choosing and tailoring a way of working rather than mandating one framework such as SAFe across every team. It is tempting because SAFe is a recognised scaling framework, but DA treats frameworks as options to blend contextually, not a single mandated standard.

Standardize all teams to use the exact same process

Why it fails: DA expects teams to tailor their way of working to context, so forcing identical processes contradicts its guidance. It is tempting because consistency appears to aid coordination at scale, but DA deliberately preserves variation across teams rather than imposing one uniform process.

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.

Hire more senior developers to review code.

Why it fails: Adding reviewers increases capacity but leaves the batch-and-queue handoff that creates the wait; Lean addresses the flow constraint, not headcount. Hiring senior developers suits a genuine skills shortage, whereas reducing review batch size and limiting work in progress shortens the queue itself.

Eliminate code reviews.

Why it fails: Removing reviews eliminates the queue but also the defect detection that reviews provide, so defects flow downstream and rework rises. Lean reduces wait time by limiting work in progress and balancing review capacity, not by deleting the control. Where reviews add no value at all, dropping them could be valid.

Schedule all reviews for the end of the week.

Why it fails: Batching reviews weekly enlarges the queue and lengthens feedback delay, worsening the very wait Lean seeks to remove. End-of-week scheduling suits periodic reporting or release gates, but continuous flow requires reviews to be pulled as soon as code is ready, keeping batch size small.

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.

Command and Control

Why it fails: Command and control centralises approval in a hierarchy, so teams cannot decide at the speed agile delivery requires and feedback loops stall. Agile governance pushes decisions to the lowest capable level with clear guardrails. Command and control fits stable, safety-critical operations needing strict uniformity.

Ad-hoc Decision Making

Why it fails: Ad-hoc decision making lacks defined ownership, escalation paths and guardrails, so decisions cannot be traced or repeated as the governance model scales. Agile governance still requires lightweight, explicit decision rights. Ad-hoc approaches suit small exploratory prototypes, not an organisation-wide transition.

Full Documentation

Why it fails: Full documentation freezes decisions into artefacts approved before work starts, which conflicts with agile governance that delegates authority to teams and revisits decisions as evidence emerges. Documentation supports audit and onboarding; it becomes the chosen approach in regulated, plan-driven environments demanding formal sign-off.

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.

Commit to the feature immediately and learn as they build

Why it fails: Committing immediately without understanding the stack removes the feedback loops that disciplined delivery depends on, so defects and rework accumulate. It is tempting because it appears decisive and fast, but discipline means validating assumptions through small experiments and reviews before scaling the commitment.

Reject the feature request until they are experts

Why it fails: Refusing work until the team is expert stalls delivery and ignores that disciplined practice means managing risk through spikes, pairing and incremental learning, not blocking. It is tempting as a way to avoid mistakes, but the disciplined approach is to timebox investigation and deliver in small, verified increments.

Ask management to assign an expert to do the work for them

Why it fails: Delegating to an expert leaves the team unable to maintain or extend the feature, so the knowledge gap persists and the work is not owned. It is tempting because experts deliver quickly and correctly; that is the right choice for a one-off critical fix, not for building a team's capability.

Portfolio Management

Why it fails: Portfolio management is high-level alignment.

Governance Framework

Why it fails: Governance ensures compliance, not lifecycle selection.

Team Roles

Why it fails: Roles define responsibility, not lifecycle.

Add more team members

Why it fails: Adding people increases coordination overhead and onboarding drag, which typically widens variability before throughput stabilises. It is tempting because extra capacity looks like a direct velocity fix, and would be correct when the team is genuinely understaffed against a stable, well-understood workload.

Increase WIP limits

Why it fails: Raising WIP limits lets more items start concurrently, increasing context switching and queueing that destabilise throughput rather than smoothing it. It is tempting because higher limits appear to permit progress, and would be right when the team is starved of work and limits are throttling legitimate parallel effort.

Stop all meetings

Why it fails: Cancelling all meetings removes the collaboration and feedback loops that surface and resolve blockers causing erratic delivery, so it does not optimise flow. It is tempting as a reaction to perceived meeting overhead, and would suit a team whose ceremony load genuinely exceeds the value those sessions deliver.

Their own speed

Why it fails: Prioritising the team's own speed ignores enterprise-wide outcomes, dependencies and governance that Enterprise Awareness demands. Teams must optimise for organisational value, not local velocity. Focusing on speed is appropriate within a single team's sprint execution, but it fails when decisions affect shared platforms or cross-team delivery.

The latest software tools

Why it fails: Tooling choice is a tactical decision; Enterprise Awareness requires understanding how the team's work fits organisational strategy, governance and other teams. Adopting the newest tools without that context can duplicate platforms or breach standards. Tool selection is relevant when optimising a specific delivery pipeline, not when framing enterprise alignment.

Their internal team dynamics

Why it fails: Enterprise Awareness concerns aligning team decisions with organisational goals, governance and shared strategy, not internal team dynamics. Focusing inward misses cross-team dependencies and enterprise priorities. Internal dynamics matter for team-level coaching or psychological safety work, which is a different domain from enterprise alignment.

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.

Choose a lifecycle that supports lightweight documentation only.

Why it fails: Regulated industries often require specific evidence that exceeds 'lightweight' definitions.

Minimize the number of roles to increase speed.

Why it fails: Reducing roles does not address compliance requirements.

Ignore the DA toolkit and stick to your existing Waterfall process.

Why it fails: This ignores the requirement to apply the DA toolkit for fit-for-purpose WoW.

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.

Write a full requirements document

Why it fails: DA favours lightweight, iterative scope exploration through conversations and modelling, not a comprehensive upfront requirements document, which assumes requirements can be captured before building. A full document suits plan-driven or low-uncertainty projects where scope is stable and contractual.

Delegate to the architecture team

Why it fails: Delegating scope exploration to architects removes the business and delivery stakeholders whose conversation DA requires, and architecture alone cannot establish intent or value. It would be appropriate for purely technical design decisions, not for exploring initial scope on a complex project.

Guess the requirements

Why it fails: Guessing replaces deliberate exploration with assumption, giving no validated understanding of scope or intent. DA instead recommends structured collaborative techniques such as interviews, workshops and example mapping. Guessing would only be defensible where requirements are trivially obvious and carry negligible delivery risk.

Rely solely on automated test cases as documentation

Why it fails: Automated tests capture executable behaviour, not the rationale, traceability or regulatory evidence high-criticality systems demand. It tempts teams avoiding duplicate effort, yet Disciplined Agile expects lightweight documentation recording decisions and compliance artefacts, which test cases alone cannot satisfy for audits.

No documentation is required as per Agile principles

Why it fails: Agile principles value working software over comprehensive documentation, not its absence; regulated medical software still requires traceable records. It tempts teams trimming overhead, but Disciplined Agile prescribes just enough documentation to satisfy governance, so omitting it entirely fails the compliance obligation.

Document everything in detail before starting

Why it fails: Upfront comprehensive documentation contradicts Disciplined Agile's iterative, lightweight approach and delays feedback on evolving requirements. It tempts teams seeking audit certainty, yet DA produces documentation continuously and just in time, focusing on regulatory and decision records rather than exhaustive pre-written specifications.

Fully decentralize all IT procurement decisions

Why it fails: Full decentralisation removes the enterprise awareness and governance that Disciplined Agile expects, leaving procurement uncoordinated and risks unmanaged. It is tempting because it honours team autonomy, and it would be correct where teams already have mature guardrails, budgets and shared architectural guidance.

Force all teams to use legacy software only

Why it fails: Mandating legacy software removes teams' ability to choose fit-for-purpose tooling, which Disciplined Agile rejects; it addresses symptoms rather than the governance gap driving Shadow IT. It is tempting because standardisation aids support and compliance, and it would be correct where regulatory or security constraints genuinely prohibit alternatives.

Ban all software purchases by individual teams

Why it fails: A blanket ban on team purchases ignores that Shadow IT signals unmet needs; Disciplined Agile prefers guided self-organisation over prohibition. It is tempting because it restores central control and visibility, and it would be correct where procurement is legally restricted to approved vendors for compliance reasons.