These resources (which include the content from the book, and where appropriate, downloadable tools) are only available to folks who have purchased the book. Get in touch if you’d like access.

The faster you go, the more often you need to learn

The postmortem, at the end of the project, to capture lessons learned, seems productive but prevents teams from identifying patterns and addressing systemic issues within the timeframe of the project. The pressure to deliver can make reflection feel like a luxury—and as a result, push it outside the timebox of the actual project—but without structured retrospection, teams repeat mistakes and miss opportunities for improvement.

When reflection does happen, it often focuses solely on problems or becomes a blame game, missing the opportunity to reinforce positive patterns and build on successes. The postmortem is doing what it says on the tin: The project is dead; why did it die?

📖
The practice of systematically reflecting on work and team effectiveness predates the Agile movement. Norm Kerth gets credit here for formalizing “project retrospectives” with his influential 2001 book, Project Retrospectives: A Handbook for Team Reviews. His approach was projectcentric, usually involving post-project reviews. In 2001, retrospectives gained further momentum from Agile Manifesto principle 12: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Retrospectives create intentional space for teams to step back, examine their work patterns, and deliberately evolve their practices. Unlike casual discussions or complaints aired in hallways, retrospectives provide a structured container for honest reflection and collective learning.