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.