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”. 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?
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.