Agile assumes feedback can shape the next iteration; if feedback isn’t reachable (after launch) and software can’t be re-deployed (after launch), the assumption fails and the practices don’t deliver their benefits.

Agile is faster, not slower — that’s part of what frustrates the safety-critical fit, since there’s no time for the rigor formal verification needs. Speed is the wrong dimension to evaluate the mismatch on.

XP has the same fundamental mismatch with safety-critical space hardware — it explicitly excludes the spacecraft-software domain. Recommending XP just substitutes one Agile framework for another with the same structural unfit.

Verbal communication and reactive iteration are real Agile preferences, but the Manifesto explicitly says documentation and planning have value. Treating “less of” as “none of” is the most common misreading and is what produces undisciplined teams that mistake disorganization for agility.

Agile typically does less up-front planning than Waterfall, not more — planning is iterative and time-boxed. Framing it as “more upfront planning, framed differently” inverts the actual practice.

End-of-project documentation is exactly the artifact Agile tries to de-emphasize in favor of working software as the primary measure. The framing here describes Waterfall’s deliverable model, not Agile’s.

Scrum requires a demonstrable working increment at the end of each sprint to the customer, and Scrum’s own scope-change rules apply between sprints. End-only demos and frozen specs violate the framework, not exemplify it.

XP adds pair programming, TDD, CI, and small frequent releases — none of which appear here. The described team has Scrum’s ceremonies without XP’s engineering practices and without Agile’s customer loop.

“Wagile” combines Waterfall’s worst feature (no customer feedback until the end) with Agile’s overhead (ceremonies that consume time without producing value). It is not best-of-both; it is worst-of-both, and is one of the most-studied Agile-adoption failure modes.

This is the headline Waterfall failure: the customer can’t catch a wrong-direction project until it’s already complete, by which point fixing it costs as much as building it.

Real domains have evolving requirements (users change their minds, markets shift, technology advances). Waterfall’s stability assumption is the root cause of most of its other problems.

Defects discovered after long sequential phases cost orders of magnitude more than the same defects discovered at the moment they were introduced. This is why Agile invests so heavily in fast feedback.

Waterfall does not produce ‘too modular’ code — that critique applies (occasionally) to over-engineered architectures. Waterfall’s typical code quality varies widely; modularity is not the failure mode.

The directions are reversed. Waterfall is slower end-to-end (months/years per release); Agile is faster (weeks per iteration). Slow-vs-fast is exactly what Agile rebalanced.

Agile teams estimate frequently (Planning Poker, velocity, burndown). The framing ‘we will deliver every 2 weeks’ is a precise estimate — it commits to a cadence and lets scope float.

Agile is compatible with deadlines — the team commits to a date and adjusts scope to fit. The technique of fixing-time-and-scope-and-quality and letting all three negotiate is itself an Agile pattern (the iron triangle).

The team is being responsive: they’re shifting decision authority to the customer, who controls when ‘good enough’ is reached. This is exactly the customer-collaboration value at work, not avoidance.

Simplicity is about the amount of work not done, not about who writes specs. The pattern described isn’t about spec detail — it’s about who makes decisions.

Customer satisfaction is about delivering value to the end user. Leadership-as-not-the-customer is true but tangential — the violation is specifically about excluding developers from decisions about their own work.

Technical excellence is about ongoing quality investment. Leadership’s stance on quality may or may not be involved; the specific pattern in the question is about decision-making authority.

They are distinct frameworks with different emphases — though all rooted in Agile values. Treating them as identical loses the ability to combine them strategically (e.g., Scrum for workflow + XP for engineering practice).

Scrum scales somewhat better than XP, but it’s also widely used in small teams. Lean originated in manufacturing but has been thoroughly adapted to software (Lean Software Development). The framing is too coarse.

The roles are reversed: XP focuses on engineering practices; Scrum focuses on project management / workflow. Lean is broader than ‘just metrics’ — it’s a philosophy of waste elimination.

This is the cargo-cult version of Agile that produces chaos. The Manifesto explicitly says ‘while we value the items on the right [following a plan], we value the items on the left [responding to change] more.’ Both have value.

Writing a Waterfall plan and labeling it ‘Agile’ produces process-mislabel theater — the worst combination of upfront-rigidity overhead and Agile-vocabulary plausible-deniability. Not a real fix.

Even startups need a hypothesis about what they’re building and for whom. Skipping all process produces undirected work that may not converge on a viable product before runway runs out.

Engineering has plenty to say about delivery cadence — the right conversation is what’s blocking demonstrable increments, not ‘engineering shouldn’t have an opinion.’

Self-organization doesn’t mean engineering decides unilaterally; it means the team self-organizes around delivering customer value. Refusing to demo software is not a self-organizing decision — it’s avoiding the feedback loop.

‘Working software’ means demonstrable, not polished. The Agile principle prioritizes showing real progress over hiding work until it’s perfect. The engineering manager’s framing reverses this.

Treating sprints as sacrosanct re-creates the inflexibility Agile was designed to address. Some Scrum coaches teach this rule as a heuristic to protect focus, but the heuristic itself is not an Agile value — it’s a practice that sometimes serves the values.

Automatic acceptance discards the engineering view of cost and feasibility. Even high-priority changes have trade-offs that the customer needs visibility into before deciding.

Deferring conversation to next iteration is a process rigidity that violates ‘customer collaboration over contract negotiation.’ Customers expect to talk about urgent things urgently; deferring damages the relationship and the product.