Cancelled project retrospective format

Question

Can anyone recommend a retrospective format for a cancelled project?

The attendees will be the development team but also some of the more senior stakeholders.

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.

The project was cancelled because the product failed in the market. The team is disappointed. It’s very niche and their skill sets were specifically sought for this project and doing other work is not really what they want to do and lower pay people could do it

Answer 1

I think it needs to be approached like any other end project retrospective. The difference here is the project has been canceled.

1. It's important to review the last scrum process and understand what went wrong and what went right and how can we continue improving for future projects. (Lessons learned)

2. It's important to understand why the project has been canceled and how it can be avoided in future projects. (Important for the executives and team)

There are many reasons for a project to be canceled: Don't achieve the needed time to market, lack of budget wrong technology, expectative management, change in the company strategy, lack of skills needed for the project, and many others...

And if the reason is identified it needs to be feedback for the company for future improvement.

The most important thing is to keep the focus on the problem, never on the people. In that way, you avoid exposing the team and step in the executive's foot keeping the morale of the team.

Answer 2

There are two different aspects that you want to focus on in this retrospective: product failure and the work team members have put in.

For product failure, one format could be a timeline of all the product decisions taken during the project. Collect data of all the things that have happened with the product, decisions take, feedback received, etc., and map them out on a horizontal line with dates (this can be done before the meeting takes place).

Next, the team members and stakeholders can add sticky notes (paper or virtual ones in case it's an online retrospective) to share their insights and feelings. Optionally you can use smileys or a rating from 1-5 whether moments were felt as low or highlight. Pull out some of the key moments from the timeline (if needed do a dot vote) and discuss those to learn and decide what to do differently in the future.

To celebrate the hard work and show appreciation for the skills that team members brought in, you can help the team explore the core qualities and strengths that they have (see https://www.benlinders.com/2015/exploring-strengths-with-core-qualities/). If the culture feels safe enough you can do this together with the stakeholders, if not then it might be better to arrange a separate meeting where the team reflects alone.

For both exercises, facilitation is key. You want to prevent blaming, keep everyone involved, and ensure that there's an atmosphere where people feel safe to speak up.

Answer 3

You're conflating several competing objectives here. Celebrating the hard work or worrying about future, less challenging work is not an objective of a retrospective. If you want to celebrate the work performed, then go celebrate. That would involve food, drink, and someplace nice to socialize. If you want to worry about future work, that would involve strategizing where you want to go. If you want to think about what worked and what did not work in your closed project, then do a retrospective. I know this does not answer your question directly but I hope it steers you differently.

Answer 4

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:

1. the right place to celebrate expended effort for its own sake; or
2. 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:

1. Identify what went wrong at a process level.
2. Determine why the process failed to detect and/or correct the problems before failure became unavoidable.
3. 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.

Answer 5

Retrospectives you're thinking about happen in a safe, friendly environment. Where people are not judgmental. Where if someone is to blame - others will be there to support and help fix the problem. It's about team fixing problems within the team.

The meeting that you're about to have is a post mortem where someone is to be blamed, but most likely no one would want to take an active position and so nothing actionable will be discussed. So ask yourself:

• Will this group of people keep working together on next projects?
• If one of devs/stakeholders/you is to blame - would they accept the blame and change their behaviour in the future? Would someone dare to express this thought?
• Is there someone on the meeting higher than stakeholders and developers? Who can make cold, objective decisions regardless whose fault it was?

If answers are sound YES - then it's a typical retrospective. If NO - then you better run a series of one-on-ones, gather opinions, think on them. And talk to someone executive - someone who can make decisions based on the data that you gathered. As for the retro meeting - just make it a short, typical "good work, well done, but the conditions we were exposed to were too harsh and hence we failed".