Modern Agile: What Actually Works vs What's Just Ceremony
Modern Agile: What Actually Works vs What's Just Ceremony
Series: The Modern SDLC · Post 4 of 17 ← Post 3: Developer Toolchain · Post 5: Development Practices →
Most engineering teams are doing agile wrong. Not because they don't care, and not because the people running it aren't trying. Because somewhere between the Agile Manifesto and the modern enterprise, "agile" became a set of ceremonies to perform rather than a way of thinking about how to deliver value.
The tell is the standup that runs forty minutes. The sprint planning that turns into a design session. The retrospective that generates twelve action items, none of which are assigned to anyone, none of which are done by the next retrospective. The velocity metric that gets optimised until it means nothing.
Teams in this situation aren't doing agile. They're doing the appearance of agile while carrying all its overhead and none of its benefit.
This post is about the practices that actually move the needle — and the ones that are mostly ceremony.
The one thing to remember
Agile is a thinking framework for delivering value in small increments with fast feedback. Every practice you adopt should serve that goal. If it doesn't, cut it.
The test for any agile ceremony: does doing this help the team deliver better software faster? If the honest answer is no, stop doing it. Process exists to serve delivery, not the other way around.
Connect work to outcomes before connecting it to tasks
The failure mode that undermines most agile implementations isn't in the ceremonies — it's in the absence of a clear line between the work the team does and the outcomes the organisation cares about.
A team can run perfect sprints, maintain a healthy backlog, and hit their velocity targets every week while building things that don't move any business metric that matters. This isn't a failure of execution. It's a failure of connection.
The structure that prevents it is the OKR hierarchy: Objectives (where we're going this quarter) → Key Results (how we'll measure whether we got there) → Epics (chunks of product work that advance a Key Result) → Stories (deliverable units within an epic). Every story should be traceable back up this chain. If you can't answer "why are we building this?" with something more specific than "because someone asked," the story shouldn't be in the sprint.
This sounds obvious. It's rarely practiced. The practical implementation is simple: in sprint planning, before accepting a story into the sprint, ask "which Key Result does this advance?" If nobody can answer, the story goes back to the backlog until the connection is established.
Write stories that describe outcomes, not tasks
A story is a unit of value. Not a unit of work.
The difference matters because it changes what the team builds and how they know when they're done. "Implement the payment API endpoint" is a unit of work — it describes a technical task with no user, no outcome, and no way to measure success. "As a customer, I want to complete a purchase with my saved payment method so that I can check out without re-entering my card details" is a unit of value — it has a user, a goal, and a condition of success.
The INVEST criteria is a useful checklist for story quality:
Independent — can be developed and delivered without depending on another story in the same sprint
Negotiable — the how is open to discussion, only the what and why are fixed
Valuable — delivers something meaningful to a user or the business
Estimable — the team can form a view on its complexity
Small — completable within a single sprint, ideally within a few days
Testable — acceptance criteria exist that define when it's done
Acceptance criteria are the most important part of a well-written story and the most commonly underdeveloped. Written in Given/When/Then format, they define done unambiguously before development starts. "Given a customer with a saved payment method, when they click 'Pay now', then the payment is processed using the saved method and they receive a confirmation." This is a test. It can be verified. It leaves no room for "I thought done meant X."
The size rule is practical: any story estimated above 8 story points (or assessed as L or XL in t-shirt sizing) isn't ready for a sprint. It needs to be broken down. A story that can't be completed within a sprint is a waterfall task wearing an agile costume.
Estimation: the number matters less than the conversation
Story point estimation causes more religious debate in engineering teams than almost any other practice. The honest answer is that the specific system matters far less than most people think. What matters is that the team has a shared understanding of relative complexity — and that the conversation during estimation surfaces disagreement before it becomes a problem during development.
The three systems in common use:
Fibonacci story points (1, 2, 3, 5, 8, 13) are the most common. The non-linear scale is intentional — the gap between 8 and 13 is meant to represent genuinely higher uncertainty, not just more hours. Planning poker — where everyone reveals their estimate simultaneously — surfaces disagreement. When one engineer says 3 and another says 13, that disagreement isn't a problem to resolve by averaging. It's a signal that the story is understood differently by different people, which is exactly what you need to surface before development starts.
T-shirt sizes (XS, S, M, L, XL) have lower friction and less false precision. Good for roadmap-level planning and for teams that find the specificity of story points to be more ceremony than signal.
#NoEstimates — count stories rather than point them. Assumes stories are roughly equal size if written well. Reduces estimation overhead entirely. Works well for mature teams with strong story discipline; falls apart if story quality is inconsistent.
Whatever system you use, one rule applies universally: a story that comes back with a high estimate (above 8 points or L+) is a signal, not a problem. It means the story is too big, too ambiguous, or poorly understood. Break it down before it enters a sprint.
The sprint ceremonies: what they're actually for
The ceremonies aren't the point. The point is delivering working software and learning from what you build. The ceremonies exist to support that — and when they stop doing so, they should be changed or cut.
Sprint planning has one job: the team leaves with a shared commitment to a set of stories they believe they can deliver, and a shared understanding of what each story requires. It should not be a design session. It should not be the first time stories are discussed (that's refinement's job). If planning regularly runs over two hours for a two-week sprint, something upstream is broken — stories are arriving unprepared, or planning is doing work that belongs elsewhere.
The daily standup works best when it's a coordination meeting, not a status report. The format that produces the most value is walking the board right to left — starting from the stories closest to done, working backward through in-progress, then to-do. This surfaces blockers on near-complete work immediately, when fixing them has the most impact. The format that produces the least value is going person by person asking "what did you do yesterday, what will you do today, any blockers?" — which is a status report that could be a Slack message.
Fifteen minutes. Hard limit. If it regularly runs over, the team is using standup to do work it should be doing elsewhere.
Sprint review is where working software is demonstrated to stakeholders. Not a PowerPoint. Not a walkthrough of a staging environment. Working software, demonstrated against the acceptance criteria of the stories completed. The purpose is feedback — real feedback from real stakeholders who can see what was built and respond to it. Teams that skip the review because "stakeholders are busy" are skipping the feedback loop that makes agile valuable.
The retrospective is the team's mechanism for improving its own process. It has exactly one requirement: it must produce action. A retrospective that generates honest conversation and twelve items on a whiteboard, none of which are assigned to anyone, is a support group, not a process improvement. The discipline: generate as many items as needed, vote on the top three, assign each to a named person, and open the next retrospective by reviewing whether last time's actions were completed. That accountability is what turns retrospectives from therapy into improvement.
Backlog refinement runs mid-sprint to prepare the next sprint's work. Stories are written, acceptance criteria are added, estimates are formed, dependencies are identified. The goal is that sprint planning should be boring — all the hard work already done, the team simply selecting from a backlog of ready stories. If refinement isn't happening, planning will be painful.
Backlog health: the backlog is not a dumping ground
A backlog with 400 tickets is almost always a graveyard masquerading as a plan. Items accumulate, lose context, become stale, and create the illusion of a roadmap while actually obscuring priorities.
A healthy backlog has three properties:
It's prioritised. The top of the backlog represents the most valuable work the team could be doing. The further down you go, the less certain the priority. Anything below the horizon of the next two to three sprints is aspirational, not planned.
It's ready. Stories at the top are written with acceptance criteria, estimated, and free of unresolved dependencies. A story that arrives at sprint planning without acceptance criteria isn't ready to be committed to. "Ready" should be a formal gate.
It's curated. Any ticket with no activity in the last three months gets archived. Not deleted — archived. If it was important, it'll come back. The act of regular archiving forces the team to actively decide what matters rather than passively accumulating everything anyone ever thought of.
The prioritisation framework that works best depends on the team, but RICE (Reach × Impact × Confidence ÷ Effort) is the most rigorous for product decisions. For simpler contexts, straightforward stack ranking — what's most valuable, what's second most valuable — avoids the overhead of scoring while producing a clear priority order.
The metrics that matter: flow over activity
Velocity — story points completed per sprint — is the metric most agile teams track and the one that provides the least signal.
The problem with velocity is that it measures output, not outcomes, and it's trivially gameable. Teams that are managed on velocity inflate estimates, reduce story ambition, and optimise for points delivered rather than value delivered. The metric stops measuring what it was meant to measure within a few months of being used as a management tool.
The metrics that actually indicate process health are flow metrics:
Cycle time — the time from when a story moves to "in progress" to when it's done. Low cycle time means work flows through the team quickly. Rising cycle time means something is creating blockages. Track it per story and watch the trend.
Lead time — the time from when a story is requested (enters the backlog) to when it's delivered (shipped to production). This is the metric your stakeholders actually care about, even if they don't call it that.
Work in progress (WIP) — the number of stories in flight simultaneously. The counterintuitive truth: limiting WIP makes teams deliver faster, not slower. Every additional item in progress adds context switching, increases the chance of blocking other work, and lengthens cycle time for everything. A team with three things in progress will consistently outship a team with fifteen.
Escaped defects — bugs found in production versus bugs found in review or QA. A rising trend here means quality gates aren't catching what they should. A sustained low trend means the testing strategy is working.
A cumulative flow diagram — showing how many stories are in each column of your board over time — makes these metrics visual. Where work piles up in a column is where your process has a constraint. That's where to focus improvement effort.
Kanban over Scrum for interrupt-driven teams
Scrum's fixed sprint model assumes work arrives in predictable, plannable batches. For teams whose work looks like that — product teams building features on a roadmap — it fits well.
For teams whose work doesn't look like that — platform teams handling support requests, teams managing operations alongside development, small teams where a single production incident disrupts the entire sprint — the fixed sprint creates more problems than it solves. Commitments made on Monday are routinely broken by Thursday. Velocity is meaningless when half the sprint's work wasn't planned. Sprint planning for work that's fundamentally unpredictable is an exercise in fiction.
Kanban fits these teams better. There are no sprints — just a continuous flow of prioritised work with WIP limits on each column. New work enters the backlog and is prioritised against existing work. The team pulls from the top of the backlog when capacity is available. Cycle time and throughput replace velocity as the health metrics.
The decision between Scrum and Kanban shouldn't be ideological. It should be based on what the work actually looks like. Teams that try to force Scrum onto fundamentally interrupt-driven work spend a lot of effort managing the gap between the process and reality.
What goes wrong when agile becomes ceremony
Agile theatre. All the ceremonies, none of the thinking. Standups, planning, retrospectives — all happening on schedule, all generating the right artefacts, none of them influencing how decisions are made or how the team responds to feedback. The ceremonies become the goal rather than the mechanism.
Sprint as deadline. Treating the end of a sprint as a hard release date creates the wrong pressures. Stories get rushed to meet the deadline. Quality is compromised. Technical debt accumulates. The sprint boundary should be a checkpoint, not a guillotine.
Velocity obsession. Once velocity becomes a management metric — once someone outside the team is watching it and forming opinions about team performance based on it — it stops being a planning tool and becomes a target to optimise. The optimisation is never good for the actual work.
Retrospectives with no follow-through. The most demoralising experience in agile is raising the same problem in every retrospective because last sprint's action to address it was never completed. Teams that experience this long enough stop raising real problems at retrospectives. The session becomes a formality rather than a mechanism for improvement.
No team autonomy. Agile requires that the team can say no to unrealistic commitments, push back on scope mid-sprint when new information changes the picture, and make decisions about how to do the work. A team that's told what to build, how to build it, when to have it done, and measured on whether they hit that date isn't doing agile. It's doing waterfall with standups.
If you do one thing from this post
Run the next retrospective differently. Before you generate any new items, open with five minutes reviewing last retrospective's action items: were they done, and did they help?
If the honest answer is mostly no — actions weren't completed, or they were completed but nothing changed — stop generating new action items until you understand why the last ones didn't land. The problem isn't the retrospective format. The problem is the follow-through system. Fix that first.
Next up: Post 5 — The Coding Standards That Separate Confident Teams from Anxious Ones
← Post 3: Your Developer Toolchain Is Either a Force Multiplier or a Tax
