Choose Your Way OF Working practice questions

Abandoning all documentation immediately.

Why it fails: This is reckless and ignores the 'pragmatic' principle.

Mandating a 'Safe' implementation.

Why it fails: DA is a toolkit, not a rigid framework like SAFe.

The 'Agile Transformation' framework.

Why it fails: DA avoids the term 'transformation' in favor of 'evolution' and pragmatism.

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.

Force the team to follow the Scrum guide's retrospective format.

Why it fails: Disciplined Agile encourages choosing the WoW that fits the team's context, so imposing the Scrum guide's retrospective format contradicts that principle and may deepen the staleness. It is tempting because Scrum's format is familiar and structured, and would suit a team already committed to Scrum whose retrospectives merely lack discipline.

Assign a new facilitator.

Why it fails: Rotating facilitation can refresh a retrospective, but simply assigning a new facilitator changes the person, not the process, leaving the stale format intact; DA instead guides the team to select new techniques. It is tempting because facilitator rotation is a recognised agile practise, and would be correct where the existing process is sound but the incumbent is ineffective.

Cancel all future retrospectives.

Why it fails: Cancelling retrospectives removes the inspect-and-adapt loop entirely, so the team loses its only structured forum for surfacing process problems. It is tempting as a dramatic reset when a ceremony feels stale, and would fit only if the team were disbanding or replacing the retrospective with a different improvement mechanism.

Daily Stand-up Frequency.

Why it fails: This is a practice, not a process goal.

Select the Project Lifecycle.

Why it fails: This is a decision point, not a process goal.

Avoid all documentation.

Why it fails: Omitting documentation breaches the mandatory compliance requirement outright, leaving no audit trail or evidence of decisions. Skipping paperwork is tempting when delivery pressure is high and documentation feels like overhead, but here it is a contractual obligation, not optional.

Use the same documentation as the Waterfall team.

Why it fails: Waterfall documentation assumes fixed, fully specified requirements, so it will not capture iterative DA artefacts such as evolving backlogs and increment reviews. Reusing an existing template is tempting because it appears to save effort, yet it misaligns with the toolkit's iterative delivery model.

Create a new documentation process from scratch.

Why it fails: Building a new process discards the DA toolkit's existing templates and compliance artefacts, duplicating effort and risking gaps against mandated standards. Starting fresh appeals when legacy documentation feels unfit, yet the toolkit already provides the structure compliance requires.

Grow Team Members.

Why it fails: This is about individual development.

Improve Team Velocity.

Why it fails: This is about speed, not quality.

Coordinate Activities.

Why it fails: This relates to team synchronization, not quality directly.

Strict-Compliance.

Why it fails: This is not a standard DA lifecycle.

Hybrid-Only.

Why it fails: This is not a DA lifecycle.

Waterfall.

Why it fails: This is a traditional lifecycle.

Define the team's dress code.

Why it fails: Irrelevant factor.

Manage the budget.

Why it fails: Budgeting is not a decision point in this goal.

Produce Potentially Consumable Solution.

Why it fails: This is the ongoing delivery phase.

Improve Team Velocity.

Why it fails: This requires a baseline process to improve.

Grow Team Members.

Why it fails: While important, it's not the starting point.

The Continuous Delivery: Agile lifecycle, because auditors require frequent small releases.

Why it fails: Continuous Delivery: Agile assumes a streamlined path to production with automated deployment and minimal external gatekeeping. This team's work is gated by mandatory artifact review, so the lifecycle's core assumption does not hold. It would create friction between the delivery cadence and the compliance checkpoints, requiring the team to abandon the lifecycle's defining characteristic.

The Agile lifecycle, because a compliance team should always start with the lightest possible process.

Why it fails: The Agile lifecycle suits teams that can deliver small increments continuously to a single production environment. This team cannot release unreviewed work, so a continuous delivery cadence conflicts with its mandatory review gates. Choosing the lightest process ignores the team's regulatory constraints and would force heavy tailoring just to make the lifecycle viable.

The Lean lifecycle, because it eliminates all process documentation and review steps.

Why it fails: The Lean lifecycle focuses on eliminating waste in a flow-based system, but it does not eliminate mandatory compliance reviews. This team must retain evidence of review, which Lean would not inherently provide. Selecting Lean here misreads the lifecycle's purpose and would leave the team without the cadence and governance structure it needs.

Select the option with the fewest steps.

Why it fails: Step count ignores the trade-offs each option makes across the other process goals, which is what the DA toolkit weighs. Options are chosen by assessing their impact on the whole system, not by counting activities. Fewest steps would be correct only if the goal were purely minimising process overhead.

Randomly select an option to experiment.

Why it fails: Random experimentation discards the deliberate trade-off analysis the DA toolkit prescribes for choosing between options, wasting effort and risking a poor fit. Options are selected by evaluating their impact against your team's goals and context. Random choice would be correct only when options are genuinely indistinguishable.

Select the option that is most popular in the industry.

Why it fails: Industry popularity reflects other organisations' contexts, not your team's value streams, constraints and goals, which the DA toolkit requires you to evaluate. Selection follows context-specific trade-off analysis. Popularity would be correct only if your context matched the industry norm exactly.

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.

Ensure Continuity.

Why it fails: Continuity addresses sustaining value delivery across iterations and team changes, which applies mid-project rather than the inception alignment stage. It is tempting because continuity is a recognised DA goal, but it would be correct when the concern is maintaining flow through transitions, not establishing shared direction at the start.

Produce Potentially Consumable Solution.

