An agile retrospective is a safe space. We can reflect on the week, think through our victories and defeats, and say what we feel. If your team is a ship, the retrospective is the captain. The captain looks at where you’ve been, thinks about where you’re going, and course-corrects as necessary. Without a retrospective, you’ll likely end up blindly sailing straight into a hurricane.
The retrospective is a critical departure from our day to day process of pair programming. When we pair, we’re focused on the problem directly in front of us. We have to put two minds together to solve that problem, and this requires a surprisingly intense amount of focus. It’s not a process that lends itself to introspection and reflection.
The departure from that day-to-day into a retrospective leads to an interesting communication challenge. Consider this: when we pair, we solve problems by thinking out loud and arriving at solutions collaboratively, organically. Minds meld. Buy-in is a given.
But in a retro, we might arrive at a conclusion without consulting anyone else. And when we present it, the team may disagree, but it’s not always obvious how to resolve that dispute.
Let me give you a real example. Once, on a project, a new client developer joined the team. He was a very experienced, highly competent developer, but he was new to pairing, TDD, XP. A couple weeks in, he stated in a retro, “I think we’re testing just for the sake of it.”
As you can imagine, this ruffled some feathers. We instinctively disagreed, but without knowing the context of his statement, the argument basically boiled down to this:
“No, we’re not.”
“Yes, we are.”
“No, we’re not.”
“Yes, we are.”
Clearly, we needed to know more. And then something happened. Another client developer on the project who had been on it for several months said, “Can you give us some concrete examples of tests that lead you to this conclusion?”
And then everything became clear. Once he described what he was reacting to in the test suite, we were able to hone in on the real issue. The new client developer was seeing tests at the acceptance layer that provided very minimal, common path verification. He wanted to see more edge cases fleshed out, but didn’t yet understand the relationship between high-level integration verification and low-level unit testing.
Whenever you hear a conclusion in a retro that you don’t agree with, ask “Why?” Try to understand what lead them to their conclusion. You can argue with someone until the cows come home, but without understanding the context of their statements, you’re not likely to reach any sort of resolution.
