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.

Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one’s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable. The main reason planning poker works is that it makes disagreement visible.

The phrase prompt engineering acquired a skeptical connotation early — something between a joke about talking to chatbots and a transitional skill that would be obsoleted as models improved. Neither characterization was accurate, and teams that dismissed it on those grounds have paid a real productivity cost. Prompting a code generation model effectively is a software discipline because it shares the fundamental characteristics of all software work: it requires precise specification of desired behavior, systematic handling of edge cases, and iterative refinement based on observed output.

When agile teams moved to remote work, the common concern was whether the ceremonies would survive the transition. Would sprint planning work over video? Could retrospectives produce candor without physical presence? Would the daily standup maintain its discipline when the team was distributed across time zones? These concerns were largely misplaced. The ceremonies adapted. Video-based sprint planning, while less fluid than in-person, functions well enough with the right tools and facilitation.

For most of software’s history, vague requirements were expensive but survivable. A developer who received an underspecified ticket could ask a question, make a reasonable inference, or build a small prototype and get feedback. The cost of ambiguity was absorbed in back-and-forth, rework, and the gradual clarification that happened naturally when humans were iterating together. AI-assisted development has changed the economics of ambiguity in a way that most teams have not fully reckoned with.

The retrospective is the most important ceremony in the sprint cycle and the one most commonly reduced to ritual. Teams go through the motions — what went well, what didn’t, what to improve — produce a list of action items, and proceed to the next sprint having changed nothing. The list sits in a document somewhere. The problems repeat. This failure mode is so common that many experienced practitioners have concluded retrospectives do not work.

The large story is one of the most reliable predictors of sprint failure. A story that spans more than half a sprint occupies the team’s attention, resists review, and tends to arrive at the sprint boundary in a state of near-done that creates exactly the kind of work-in-progress debt that sprints are designed to prevent. Teams know this. They continue to carry large stories because splitting them well is genuinely difficult and the techniques for doing it are not intuitive.

Technical debt in most agile teams exists in two places: in the codebase, where it slows down every sprint without appearing in any sprint report, and in informal conversations between developers, where it is acknowledged but never prioritized. This arrangement persists because engineers are reluctant to burden the product owner with implementation concerns, and product owners are reluctant to prioritize work that has no visible user-facing outcome. The debt accumulates. The sprints slow down.

Technical debt was always a metaphor with a compounding interest rate. Decisions made quickly to ship a feature cost more to address the longer they remained in the codebase. Teams that managed debt well built systems that stayed malleable. Teams that ignored it built systems that eventually could not be changed without risk of collapse. AI-assisted development has not eliminated this dynamic. It has accelerated the principal. The speed at which code can be generated means that architectural decisions — or the absence of them — propagate through a codebase faster than ever before.