retrospectives
Go over your projects to determine what went well, what didn't go well, and how you can improve in the future. This is useful for projects you do yourself, as well as larger projects with lots of people. This is essentially how retros are run in Scrum.
In general, the focus should be on systems that didn't work well. There are often culprits, but usually we can pin issues to failing systems. This is immensely more productive than trying to say one person caused a large-scale problem. This is not always true, but it usually is.
Preparation
Send out a list of topic for the team to discuss ahead of time. This will make sure everybody can get their ideas heard and common thoughts from everyone can be collated together. Seems good to rewrite the questions or concerns, or group them together ahead of time. This makes it so that individuals aren't singled out when it comes time to bring relevant parties together to chat about issues.
Before the event, submit the topics out to everyone in a prioritized lit to ensure that if time runs out, you still get stuff done.
The Retrospective
For each topic,
- Agree on the facts. Everyone can (and often does) have different perceptions and storylines of what happened. This must be done before going forward.
- Analyze what was good and what could be improved. Focus on the process and the systems, not on the individuals. People feeling shame will get you nowhere. Solving a systems problem is the fastest way to ensure nobody makes the same mistakes again.
- Find ways to implement the improvements. Make concrete actions that will help achieve the desired outcome.
Afterward
Send out the insights, decisions, lessons, and actions from the meeting. You need to make sure the actions get implemented! If you don't, you'll be losing lots of good work.
References
Last modified: 202611081913