The “agile is dead” argument appears on a reliable cycle, usually authored by someone who spent years watching organizations adopt the ceremonies, terminology, and org charts of agile while preserving the planning assumptions, reporting structures, and risk culture of waterfall. The frustration is legitimate. The conclusion is wrong. What failed in most organizations was not agile. It was a management consulting product that appropriated agile vocabulary while systematically removing the practices that give agile its value.

The promise was efficiency. Feed the prompt, review the output, merge the diff. What teams discovered instead is that AI-assisted code review is more cognitively demanding than reviewing code written by a colleague — not less — because the nature of the errors has changed. When a human writes a bug, there is usually a traceable cause: a misunderstood requirement, a missed edge case, a copy-paste error. The bug has an author with intent.

Software architecture has always been more about constraints than capabilities. A good architecture does not just describe what a system can do — it defines what it will not do, where the boundaries are, and how components relate to one another in ways that can be understood, tested, and changed over time. The value of architectural discipline is not immediately visible. It manifests as the absence of problems that would otherwise accumulate quietly and expensively.

Sprint planning gets the attention. Retrospectives get the emotion. The daily standup gets the complaints. Backlog refinement — the ongoing work of clarifying, estimating, and ordering items before they are pulled into a sprint — is the practice that determines whether any of the other ceremonies will function. A team that arrives at sprint planning with a well-refined backlog can complete planning in under an hour. Stories are understood, sized, and ready.

Continuous delivery is typically categorized as a DevOps or engineering operations practice: build pipelines, automated testing, deployment automation, infrastructure as code. This categorization is accurate but incomplete in a way that matters. Continuous delivery is also the technical prerequisite for agile development to function as intended, and teams that treat it as an infrastructure concern rather than a delivery discipline tend to develop a subtle dysfunction in their sprint practice.

Most agile teams have a definition of done. Fewer have a definition of ready. The asymmetry is understandable — done is where accountability lives, where the increment is evaluated, where quality is enforced — but the absence of a ready definition pushes unresolved questions into the sprint, where they are more expensive to answer. A definition of ready is an agreement about what a story must have before it can be pulled into a sprint.

The fixed-price contract is built on a specific assumption: that the scope of the work can be defined in advance with enough precision to price it accurately. The agile development model is built on a specific observation: that software requirements are not fully knowable in advance, and that attempting to define them completely before development begins produces worse outcomes than defining them incrementally in response to what is learned during development.

Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong. AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.

The debate over whether a team should use kanban or scrum is often a proxy for a different and more useful question: does this team’s work arrive in predictable batches or as a continuous flow? Scrum is designed for the former. Kanban is designed for the latter. The choice follows from the nature of the work, not from a preference for ceremonies or a dislike of story points. Scrum works well when a team can define discrete deliverables, plan a fixed amount of work for a fixed period, and evaluate progress at the end of an iteration.

The scaling agile industry — SAFe, LeSS, Nexus, Scrum@Scale, and their variants — exists to solve a real problem: how do you coordinate multiple agile teams working toward a shared product without recreating waterfall planning at the portfolio level? The problem is genuine. The solution is frequently applied to organizations that do not have it. The typical trigger for a scaling framework adoption is not coordination failure between teams — it is discomfort at the leadership level with the absence of a visible, organization-wide plan.