How teams work

Agile is a set of preferences rather than a process: working software over comprehensive documentation, responding to change over following a plan, collaboration over contract negotiation, individuals and interactions over tools. Each is a preference between two goods, which is the part most often dropped when it is quoted.

Scrum implements those preferences with structure: fixed sprints, a product owner, a scrum master, a backlog, and ceremonies for planning, review and retrospective. Kanban drops the sprint entirely and limits work in progress instead, pulling the next item when capacity frees. Kanban suits interrupt-driven work such as support or platform; scrum suits planned feature work with a stable team and a plannable period.

Work in progress limits are the most underrated idea in either. Starting five things at once does not make them arrive sooner; it makes all five arrive later and increases the chance that some are abandoned half-finished. Limiting concurrent work reduces cycle time for the same throughput, which is Little's Law applied to a team rather than to a service.

The common failure is adopting the ceremonies without the feedback. Standups with no working software to demonstrate, sprints whose plan cannot change, retrospectives with no action taken: that is waterfall with more meetings, and everyone in the room knows it, which is where the reputational damage to the word comes from.

The retrospective is the meeting that determines whether any of it works, because it is the only one whose output is a change to how the team operates. A retrospective that produces observations and no owned action is a therapy session; one that changes something small every fortnight compounds. Estimation deserves less energy than it gets. Story points are a relative measure whose only legitimate use is forecasting from historical throughput, and the moment they become a productivity metric they are inflated and stop forecasting anything. Counting finished items and measuring cycle time is simpler and harder to game.

Review catches defects, and if that were the whole benefit it would not be worth what it costs. The larger effects are that context spreads across a team, that a second person can now maintain the thing, and that the codebase stays coherent enough for the next change to be small. A team where every file has exactly one person who understands it has a staffing problem disguised as a productivity advantage.

Pull request size is the single biggest lever on whether any of that happens. Small changes get read; large ones get approved, because nobody can hold two thousand lines in their head and the honest options are to spend a day on it or to trust the author. Everybody chooses trust. That is not laziness, it is capacity, which is why the fix is upstream: splitting work into reviewable pieces is a design skill, and a change that cannot be split usually has a boundary problem worth finding before it is written.

Latency matters as much as depth and gets far less attention. A review that arrives in an hour costs the author nothing; one that arrives the next day costs them a context switch to return to work they had finished thinking about, and it costs the change a day of drift against the branch it will merge into. A team that reviews within a few hours and comments less thoroughly generally ships better code than one that reviews perfectly on a two-day delay.

Separate blocking concerns from suggestions, explicitly, in the comment itself. Reviewers and authors routinely disagree about whether a comment must be addressed, and the disagreement is invisible: the reviewer thought they were musing, the author thought they were blocked, and a day goes past. Saying which comments are required and which are taste removes an entire category of friction, and a convention as crude as a one-word prefix does it.

The most useful comment names the case that breaks rather than the preference that was violated. This is null when the user has never logged in can be acted on immediately and cannot be argued with. I would extract this starts a conversation about style with no way to settle it, and settles by seniority rather than by reasoning, which is corrosive in a way that is hard to attribute afterwards. Where a preference genuinely matters, it belongs in a linter or a formatter, enforced by a machine that nobody resents.

Two things are worth taking out of review entirely. Formatting, which a formatter should decide so that no human ever spends attention on it. And architectural direction, which is much cheaper to discuss before the code exists than in a comment thread on a finished implementation. A review is the wrong venue for a design argument, and the tell that it is happening is a pull request with forty comments and no defect among them.

During an incident, restore service first and investigate afterwards. Mitigation and diagnosis compete for the same people and the same minutes, and users care about the first. Roll back, fail over, disable the feature, and keep the evidence; understanding can wait, and it is easier with a system that is up.

Incidents run better with roles assigned rather than assumed. One incident commander who coordinates and decides, one person communicating outward so the responders are not answering questions, and the rest investigating. The commander does not have to be the most senior engineer, and often should not be, because coordinating and debugging are different jobs competing for the same attention.

A postmortem asks what made the failure possible rather than who typed the command. If one person's mistake could take production down, the finding is the system that allowed it: no confirmation, no staged rollout, no way to reverse. Human error is the beginning of the investigation, not its conclusion.

Blameless does not mean consequence-free. It means the output is a change to the system rather than a name, because the alternative is worse in a specific and measurable way: if reporting a mistake is punished, people stop reporting, near misses go unrecorded, and you lose exactly the information that prevents the next one.

Actions need owners and dates or the document is a diary. A postmortem that produces twelve suggestions and no assignments has changed nothing, and the same incident recurs with a second document beside the first. Two owned actions beat twelve orphaned ones.

Two habits are worth adding once the basics hold. Track how long detection took separately from how long the fix took, because a fast fix after a slow detection is still a long outage and points at monitoring rather than at engineering. And read old postmortems periodically: the recurring theme across a year is a finding that no single incident can reveal.