Before handing a project over to a production or operations department or to an external customer, effective Agile teams conduct one last retrospective to officially close the project. This final project retrospective allows the team to review the project as a whole and helps team members resolve any remaining issues before moving on to new assignments.
In an article on the Sodaware.net web site, Agile veteran Steve Pavlina has several suggestions for conducting this final retrospective (or “postmortem,” as he calls it). We have summarized his suggestions below (and added a few of our own comments) to help you complete this final activity and successfully bring your project to a close:
Involving participants:
Be sure to invite everyone who contributed to the project to the project retrospective.
Schedule the retrospective and invite contributors as early in the project as you can, so they can set aside time in their schedule to attend. Solicit any ideas that they may have for improving future projects. Consider using a three-part questionnaire to collect their impressions—ask them to rate the experience on a scale of 1–10, have them answer targeted questions to capture targeted feedback, and include a comments section to let them provide open-ended/qualitative feedback about the project.
Be sure that the retrospective includes someone in the organization who has the power and authority to get things done.
Retrospectives often surface issues that are outside the team’s control so you may need to escalate these problems to someone who can ensure that they are handled appropriately.
Recording results
Record the results of the retrospective and make them available to other teams.
Document all contributions in writing and consider ways to make lessons learned accessible across your organization. Placing the results on a company intranet allows you to link to additional resources and information as needed.
Starting with project overview
Start with a project overview to reacquaint everyone with the project’s intended objectives.
Review the project’s purpose and intended customer. Describe the initial design suggestions, the estimated budget, the scheduled start and finish dates, and other relevant information.
Recording project details
Record the project details.
Include a final project description and list any problems or defects you encountered. Document the final budget and final release dates. List the development tools and processes you used and describe any innovations or process modifications you may have implemented. Be sure to list the contributions of everyone who worked on the project to ensure that they receive proper credit and to document individuals that future teams can turn to for expertise.
Describing failures and successes
Describe the project failures and successes.
List at least 10 things that went better than expected, and at least 10 things that went worse than expected. Review all of the iteration retrospectives and record all results and suggestions. Document any surprises you encountered during the project and how you responded.
Take time to evaluate individual and team performance.
Record your impressions of teamwork, individual contributions, and newly acquired individual and team skills while they are still fresh in your mind, in case you are asked to assist in performance assessments and reviews.
Evaluating risk management
Evaluate your project risk management activities.
Document the risks you took, record how they turned out, and make suggestions about how you would change your approach on future projects.
Developing conclusions and resolving outstanding issues
Develop conclusions and make suggestions.
Review the team’s velocity and the project story boards, and use that information as you forecast new projects. Describe what you think you should start doing, what you should keep doing, and what you should stop doing on future projects.
Make sure all grievances and conflicts are addressed before moving on to new projects.
Retrospectives may become emotional and conflicts may arise as teams review their performance. Reiterate with the team that retrospectives are a time to discuss what happened in the project, not to place blame for issues or problems. Moving on to new projects without resolving conflicts can cause hard feelings to be carried over and negatively affect team members.
Don’t release team members to other projects until you have completed all project closure activities.
Make sure the team is available to complete any last minute items, clarify inconsistencies, and discuss lessons learned.
Planning for future projects
Develop a plan of action for future projects.
Decide how you will incorporate the lessons you learned from this project into upcoming projects. Make sure that any items and requests that weren’t included in this release are included in subsequent release planning.
Most importantly, you have to ensure that project retrospectives are not just meetings to rehash material that the team has already covered. Unless attendees see actions and results from these meetings, they will consider retrospectives to be unproductive and may stop attending. Retrospectives should be constructive meetings that collect information but also provide plans for putting that information into action on future projects.
Mini case: Closing an Agile Project
Rachael Alvarado was trying to decide if she could forgo a project retrospective before closing out her latest project. As an Agile project manager for an aerospace parts developer in Lansing, Michigan, Alvarado had followed all of the Agile guidelines as she guided the company’s newest starter generator through its final iteration. The product was now ready for release to the market and Alvarado was ready for her next assignment.
“We’ve held retrospectives after all of the project iterations so I think we’ve covered just about everything,” she thought to herself. “The project went about as well as can be expected and everyone is eager to get on to the next challenge.”
Alvarado had met with her boss earlier in the week so she knew what her next project would be. She read through the information about the project on the company’s intranet. “It looks like most of the team will be coming back to work on our next project so I don’t think we’ll lose that much skill or information. We’ll get a few new people, like we do on every project, but not many. I still have a lot of work to do before I can start the next job, and creating the retrospective questionnaire and putting the retrospective results on the intranet are just going to add to my workload.”
“It’s probably too late to send out invitations. Everyone’s so busy and probably won’t have time in their schedules for this type of meeting anyway. Maybe I should just write up a report and circulate it for everyone’s comments and additions?”
Question
Answer the question in the textbox, then click Submit to compare your answer to an answer written by an experienced project manager.
What would you say to Alvarado to convince her that she should hold the retrospective?
Suggested/Sample Response
Alvarado needs to continue to follow the Agile guidelines and hold the project retrospective.
The iteration retrospectives may have provided feedback about each individual iteration, but the team still needs to look at the project as a whole as well. There may be suggestions or issues that team members have not voiced yet because they apply to the entire project, not about the specific iteration recently completed; those opinions would still need to be addressed.
If Alvarado simply produces a report, she runs the risk of not capturing all viewpoints and insights on the project. She deprives the team of the chance to discuss the project and to celebrate their accomplishments. Agile teams work in close collaboration throughout a project and often need closure before they can fully commit to a new project.
The fact that the project retrospective will require additional time and work is not a good reason to skip the meeting. Alvarado—and the entire team—needs to be committed to see the project to its completion before moving on to other assignments. That means completing the entire project, including the project retrospective.
Recommended for you Agile and Waterfall Project Management , What is AGILE?
