I was introduced to June by my friend, and virtual collaboration expert, Judy Rees. June and I had a wonderful chat on the phone, during which he introduced me to a fascinating new way of looking at retrospectives. Since then, I couldn't wait to share it with all of you. By way of background, June is the founder of the Korean Agile/XP community and the owner of his own agile consultancy.
YOUR STORY
David Horowitz (CEO, Retrium): You're an agile coach. Tell me about what you do.
June: What I mainly do is coaching agile coaches. That is my number 1 priority.
David: How did you get started in the agile world?
June: In 1999, I got interested in the original Wiki (c2.com) and learned about Extreme Programming. It was a shocking experience. I started to experiment with it. And in 2002, I was in a group of people developing a research software and I helped them using Extreme Programming. Since then, people have come to me to help them adopt Agile.
ON RETROSPECTIVES
David: How important are retrospectives to an agile team? Why?
June: If what you mean by a retrospective is a "highly formal and ritualized ceremony" then I think it is not very important. If instead you mean a way of looking back to improve via feedback and sharing, then I think it is very important. Feedback and sharing are critical to making agile work.
David: You have a unique approach to retrospectives. Can you tell me about it?
June: Yes. I've been teaching retrospectives to people since 2000. I taught them how to lead a retrospective (whether it was 1 or 2 hours long). For example, you start from check-in and then you gather information and blah blah.
But their retrospectives weren't working, so I started to analyze why they failed. Here's what I found.
People generally do not have a sufficient opportunity to lead formal retrospectives. And there are so many elements -- many people, various topics, and etc -- intertwined in a complex fashion. That slows down the learning even more. Together, that means people have insufficient trial numbers and high cognitive load (hence, you do not see the reason of failure even if you tried actually and failed).
Doing retrospectives well requires muscles. The retrospectives muscles have got to build up, but the first situation is too difficult and there is no time for the muscle to grow up.
[bctt tweet="I've been teaching people to run 30 second retrospectives first."]
I tell my students that they are in front of an elevator and there are 30 seconds before the elevator arrives your floor. Your teammate is standing next to you. Do a retrospective session with him. Now, start!
Here's what that does for you:
- Your retrospectives will have a shorter duration and fewer elements. So the probability of your observing, analyzing, and learning something from that gets higher.
- There are comparatively more chances to try (and practice) them in your life.
- You have less pressure of failure (it's just a 30 seconds, even if it fails) and so you can be bold and challenge yourself more.
- Through that time, the trust between you and your teammate builds up and your social capital accumulates, which makes your next retrospective much easier and more successful.
- You don't make a big mistake (such as gathering people and telling them "starting today, we are going to do retrospectives"). This destroys trust -- suddenly calling in people, telling them that you are starting a new type of meeting, and behaving as if you are the expert makes people's autonomy and self-efficacy low.
- All of these help build up your retrospectives muscles, and you are at a more advantageous position to try a more complex retrospectives next time.
What is interesting is after a 30 second retrospective, how terrible you are at retrospectives becomes immediately apparent. And so learning happens.
After this 30 second retrospective, you can build up to 5 or 10 minute retrospectives. Eventually you get to a traditional 1 hour retrospective, and so on.
I try to apply the same principles to all sorts of complex skills. (Yes, doing retrospectives is a very complex skill and the usual way of lecturing is really poor at teaching complex skills.)
David: Describe one of your success stories using your retrospective approach. Why did it work well?
June: Here is a telling story. A team leader came to me and told me that he was worried and dissatisfied with his team. Especially how they behaved in retrospectives. They were passive and just going through the motions.
When I asked how he ran his retrospectives, he told me that he has a set procedure and that he led his team through the steps.
After my coaching, he changed his approach. He started doing micro-retrospectives whenever and wherever possible.
After two or so weeks, he came back and told me: it was like the difference between heaven and hell.
First of all, he realized that the problem was more on his side rather than his team's.
Second, he realized that large and formal retrospectives are much more difficult, and no matter how many trial retrospectives he had under his belt it hadn't built up his "retrospective muscles".
He found that his new approach was not only easier, but also enabled learning. Even better, the team built up trust and psychological safety through the many micro-retrospectives.
David: Do you think this approach would work for distributed agile teams? Why?
June: Yes. Distributed agile teams is an even more difficult situation. You need this approach more than ever.
---
I'd like to thank June for taking the time to do this interview with me. I learned something new. More importantly, I learned something valuable. So if traditional retrospectives aren't working for you, consider the 30-second retrospective. I know I will.
Distributed team? Want to run effective retrospectives? Try Retrium today.