Why it fails: Produce Potentially Consumable Solution concerns delivering working increments each iteration, not early project alignment. It is tempting because it is a genuine DA process goal, and it would be correct if the question asked about delivering value continuously rather than aligning the team at project start.

Improve Team Velocity.

Why it fails: Velocity measures work completed per iteration, a delivery metric tracked once delivery is underway, not an alignment activity. It is tempting because velocity is a common DA goal, but it would be the correct focus when the team needs to improve throughput during execution, not to align stakeholders at project inception.

It forces every team to use the exact same metrics.

Why it fails: GCI explicitly lets teams choose metrics suited to their context, so imposing identical metrics on every team contradicts its purpose. It tempts because standardised metrics appear to enable cross-team comparison, which is valid for enterprise reporting but not for guiding team-level improvement.

It eliminates the need for retrospectives.

Why it fails: GCI relies on retrospectives to identify and act on improvement opportunities, so removing them eliminates the mechanism the approach depends on. It tempts because fewer ceremonies appear to save time, which is defensible only where improvement is driven by another explicit feedback process.

It mandates the use of only one specific lifecycle.

Why it fails: GCI encourages teams to select the lifecycle that fits their context, so mandating a single lifecycle removes the choice the approach exists to support. It tempts because a single lifecycle simplifies governance and training, which suits small organisations with uniform work.

Follow the methodology strictly.

Why it fails: Disciplined Agile explicitly rejects rigid adherence, instead guiding teams to tailor their Way of Working to context. Following a methodology strictly contradicts the toolkit's core premise of choice. It tempts because prescriptive frameworks such as SAFe or waterfall do mandate strict compliance, which suits regulated, low-variability delivery where deviation carries audit risk.

One size fits all.

Why it fails: Disciplined Agile explicitly rejects one-size-fits-all thinking; Choose Your WoW tailors the way of working to each team's context. It is tempting because standardised, uniform processes appear to simplify governance, and a single prescribed method would suit an organisation deliberately prioritising consistency over contextual fit.

Stop all work until the backlog is re-prioritized.

Why it fails: Halting all work freezes delivery and contradicts the WoW emphasis on visualising flow and pulling work incrementally; the first step is limiting WIP, not stopping it. It tempts teams wanting a clean reset, which suits planned shutdowns or major reorganisations rather than continuous flow improvement.

Ask management to hire more staff to handle the current WIP.

Why it fails: Hiring adds capacity without reducing the queue, so the WoW principle of limiting WIP and finishing work first is bypassed; delays persist as new staff absorb existing inventory. It tempts teams facing genuine long-term capacity shortfalls, where permanent headcount growth is the legitimate remedy.

Adopt a full Scrum framework immediately.

Why it fails: Adopting full Scrum imposes ceremonies and roles without first measuring and limiting WIP, so the delay driver persists. Scrum is genuinely right when a team needs iterative delivery with defined accountabilities, but the WoW mindset starts by making work visible and reducing WIP before selecting any framework.

A list of KPIs to measure team performance.

Why it fails: KPIs measure ongoing team or delivery performance, whereas a Process Goal defines a target outcome the process itself must reach. It tempts because DA goals are measurable, so metrics appear related, but a KPI list would be the answer only if the question asked how performance is tracked.

A project management certification level.

Why it fails: A certification level is a credential held by an individual, not a Process Goal, which in the DA toolkit names an outcome the delivery process must achieve. It tempts because DA does define role-based certifications, and those would be the answer if the question asked about practitioner accreditation rather than process outcomes.

A specific set of practices that must be adopted.

Why it fails: Process Goals state measurable outcomes the process must satisfy; they do not mandate a fixed set of practices, since DA deliberately leaves practice selection to the team. It tempts because DA does describe practices, and a question about prescribed adoption would point to those instead of goals.

Switch to a Waterfall lifecycle immediately.

Why it fails: Switching lifecycles addresses governance and delivery cadence, not the Agile lifecycle's commitment problem. The team should evaluate their iteration length, capacity allocation and story-point estimation against actual throughput. Waterfall suits fixed-scope, sequential delivery with stable requirements and minimal change, where commitments are set once at the outset rather than re-forecast each iteration.

Increase the frequency of daily stand-ups.

Why it fails: Daily stand-ups synchronise work and surface blockers; they do not diagnose why commitments are missed. The 'Continuous Delivery: Agile' lifecycle expects teams to evaluate their process against the outside-in flow of value, examining where work queues and delays accumulate. Increasing stand-up frequency would be the right response to poor coordination or stale information, not to systemic commitment failures.

Assign a dedicated Scrum Master to force compliance.

Why it fails: A Scrum Master enforcing compliance imposes process authority rather than addressing the forecasting or capacity problem causing missed commitments. Dedicated facilitation helps teams new to Scrum, but the issue is the commitment itself, not ceremony adherence.

To find a single 'best' practice for all teams.

Why it fails: Decision points are examined to clarify who owns each decision and how it is made within a specific team's context, not to standardise on one universal method. A single best practice contradicts the process goal's premise that teams tailor decisions to their own workflow and constraints.

To satisfy regulatory audit requirements.

Why it fails: Decision points are examined to identify where the process branches and who must be consulted or informed at each branch, so activities and responsibilities are correctly assigned. Satisfying regulatory audit requirements is a separate governance concern, addressed through evidence and compliance controls rather than decision-point analysis.

To minimize the number of team meetings.

Why it fails: Decision points exist to assign ownership and define how work flows between roles, not to reduce meeting volume. Cutting meetings is a scheduling outcome, not the purpose of analysing decision points. Teams examining decision points are mapping who decides what and when, which is unrelated to meeting frequency.

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.