Project Retrospectives
Learn to answer some of the typical questions about project retrospectives.
We'll cover the following...
- Typical questions
- How do you measure the success of your team?
- Follow-up questions
- Give an example of a project that failed despite the effort and passion that went into it.
- How do you track project status, and what action do you take if the team is behind schedule?
- Tell me about a time when a major project was reprioritized and what its effects were.
- Red flags
A project retrospective is a discussion conducted at the end of a project to review the project’s end-to-end execution, successes, and failures and identify areas of improvement for future projects. Although a project retrospective can be done monthly, a major project retrospective conducted at the end of each quarter is sufficient to capture learnings from all the team projects.
It is the engineering manager’s responsibility to conduct a successful project retrospective by providing a safe and comfortable environment for all participants to express their opinions, ask questions, and provide feedback. An important agenda for the retrospective discussion should be to develop action items for the next half based on learnings from the past.
Typical questions
Let's look at some typical questions asked regarding project retrospectives.
How do you measure the success of your team?
A team's success is typically measured against its own goals. Goals can be things like building new features or improving existing ones. Success should not be determined by a post hoc process where the criteria are decided at the end of the quarter or half.
Was the team able to meet all its goals? If so, then it is a success. If not, it does not automatically mean it's a failure. You must ask to what extent did it meet them? It is rare for a team to meet all its goals entirely. The team might miss some goals, so as a manager, you need to carefully list down all of the goals for the quarter or half and then evaluate their completion and progress. Reprioritization could have changed things. After a thorough evaluation, you should decide whether the quarter or half was a success or not.
It’s also important to understand and evaluate how the projects were executed, not just based on the results.
Note: You can also make the evaluation based on a sprint, but usually, it is done for a quarter or a half.
Follow-up questions
Normally, goals should have some metrics to gauge if they are fulfilled. Let’s look at some follow-up questions about how well goals are defined and met.
How do you define the team's goals?
Instead of having a binary criterion when defining goals like whether a feature/service is built, it is better to have a clear metric such as "enable service for
Let's first look at a few examples of ...