This type of retrospective is great for teams working on a new product with a given deadline. The idea is simple – just imagine that the launch date has come and the product… failed miserably. Yes, imagine you failed.
It’s important to imagine it in great detail and capture all possible problems, even if they seem unlikely to happen, they are outside your control or just seem silly. Ask people to get super creative, the sky is the limit here.
I was surprised how quickly my team generated so many post-it notes with potential problems written on them, that they didn’t fit the designated box and we had to double its size.
For a moment we completely lost the confidence in the product… We knew the deadline was tight, but it still seemed doable (before). Looking at the board covered completely with potential problems was an eye opening experience – yes, there is a chance of failure…
Luckily – there is still some time left and there are things that can be done to prevent or mitigate the issues.
We started from grouping the problems into themes.
Having stakeholders participating in the exercise turned out to be very beneficial, as the dev team focussed mostly on technical issues and less on the business side of things. The success of the product is however a complex thing and stable software is just one of its factors.
After grouping all the problems into themes we discussed which of them are real show-stoppers and which are likely to happen. We also excluded the ones we don’t have any control over and focussed on remaining issues.
It turns out that there are quite a lot of things we could do to mitigate the risk of failure. We have generated a list of actions and scheduled some of them to happen really soon, i.e. meeting an expert in the area of where the product is going to be used. Other actions will rather be ongoing – i.e. ensuring a fast feedback loop by engaging in all sorts of activities with potential business users.
- You’ll uncover potential problems, which might have been a taboo till now.
- Proactive approach mitigates the risk of failure.
- Stakeholders manage their expectation better by understanding the technical challenges better.
- Dev team understands the business perspective better and how critical their work is.
Attitude to failure
I believe in being proactive, but I’d like to stress here, that avoiding failure is not the point. Paraphrasing Matthew Syed from his excellent book titled ‘Black box thinking‘ – we need to change the attitude to failure. Stigmatising failure will lead to fear and might blind us to bigger problems. Failure is (!) good. So, fail fast and learn fast!