After the retrospective, don’t try to tackle all the issues identified immediately. Choose up to three issues initially from the top of the priority list; the rest will still be there for future follow-up. Write an action plan that describes your improvement goals, identifies steps to address them, states who will take responsibility for each activity and lists any deliverables that will be created. Assign each action item in the plan to an individual who will implement it and report progress to the action plan owner. At your next retrospective, check whether these actions resulted in the desired outcomes. An action plan template is included in the process assets that accompany this book.

An action plan that doesn’t lead to concrete actions is useless. I once facilitated two retrospectives for the same development group two years apart. Some issues that came up in the later event were the same as those identified 24 months earlier. Failing to learn from the past practically guarantees that you will repeat it.

Note

An action plan is never created, or it is created but never implemented. If this happens more than once, the team won’t believe management is serious about making changes and they’ll opt out of future retrospectives.

The project team is the best source of information about how a recently completed project really went. You can use a retrospective to help your team assemble a rich picture of the project, so the manager can use that information to create a more effective environment the next time. But all organizational change takes time, patience, and commitment from all stakeholders. If people really don’t want to change, they won’t.