TL;DR
Agile frameworks like Scrum are founded on empirical control and validated learning, so "failing fast" is not inherently a negative. In fact, canceling a project that can't be salvaged is often the best way to avoid chasing sunk costs. However, understanding the Five W's of the failed project can lead to process improvements if and only if the Scrum Team, the organization, and the stakeholders collectively approach it as a process improvement exercise rather than a means of affixing or deflecting blame.
There's no canonical format for conducting either a retrospective or a postmortem. However, defining the purpose of the meeting and adhering to a fixed agenda can ensure that the focus is kept on lessons learned rather than finger-pointing.
Postmortems Aren't Agile Retrospectives
Retrospectives are inspect-and-adapt ceremonies for process improvement. They are emphatically not:
- the right place to celebrate expended effort for its own sake; or
- the ideal venue for exploring project failures.
While postmortems are important, they require a level of honesty and organizational maturity that often requires active listening and hands-on meeting facilitation. There's no "one size fits all" agenda for this type of meeting, but you should start by laying out an agenda ahead of time, and ensuring that the meeting doesn't devolve into a blame game.
Recognizing Effort is Fine; Celebrating Failure Prioritizes Effort Over Outcomes
The idea is to reflect on the hard work that was done and gain insights why the project maybe didn’t work but also kind of celebrate all the hard work.
Understanding why a project didn't succeed is important to the business, and (possibly) to the team. Likewise, understanding the reasons a project failed may provide some valuable lessons for future work. However, celebrating unsuccessful "hard work" teaches the team that presenting a highly visible level-of-effort is more important to the organizational culture than delivering actual value. This is very much an anti-pattern.
Analyze the Failure
The project was cancelled because the product failed in the market.
"Failed in the market" is a bit hand-wavy. Failed how? Was it avoidable? Why didn't the empirical control process foresee the impending failure? Why was the process unable to self-correct before failure became inevitable?
This isn't about affixing blame. It's about process transparency and understanding where the process broke down. That requires charting a very narrow path between identifying things the team could have or should have done without accepting unwarranted blame. If the project failed due to external factors that were unknowable, that's unfortunate but understandable. More likely, though, the project failed because the process didn't deliver sufficient value (regardless of how much "hard work" was involved) or make the right problems visible.
Adhere to an Agenda
It's impossible to offer a fully-prescriptive agenda, but you need to ensure that you have one. Make sure that everyone involved has a clear understanding of the agenda items, and keep the meeting from veering off-track from the agenda. In very broad terms, a postmortem should:
- Identify what went wrong at a process level.
- Determine why the process failed to detect and/or correct the problems before failure became unavoidable.
- Recommend how the process can be improved next time.
Whether the process failures were internal or external, the bottom line is that the process should have detected potential failure as early as possible, and likely could have done something proactive before failure became inevitable. With that said, agile frameworks are about validated learning, so "failing fast" is not inherently a negative. By measuring the value of early termination in terms of ineffective costs saved rather than ineffectual effort expended, the organization will be better situated (if not necessarily able) to redirect its limited resources to something more likely to succeed.
