Yes, so, my experience, mostly my experience comes from Denmark is that the Agile teams are doing retrospectives because they are told to do so. Most of them are doing it because they think it is something that is a part of the Agile package and thus what they are doing is the simplest and the smallest thing that they can call a retrospective. Some people are doing it very well, but I also see a lot of incidents where people are wasting time with retrospectives and are being really miserable about it.
3. You said wasting time, can you give some examples of that?
If you call people into a retrospective in order to inspect and adapt which is the reason for having the retrospective and you just have a round table meeting where people say “How is it going?” “It’s going ok” or “We have this problem” and you spend an hour on that, then if you don’t come out with some action points, that you can actually do, some things that you want to change, if you don’t come out having shared the experience that you had in the last sprint, or the project, then I think it is a waste of time. And that is also how some developers see it that the retrospective do become a waste of time if there are no results coming out of the retrospectives.
Several kinds of barriers I would say. One important barrier is the view on retrospectives, as I mentioned before. If you see retrospectives as something that you should do because it’s part of the Agile package, then you tend to do the minimum that you think you can call a retrospective, so that is one barrier. So what you should do instead is you should ask yourself: what do I want to get out of having retrospectives? If it is inspect and adapt, if it is sharing, if it is changing, trying new experiments, than maybe you should try learning a bit more about how to actually facilitate retrospectives and learn how to use the five phases of retrospectives and get something out of it.
That’s one barrier, I would call it ignorance about what a retrospective really is. Another barrier that I see is that in a retrospective, if you do the activities that you can do in a retrospective a lot of them are actually fun and some developers are afraid that if it’s fun then it’s not really serious enough to be called work. So I do see a barrier in the culture of the developers, again I am speaking mostly from Denmark here, the culture of the developers is that it has to be serious to be something that is worth while.
If it turns out to be fun or playing around throwing a ball or using a lot of colorful post it notes, then they say “Well it’s ridiculous, it’s not worth spending time on it”, so that’s another barrier. And the third barrier I see for doing retrospectives not as efficient as they should do them, is that people don’t have the right mindset when they go into retrospectives. They don’t think of the prime directive so they might have some assumptions about other people doing things in the wrong way, thinking other people are stupid, and on the other hand people can be afraid of going to the retrospectives, so these are the main three things that I see.
That’s a good and a very big question Ben. Facilitating retrospectives is actually a lot more difficult than people think it is. People think that facilitating a retrospective is just getting people to sit down, maybe going through the activities in a book and making people come up with post it notes and ideas and coming up with some action points. But it’s much more than that: it’s also something about communication between people in a group, it’s about the hierarchy in groups, it’s about body language, it’s about being able to feel the atmosphere in the room, do they need a break, also being able to figure out here is a pain point and they want to skive off over that really quickly but maybe you need to focus on that and drill down into that even though it’s painful.
So it’s a lot more that just knowing the activities and I think that people don’t put as much attention to as they maybe should. They think that an experienced facilitator is somebody who knows a hundred and twenty activities, in my viewpoint a skilled facilitator can get along with maybe ten activities, as long as they can use it in the right way at the right time. So when I say activities I mean for instance from a book like this “Agile Retrospectives” by Diana Larsen and Esther Derby, it’s got a very good description of activities you can use for Agile retrospectives and shorter retrospectives. And another book that I like to point at is also this what I call the original book by Norm Kerth “Project Retrospectives”.
It contains descriptions of retrospectives that are longer, two to four days long, because it was made in the time when projects went one or two years before you actually had a retrospective, but some of the activities described in this book can also be used for Agile retrospectives. In both these books there are not just the activities but also how you enhance the communication, how you make the quiet people talk, and also how you control yourself, because as a facilitator you will have reactions, you will have feelings, as a response to the things that are going on in the room and you have to handle yourself as a facilitator as well.
Yes, so often when I come out to a team that has been doing retrospectives for a while they say “Our retrospectives have become stale or even boring” and I ask them what do you normally do, “We do timeline, and then we do dot voting, and we do five whys and then we do dot voting, and then we make smart goals, and that’s what we do and we do the same every time”. And I’ve got a couple of different suggestions for people: one suggestion is that you change the role of the facilitator to somebody else, because often you end up having the Scrum Master facilitating the retrospective every time. And it will be worth while to make somebody else from the team facilitate, because it will give you new input, it will give you some new ways of facilitating and also the person who is now trying to facilitate will be able to recognize that it’s actually hard to facilitate a retrospective and maybe give the Scrum Master more credit when he or she does it again.
Another thing as I said before even though to my experience you don’t need to know a hundred and twenty activities, it can be a good idea to look to one of those books or maybe Patrick Kua’s E-book or other places on the Internet where there are some activities and try a new activity, try something more playful maybe some gamestorming, maybe like to like, maybe something else more physical that can put some more energy into your retrospective.
I think the most vital skill for a facilitator is to be able to listen to what people are saying and not be afraid of the silence. I see some facilitators rushing through their agenda not really listening to what people are saying, listening to the mood that people are in, and they don’t make the most of the moment because they forget to notice some things that are important that they should be doing something about diving into as I said before, drilling into a focus point. So I think listening is very important, and also being able to accept silence, I think silence is important when you are giving talks, when you are teaching but also when you are facilitating. Allow people the time to think and reflect and don’t think that if they are silent that is a bad thing.
One thing, I think the most important thing for me would be if everybody doing retrospectives would accept and respect the prime directive by Norm Kerth that when you enter a retrospective you should do it with a mindset that everybody all the time did the best job he or she could given the skills and abilities at hand and circumstances they were in. If I could make that happen for everybody entering a retrospective I think it would make a huge change because people would be again listening more to each other, instead of listening to their prejudices and assumptions about why these people didn’t do what you expected them to do.
Ben: Thank you very much Aino for this interview.
You’re welcome Ben it was a pleasure.