Early Feedback Reduces Anger and Frustration

Have you seen a developer react after they’ve spent three days writing a feature, only to have the tester say, “Um… no” in a Post Mortem (a meeting about a project after it has finished) that went badly wrong - with lots of finger pointing and anger?

Recently in a CSM Class an attendee helped me see the emotion of the situation. The more time that has passed, the more emotion and energy we will have invested in an activity. The more energy we’ve invested, the harder it is to see new perspectives and perhaps even let go entirely.

Specification By Example and Retrospectives help by reducing the length of the feedback cycle. In the case of Specification By Example we get the team members who will be involved in implementing the feature to sit down together before any code is written. It’s much easier to accept changes before we’ve done much work on the feature. Retrospectives are similar, because they reduce the length of the feedback cycle to a point where less emotion has built up before we begin work to improve the situation.

In my personal work experience, I’ve also found that the longer we go without receiving feedback the more likely it is that there will be a problem.

For a long time when facilitating my courses I’ve had an end-of-day “Retrospective”.[1] Attendees give me feedback at the end of Day One while the feedback is still actionable. Attendees write their feedback on post-it notes. I try to make this anonymous by turning my back or using my phone when they’re posted.

Where have you noticed early feedback helping with a problem?