Effective Retrospectives
Here's a question worth sitting with before your next retrospective: do you know what problem you're actually trying to solve?
Most teams don't. They run a Start/Stop/Continue and walk away with a list of action items that feel productive in the moment and quietly die before the next sprint. Not because the team didn't care, but because they skipped the step that makes any of it stick.
Start/Stop/Continue is a solutions framework. "We should stop doing X" is an answer. But to what question? If the team hasn't agreed on what dysfunction they're actually observing, you can't know whether the fix will work, or even whether you're fixing the right thing. So the same items come back next sprint. And the sprint after. The format doesn't generate new ideas; it generates familiar frustration on a two-week cycle.
Effective retrospective improvement follows a direction. You start with effects: what are we actually observing? Not how do we feel, but what do we see? Where is delivery unpredictable? Where are we working hard but not shipping? Where is trust visibly low? From there, you trace back to causes: what practices, habits, or absence of habits are producing that pattern? Only then do you reach for changes: what would actually move the thing we named?
The framework I use for thinking about software delivery has two categories: Attributes and Tools. Attributes are the observable effects of how a team is working: things like Transparency, Alignment, Focus, Quality. Tools are the levers that produce those effects: ceremonies, processes, practices, norms. Retrospectives are where teams reach for Tools. The problem is they often haven't looked carefully at their Attributes first.
A retrospective structured around this runs three questions in sequence: What Attributes are we seeing? Which Tools are contributing to them? And what Tool changes would actually move an Attribute? Start/Stop/Continue belongs at question three, after the diagnosis, not instead of it.
The teams that improve aren't the ones with the most action items. They're the ones who can name what they're trying to move, and who check after a few sprints whether it moved.
