Agile Retrospectives

9.4 A Retrospective at Every Ending

Since this book is focused on short retrospectives that follow every iteration, we haven’t covered the release and project retrospectives in depth. We’ve simply pointed out some of the major differences. If you want to learn more about end-of-project retrospectives, we recommend Norm Kerth’s book Project Retrospectives: A Handbook for Team Reviews [Ker01]. You can also join the email-based retrospective discussion group. And you can always contact us for resources and recommendations.

Even if you’ve been doing iteration retrospectives, it’s still worth the time and energy to have an end-of-release or project retrospective. People look at different issues and learn different lessons when they take a longer, broader view. Even when the team doesn’t stay together, people take that learning with them to benefit other teams and other projects. Release and project retrospectives uncover organizational factors, policies, and procedures that get in the way of the team—and these require coordination across areas to solve. Without the broader view, problems remain hidden or are attributed to the wrong source.

So, hold a retrospective at every ending point. Your teams and your organization will learn and improve as they step back and reflect. Help your team manage their actions, and support them through change. We’ll tell you how in the next chapter.

Copyright © 2013, The Pragmatic Bookshelf.