Giving feedback

Giving and receiving feedback is a difficult task but it is also extremely important for any team. For a while I didn’t realise that giving feedback that wasn’t good enough, might actually be pointless or even lead to frustration.

There is an excellent team exercise that illustrates the case.

  1. Sit a team member on a chair and give them a set of tennis balls (the more the better).
  2. Place a bucket behind the person (best at an angle), so they can’t see it.
  3. Ask the person to throw the balls behind them one by one (without looking), so the balls end up in the bucket.

feedback chair

Now, consider following scenarios:

  • Scenario 1: The person gets no feedback at all, but is still expected to place the balls in the bucket.
  • Scenario 2: Very negative feedback (i.e. ‘that was useless!’) is given when the balls miss the bucket.
  • Scenario 3: Very positive feedback (i.e. ‘well done, keep trying!’) is given even when the balls miss the bucket.
  • Scenario 4: Constructive feedback (i.e. ‘a little bit more to the left’) is given at any time.

Now ask the person how did it feel.

In Scenario 1, it’s a pure lottery. The person does not have any chance to improve.

Scenario 2 is actually very frustrating. The person is trying hard but the effort is only criticised. If you try that for long enough, the person might get annoyed and refuse participating further.

Scenario 3 is not much better. It is definitely motivating but not helping. Giving only positive feedback is not enough to improve!

Scenario 4 illustrates the best way of giving feedback – informative and honest. Feedback that will help adjust next steps, so eventually the goal can be reached.

From now on, I am going to ask myself before giving feedback –  is it going to help the other person or is it just words?



Pre-mortem retrospective

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.

Get proactive!

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.

Problem filters

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.

Key benefits

  • 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!