The sailboat retrospective is a model that I especially like to use at the end of significant chunks of work, like a release or the end of an epic or the end of a project. But it could be used at any time, especially if there is a need to better understand project objectives, risks, hindrances and helpers.
I like to use this model for post release retrospectives because it helps the team to focus on lessons learned around unexpected risks, the things that slowed the team down and celebrate the things had really helped us.
A simple retrospective exercise I like to use is the ‘one-word retrospective’ found in Getting Value out of Agile Retrospectives by Luis Gonçalves and Ben Linders. This exercise is particularly useful for helping teams deal with their feelings.
Simply ask every team member to summarize in one word how they felt about the last sprint.
I’ve been thinking a lot recently about the size of user stories in agile projects. The idea that I’ve been reflecting on is what if teams only worked with small, similarly-sized pieces of work, rather than exponentially larger blocks of work?
In theory, small user stories should be more predictable, should include less risk, less uncertainty and less complexity. They should, therefore, take less time to complete than larger user stories… you would think! Or as Mike Cohn put it in Agile Estimating and Planning (Prentice Hall, 2006), “small stories keep work flowing”.
One of my favourite books on agility is The People’s Scrum (Dymaxicon, 2013) by Tobias Mayer.
A lot of books on agility focus on the mechanics of how it all fits together, who needs to be where doing what with whom in order for the machine to work more effectively.
This book is different. It focuses not on the how, but challenges the why. It is open to critically questioning every aspect of agile with the intention of uncovering the core drivers behind agile practices.