Retrospective Prompts
Sometimes explicit questions elicit answers that people don’t think of on their own. This article lists a set of questions I’ve found to be useful when holding development retrospectives, divided into three categories.
Example Lessons
Here are some examples of things I’ve discovered with these questions:
- The early parts of a project play a disproportinate role in shaping the oucome. Even if this is when effort is lowest, it is especially important to have as many stakeholders as possible present during this part.
- When integrating with existing technology, it is important to have an expert on that technology at least part-time on the project to review critical decisions, lest mistakes are embedded deeply in the outcome.
- It is easy to spend time working on things that nobody has asked for, on the idea that it “sounds like a good idea” and “someone is bound to want it eventually.”
- It is important that the people on a project all individually agree that the scope is reasonable, and there must be no shame in admitting doubt that it can be done in time. It may be tempting to use old effort estimations that may have been made by someone else in a completely different context – don’t.
- Instead of defining a project by sketching a rough implementation, it makes sense to operationally define success, and potentially add some constraints on what sort of implementation is allowed, and then let developers run free.
- Integrating with new technology always takes much longer than expected, even if the integration seems simple or corresponds closely to an example in the official documentation of the new technology.
Prompts
When these questions say “project”, you can read it as “month” or “sprint” or “spike” or whatever is the unit of development effort you’re trying to learn from.
For each question, there are implicit questions “Why/why not?” And “What should have been different for the outcome to be improved?”
Value
- Does all work integrate into something that provides value?
- Does the outcome correspond to our expectations at the start of the project?
- Were the deliverables we worked on the ones that provide the highest value?
- Would we have chosen a different set of deliverables to work on had we known then what we know now?
- Were we aware of this uncertainty at the start?
- Could we have accounted for it, e.g. by doing things in a specific order, or by making it easy to throw out and replace the early work?
- Why do we believe the chosen deliverables do, or don’t, provide the highest value?
- What deliverables were considered for the project but not included?
- Were they discarded for the right reasons?
- Was it fun and/or interesting to produce the outcome?
Planning
- Was work blocked at some point?
- Did we plan the project realistically?
- Was the scope too small, or too big?
- What indicators should we have looked for?
- Did we know ahead of time which deliverables were most risky?
- Did we take this into account when planning?
- Were there any staffing issues?
- Could we have known from the start?
- Were the right people on the project?
- Did we pick the right trade-off between knowledge sharing and expediency?
- Was effort evenly distributed throughout the project, or was there high variation in effort?
Knowledge
- Did the team have the appropriate prerequisite knowledge?
- Did the team acquire the right domain knowledge?
- Technical knowledge?
- Are the important parts of this knowledge documented?
- Can we see the documentation?
- Did the team talk to the right people?
- Was learning interesting and/or fun for the individuals on the team?