Almost every team I’ve worked on runs some form of retrospective or post-incident review, and most of them run the same one: a whiteboard split into “what went well” and “what went badly,” a round of sticky notes, a few nods, and everyone back to their desks. It feels like reflection. It mostly isn’t. It’s a feelings dump with a tidy layout — and it reliably stops at exactly the point where the value would start.
Reflection is a skill with actual models behind it, borrowed from nursing and education, where doing it badly has consequences that show up in patients rather than sprint velocity. Four of those models are worth an engineer’s time — Kolb, Gibbs, Rolfe and Johns — and the differences between them are the difference between a review that changes something and one that just makes everyone feel heard.
The two-column trap
The “what went well / what went badly” format fails for one specific reason: it collapses two completely different questions into one. Was this good or bad? and why did it happen? are not the same enquiry, and the two-column board only ever asks the first. You end up with a list of symptoms everyone already knew about — “the deploy was slow,” “comms were confusing” — and no mechanism that forces the group past them to a cause. Worse, it treats reflection as a collection exercise: gather the notes, group them, feel productive. Collection isn’t reflection. The reflection is the work you do to the notes after you have them, and that’s precisely the part the format omits.
Kolb: the cycle, not the worksheet
David Kolb’s experiential learning cycle (1984) is the foundation the others build on: concrete experience → reflective observation → abstract conceptualisation → active experimentation. In plain terms — something happens, you think about it, you generalise a lesson from it, and then you change what you do next time. Its lasting contribution is the insistence that reflection is a loop: it isn’t finished until it feeds back into action.
But Kolb describes how learning happens, not how to run the conversation. It’s a model, not an agenda. It tells you a reflection that doesn’t end in changed behaviour was never reflection at all — invaluable as the mental backdrop, useless as the thing you put on the wall on a Friday afternoon.
Gibbs: where the structure earns its keep
Graham Gibbs’ reflective cycle (1988) takes Kolb’s loop and gives it six named stages you move through in order: description, feelings, evaluation, analysis, conclusion, and action plan. The overhead is obvious and the instinct is to trim it. Resist that instinct, because two of those stages are the whole point.
The first is that Gibbs separates evaluation from analysis — and enforces the order. Evaluation is “what was good or bad about this”; analysis is “why.” The two-column retro fuses them and then never reaches the second, which is why it produces symptoms and not causes. Gibbs makes you finish saying what before you’re allowed to start on why, and that single forced boundary is the difference between “the deploy was slow” and “we had no way to see which step was slow, because we never treated deploy timing as something worth measuring.”
The second is that Gibbs names feelings as an explicit stage, which engineers reliably skip as soft. In an incident it’s often the actual cause: the reluctance to escalate at 2am, the quiet assumption that someone else was watching the dashboard, the person who spotted it early but didn’t feel senior enough to say so. Leave feelings out and you’ll write “monitoring gap” when the honest finding was “nobody felt able to hit the big red button.”
Rolfe: fast, and easy to do badly
Rolfe and colleagues (2001) strip reflection back to three questions: What? So what? Now what? It’s elegant, it’s memorable, and it’s the one I actually reach for when there are ten minutes and a minor hiccup rather than a genuine incident.
Its brevity is also its trap. With no sub-structure, “so what?” collapses straight back into the same shallow evaluation you were trying to escape — a confident-sounding answer that never gets near a cause. Rolfe works beautifully for someone who already has the discipline Gibbs builds in, because they supply the rigour the framework leaves out. Hand it to a team that doesn’t, and you’ve just reinvented the two-column board with a third column.
Johns: reflection with a guide
Christopher Johns’ Model for Structured Reflection (1995) also comes from nursing, and it’s built for a different setting from the other three. It’s a set of cue questions — what was I trying to achieve, why did I act as I did, what were the consequences, what influenced me, what else could I have done, what have I learned — designed to be worked through with someone: a supervisor or mentor who guides the reflection and pushes back when the answers get comfortable.
That makes it the natural fit for the one-to-one — the monthly check-in or the quarterly development review, where a lead and an engineer look back at a specific piece of work while it’s still fresh. It’s also the most demanding of the four. It takes time, its structure is rigid, and it only works if the person is honest about why they acted as they did, which is exactly what a conversation with any whiff of appraisal about it discourages. And like most of these models, it can be filled in as a checklist without much critical thought going into the answers.
Its real limit for engineers is the length of the loop. Johns assumes the consequences of what you did are visible by the time you sit down to reflect. For an individual’s work reviewed monthly, they usually are. For an architecture decision they usually aren’t: a design approved at a review board this quarter may not be built and running for a year or more, and by then the context, the reasons and sometimes the people have moved on. That’s a long loop, owned by a team rather than a person, and it needs a different kind of model — one I’ll come back to later in this series.
So which one — the actual decision
Like most things, it depends — and here there are two axes: structure against overhead, and how long the loop is before you can see the consequences:
- Rolfe when the stakes are low or the reflection is your own and you’ll bring the rigour yourself. Fast, and fine when you’re the safeguard.
- Gibbs for a real post-incident review, where you need the structure to supply the discipline the room won’t. The overhead buys you the evaluate-then-analyse boundary that stops the group fixing symptoms, plus permission to name the human factors out loud.
- Johns for guided, one-to-one reflection on recent individual work — the development review, the mentoring session — where the loop is short and there’s someone in the room to keep it honest.
- Kolb as the backdrop for all of them — the reminder that whichever you pick, a reflection that doesn’t end in a changed action was just journaling.
The failure mode is identical across all four, and it’s always the last stage: analysis with no action plan is a diary, and an action plan nobody owns is theatre. An action worth capturing has a name against it and a date to check it — the same discipline that makes a decision record or a risk acceptance real rather than decorative.
The honest summary
Reflection is an engineering discipline, not a soft-skills afterthought bolted onto the end of a sprint. The two-column retro fails because it has no forced path from what happened to why to what changes — and everything useful lives on that path. Pick a model deliberately: Rolfe when you’ll supply the rigour, Gibbs when you need the structure to supply it for you, Johns when there’s a guide and a short loop, Kolb as the reminder that the entire point is to close the loop back into action. The model itself isn’t the prize. Being deliberate instead of ritualistic is.