Formal technical reviews, postmortems, and agile reviews

The informal end of the continuum

An informal review is a desk check with a colleague, a casual meeting of three or four people over a work product, or the review-shaped part of pair programming. Because there is no advance planning, no agenda, no defined roles and no follow-up, its yield is markedly lower than a formal review — but a desk check still finds errors that would otherwise propagate, and it costs an hour. The cheapest upgrade available is a checklist per work-product type: the same two people, the same hour, but now walking a list of questions rather than whatever catches the eye. Pair programming is best understood as a continuous desk check — review happening as the artefact is created rather than at a scheduled point afterwards, which trades some redundancy for immediate error discovery.

The formal technical review

A formal technical review (FTR) is a quality-control activity performed by software engineers on a work product, and the term names a family of them, walkthroughs and inspections included. It sets out to find errors of function, of logic and of implementation; to check the work product against its requirements; to confirm it follows the standards in force; to make the team's output uniform; and to make projects easier to manage. It has two side-benefits worth naming: junior engineers see how others analyse and design, and several people become familiar with parts of the system they would otherwise never read.

The constraints are specific and examinable. Three to five people. No more than two hours of preparation each. A meeting of less than two hours. One work product — which is why you review one component's detailed design or one part of a requirements model, never "the design". Narrowing the focus is what makes the yield high.

Roles, sequence, outcome

Four roles. The producer built the work product and declares it ready. The review leader evaluates readiness, distributes the materials in advance and sets the agenda. Two or three reviewers prepare individually, spending one to two hours. One reviewer additionally acts as recorder, logging every issue raised. In the meeting the producer walks through the material while reviewers raise what their preparation surfaced; the recorder writes it down; the leader keeps the agenda and stops the meeting if it turns into an inquisition.

The outcome is a triple, and dropping any part of it is the most common way to lose a mark on this definition: an issues list; a decision — accept as is, accept provisionally with minor revisions and no further review, or reject and re-review once corrected; and a sign-off by every attendee recording their participation and concurrence. A one-page summary report records the subject, the participants and the findings, and goes into the project history. Someone, usually the review leader, owns follow-up, or issues quietly fall through.

The guidelines that make it work

Ten, and the first is the one that carries the culture: review the product, not the producer. Then: set an agenda and hold it; limit debate — record a disputed issue and take it offline; enunciate problems but do not solve them in the room, because a review is not a problem-solving session; take written notes where everyone can see them; limit participants and insist on preparation; keep a checklist per work-product type; schedule reviews and their rework as real tasks in the plan; train reviewers in both the process and its psychology; and review your early reviews — the first work product a new team should inspect is its own review guidelines.

Postmortems and agile reviews

A postmortem evaluation looks backwards over a completed increment or project with the whole team: what worked, what did not, and what specifically changes next time. Agile practice distributes the same function differently — pair programming as continuous review, the sprint retrospective as a recurring postmortem, and pull-request review as a lightweight standing inspection. Lower ceremony, much higher frequency; the four formality characteristics are simply dialled down because the review interval is short.

Worked example — reviewing the BorrowBox Tool state model

One work product: the state model for a Tool, covering Available, Reserved, CheckedOut, Overdue, InInspection, InRepair and Retired. Four people — the modeller as producer, the tech lead as review leader, a developer and the librarian who will run the depot, one of them recording. Each prepares for an hour against the modelling checklist. The ninety-minute meeting produces six issues, of which one is major: the transition from Overdue to InInspection has no guard for a tool returned into a locker bank that is already full, so the model has no state for a tool that is physically present and logically nowhere. Decision: accept provisionally — the guard and a new HeldAtDesk state are added and re-checked by the leader alone. Everyone signs off. Found after release, that same gap is a member standing in the rain holding a hedge trimmer, a support call, and a librarian doing reconciliation by hand.