Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Interviews Aino Corry on Agile Retrospectives

Aino Corry on Agile Retrospectives


1. Hi, my name is Ryan Slobojan and I’m here with Aino Corry. Aino, what is a retrospective, and more importantly, what is not a retrospective?

A retrospective is basically a chance to reflect and learn on what has happened. And things that are not a retrospective are meetings where you do not get the chance to actually reflect on what has happened - where you don’t gain an insight in what has happened and thus you cannot learn from what has happened. And what I see is a lot of retrospectives that are labeled retrospectives that are basically just working on the symptoms of problems.


2. So how do you make sure when you’re going through a retrospective that you’re getting down to the root cause of the issues with things that can be addressed as opposed to just kind of fighting the initial symptom?

What I do when I facilitate a retrospective is that after we've gathered up the data, we all look at the data in different ways. We try to generate insights, looking at what stories the data can tell us and when we find something which we can label as a problem, an issue or a challenge, we’ll look deeper into it using maybe the fishbone or the 5 why activities to see what is actually causing this problem. So, instead of working with the symptoms, we can go deeply into the root of the problem and work with the root of the problem.

And it can be difficult to say whether you actually hit the root of the problem, the cause of the problem but you’ll try to go as deep as you can until you don’t feel you can go in deeper.


3. You have mentioned fishbone and 5 whys, what are those? How do they help you to get to a cause?

They are activities that you can use in a retrospective. You can use them in all kinds of meetings actually. For instance, take the 5 whys, if you could see that software has not been tested in the proper way, it might lead you to a conclusion that it’s a stupid testing person that didn’t test the software accordingly, that might be the symptom that you see and you might find the cause to the problem being that the tester is stupid.

If you use the 5 whys, you ask, "Why wasn’t the software tested?" It wasn’t tested because the one who is supposed to test it didn’t know enough about what the functionality was supposed to be in the software; why didn’t this tester know what functionality was supposed to be tested in the software? Well, because we weren’t able to communicate that to the tester. Why weren’t we able to communicate that to the tester? Maybe because the tester is sitting remotely; maybe because the tester is speaking another language; maybe because the tester does not have time to listen to what you’re saying; or you don’t have the time to do it.

When choosing one of these, you’re making another question based on the answer. For instance, if you say, "It’s a remote tester." Why is it a remote tester? Well it has to be as remote tester. Can we do anything about it? Then we can start looking at the cause of the problem.


4. And is fishbone very similar or is it different in some ways?

It’s different in the way that when you’re making the fishbone, you’re drawing a fish, and you’re drawing different bones out from the backbone of the fish and then you’re looking at different types of causes for the problem instead of just tunneling with the 5 whys into one root cause, you’re looking at different causes of the problem.


5. So which classes of the problems do you think those approaches are better suited for? You know, the 5 whys is good for ‘x’; or fishbone is good for ‘y’?

I think actually both activities can be good for all sorts of problems but I would choose one or the other depending on what kind time I have to do this. I would use the 5 whys if I have a lot of problems that I wanted to get the cause for and it’s very easy to put the people into pairs asking each other this 5 whys, getting root causes for the many different problems at the same time in parallel. When you’re doing the fishbone, it’s more a common thing that you’ll do together with the whole room.


6. One of the other question I have is: as far as the number of people in a retrospective, how many is not enough; what’s kind of the right size; is there too many; what’s a good boundary, upper and lower, for that?

It depends as we always say with retrospectives, I would say that the optimal group number for retrospectives is between 7 and 15; based on my personal experience, if you are less than 7, or when you’re less than 5, I’d say, it might feel a bit awkward to use these activities to enable the discussion. Maybe you’d be better off just discussing in the old-fashioned way.

If you’re a lot of people, it will be very difficult for everyone to participate. It’s very important for a retrospective that everyone participates in the retrospectives and that they feel heard so that they have a buy-in to what you decide to do in the retrospective.

If there are 70 people in the room, it’s very difficult to give them all time to reflect and a time to talk about what they felt happened. That being said, I have facilitated retrospectives for 80 people and I only had one hour and of course, it didn’t give everyone a chance to reflect and a chance to learn but it gave us an opportunity to let them all in parallel write on PostIt notes things that happened to them whether they were happy about it or not happy about it. It gave them a possibility to get offloaded with these incidents that happened during the event and it gave us an opportunity afterwards to look at all these feelings whether they are positive or negative towards these incidents.And then, we, as organizers could learn from it.


7. You mentioned incidents; are retrospectives something which are more incident-driven? Or do you see them as a normal cadence as part of the sprint process or both?

I see them as both. In the old days when the project retrospectives started, if you look at this book by Norman Kerth, the first book written about retrospectives, it was something that happened after a project has ended. It was a project retrospective for the whole project. It would take maybe two days, three days even and it will be an incident, retrospective,s you might say.

Nowadays, with the Agile process development, and we got this book about Agile Retrospectives, and this book is by Diana Larsen and Esther Derby is telling you about how you can make shorter interval retrospectives. And these are then the regular retrospectives that you‘ll make during project development.

So for instance, for every sprint every two or three weeks, you make one hour or 1 ½ -hour retrospective as a heartbeat to see whether the team is evolving as it should and the project is evolving as it should. But you can also ask for a specific retrospective based on some incidents, something that happened.


8. Interesting. What’s an example of an incident that will generate that kind of retrospective against out of band?

I'll say that if the team changes a lot, for instance, if you’re merged with another team; or, that your team has been cut down so that maybe only half the people are left, things like these have an impact on the team energy and the team work and definitely also on the project development. So, if something like this happens, I would say that you could make a retrospective after a few weeks after the incident to see what other feelings around this, having any problems emerged that we should talk about now out of the ordinary heartbeat retrospectives. Then you’ll have a certain focus on this retrospective and that will make it more focused on specific theme. Or the incident.


9. You also mentioned that it was good for everybody to participate in a retrospective. It seems that whenever you have a group of people together, some people are inherently more conversant, like me for instance, and some people will tend to kind of linger more in the background. So, as a facilitator, how do you draw out that input from people that are, I guess, wallflowers?

So first of all, there are five different stages in a retrospective: the first one is set the stage; and when you set the stage for the retrospective, what you do is like you try to make everybody say something, psychologically speaking, if somebody has said something, it’s much easier to say something again. If you can pass on saying anything in the beginning of a retrospective, it’s much easier for you to keep quiet for the rest of the retrospective. But once you’ve said something, it’s much easier to say something again.

So, one of the most important things for me is that when I set the stage, I hear something from everyone. It could be their name and role in the company; it could be how’s it feel like to be part of this team; it could be how do you feel about the project as it right now.

And then once you’ve set the stage like that, maybe you’ve even made some ground rules saying how you can communicate; maybe you have a talking stick so that only one person can talk at a time; maybe you have a ground rule saying, "Nobody can make fun of anything because we have to sort of have a more strict atmosphere." And then once you have created that atmosphere, you have to try and get everybody to participate by using different activities for making people participate.

For instance, if you’re always doing your discussion in the forum, then it might be difficult for some of the people who want to be wallflowers, as you say, to stay wallflowers but when you divide the people in the room in different groups, it’s more and more easy for people to communicate.

So what you could do is that, if we have ten people in the room; first you divide them into groups of five, if that doesn’t help, if you can still see that somebody is quiet, you divide them into smaller groups. And in the end, you can divide them into pairs because then they’ll have to say something, then they have to participate.

And once they’re down to pairs, you can start expanding again after that after they have had some time to talk together because some of the wallflower people are wallflower people because they don’t trust themselves and their own opinions but once they’ve had a discussion with just another person and they can see that there’s resonance in what they believe, it’s much easier for them in a larger group to articulate what they feel about things.


10. One of the things that I recall from retrospectives that I’ve been in at previous companies was there was a particular set of ground rules, it was something like, dialogue rather than debate, understanding rather than advocacy - something along those lines. I don’t remember the exact details of it. How do you ensure that that remains the spirit of the retrospective, if you see advocacy starting to happen? How do you stop that in a way that it doesn’t shut down communication?

If the ground rules are something that everybody has agreed on working with, what can you do as a start is to discreetly point maybe to the poster where you have the ground rules? And when you do that, either you say something to the person or persons in question or maybe even some of the other people in the room will say something and address that subject. If it doesn’t help being discreet, you could call a break and say, "Let’s have a 5-minute break." You can always do that in the retrospectives and sometimes it’s even a good idea if you see that people’s energy is going down and then you can go directly to the person in question and talk to this person, because often when people are behaving incorrectly or hostile at a retrospective it’s not because they want to be evil people, it’s because they’re reacting to something in themselves.

And they might not even be aware how the way they behave influences the others, so one-to-one conversation about this can be really helpful.

Or you can also change the activity, saying, "I think we’ve got enough out of this activity," changing the scene, dividing people into groups. There are different things, tips and tricks you can use to help on that.


11. Another one that I’ve heard about is the retrospective prime directive. I don’t know exactly what it is. Can you remember?

I actually found it in the book. I could read it aloud because it’s difficult to remember, the wording, precisely. But it’s Norm Kerth's Prime Directive, "Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could given what was known at the time, his or her skills and abilities, the resources available and the situation at hand.

And that’s an interesting prime directive, I think. And it has spurred a lot of discussion on the internet and also in the groups I work with because how can you claim that you truly believe that everyone is always doing the best they can? Because sometimes you know that people are skulking or doing something wrong and they could have done better.

What you have to think about about when thinking about this prime directive is it’s a state of mind you need to have when you enter a retrospective, it’s the way that you should look at the people in the room when you’re entering a retrospective because if you don‘t do that, if you don’t truly believe that; if you don’t really try to open yourself to the fact that everyone actually always do the best they can with the resources available, then you’ll start something like naming or blaming and pointing at people and saying, "You didn’t go a good job and she didn’t do a good job; or even worse, talking about people outside the room, naming people outside the room, saying it was his fault or her fault. It’s almost never just one person's fault. You can almost always find a root cause somewhere, maybe they have the wrong job based on their education, maybe they don’t have enough time, maybe they’re under pressure family-wise- there are all sorts of things that can explain what you would easily call bad behavior.


12. You’ve mentioned earlier five stages of a retrospective, what are those stages?

The five stages of a retrospective is: set the stage, as I mentioned earlier; then you gather the data, it’s important that you have some data to look at (I’ll come back to that later); the third stage is to generate insights, everybody looks at the data in the same way, at the same time, you try to have some parallel thinking; after you’ve generated the insights, you decide what to do and this is the time where you actually make a goal, make an experience, plan something that will change the way that you work and then you will end the retrospective. It’s also important to end the retrospective to get a summary of what has happened and to do a retrospective over the retrospective so that the facilitator can improve.

But let‘s go back to the stages again. I’ve mentioned how setting the stage is very important to get people to participate in a retrospective. The next stage about gathering data is also something that you need to have.

A lot of retrospectives in the Agile world right now are just when people are standing and say: what worked well; what didn’t work well; what should we do differently.

And what happens then is that you’re just looking at some incidents that have happened and then you work with these incidents. You go directly to problem solution at a time. So, the important thing about gathering data is to just look at the data, if you know the thinking hats and there’s a thinking hat for looking at data, the white thinking hat.

And when you say that you’re in the white thinking hat mode, everybody is just looking at the data. And then when somebody tries to talk about solutions or changes, you say, "No, now we’re just looking at the data."

It’s very important that everyone shares the same data before you start working on the solutions because the data in one’s person head about incidents and what happened can be quite different than what other people have seen. You always see it from your own perspective and thus it's very important to get that data.

Once you have the data, it’s also important to generate real insights. So as I said before, if you prematurely rush from the symptoms that you see that you might call problems, and you start solving these problems, you’ll get into some solutions or changes, that is solving the symptoms and you have the same problems still lying there and they will emerge as other symptoms later on, like a disease.

So, it’s very important to generate the insights and that’s what you do, for instance, with the 5 whys, where you go deeply into the root cause of the problems and you do that together.

You might have some parallel discussions but you always wind up doing it together looking at the insights that you’ve gotten. After you’re generated the insights, then you can start deciding what to do but only after you have a common insight on the problems at hand. Then you can decide what to do and you can write, for instance, a smart goal.

A smart goal is a description of a plan that everybody has committed to doing, everybody has committed to saying "This is the way we want to change things." And the smart goal is called smart goal because it has to be specific, you cannot just say, "Well, we want to do more pair programming," that’s not a very smart goal.

So, for instance, if you want more pair programming, you should be specific, you should say, "We want everybody in the team to pair program." And it should be measurable, that’s the aim. So, it should be possible to measure whether you actually do this and you cannot measure, "We want to make more pair programming", you have to say "We want to do pair programming two hours every day, all of us", it has to be measurable, it has to be attainable. It has to be something that this group can do something about. You cannot have a smart goal that says that the manager should change things or we should hire more people if this is not something that you can actually attain. It has to be something you can do or at least influence. Then it should be relevant. But it should be relevant because after you looked at the data, you generated insights together, this should be a relevant goal; this should be a relevant action.

And then it should be timely. It should be the right time for it and you should have the time to do it, so you cannot make a smart goal that you know you’ll never do because there’s no time for it.

And then you have a responsible person written on that smart goal sheet of paper and then that person is responsible for it being done and it being measured maybe at the next retrospective we'll look at all these smart goals and see what happened.

And in a retrospective you’ll decide to have maybe one or two smart goals. People tend to look at all these problems that pop up and decide that they want to change ten things in the next two weeks. And of course, it feels bad to abandon all the other problems but you have to focus on what you want to change. You can’t change everything.And if these problems are bad enough, they will emerge at the next retrospective.


13. How important is management buy off in supporting goals of retrospective? If, for instance, something has been identified as, "This is an issue, we need to pair program more but that seems, from the accounting perspective, that’s going to cause development to take much longer?" And management says, "No, we can’t do this." Is that something which then feeds into the next retrospective or how it that approached?

I think that if a team of developers decide to do something like pair programming and then in the meantime when they go to the manager and the manager says that there is no time to do this, the manager has a problem which cannot be solved in a retrospective by the developers.

So, what you would do in that, you would have a conversation with the manager about whether he thinks he that he actually wants to empower his employees to improving their own work because if they truly believe that it will improve their work to have more pair programming, then he should be listening.

And so for these retrospectives with the smart goals, if you run into something that you’re not able to change, it’s a very frustrating experience for the team and sometimes you can say, "Well, there are some teams that have issues that pop-up. With every retrospective, it’s the same issue. It’s not something they can do anything about.

And then you have to talk about, well, there are things that the team can change themselves, these are the things that we can put into the smart goals. Then there are other things than the team can influence, not something they can do anything about but they might be able to send an email, make a phone call, write a description of something, maybe getting somebody in and consultants from outside. And then there’s the soup that’s the thing that they can’t do anything about - that’s just how it is.

So one of the things in the retrospective, if I meet a group of people that have these issues that are in the soup and they keep re-occurring, I tell them about these three different levels of things that you can do something about.

And then they have to accept that some things are in the soup. So, it’s also about accepting how things are. And when you’re more clear on what you can change and what you’re not able to change, you will be more able to accept, "Well, I have to live with this. Maybe I can live around it in some way. And if I can’t live with it, more drastic solutions need to take place.


14. In retrospectives that I've been in in the past, it sometimes seemed like we address something in a retrospective and we bring it up and then it gets addressed and a couple of iterations later, it comes back, so it’s not necessary that long memory and you feel like you’re in a cycle where the same thing keeps coming back after a long periods of time. How do you get around that? How do you address that?

There are various ways of doing that. I think most importantly if you see an issue that is re-occurring, maybe you haven’t found the root cause for it; maybe it’s one of the symptoms that we talked about before. And if you’re only handling the symptoms and not getting rid of the real problem, then there will be symptoms re-occurring all the time. And then that being said, it might also be that the issue that is re-occurring is something that you cannot really do anything about right now; it could be a communication problem between two people in a team that keeps re-occurring.

And then you have to accept that this is not something that the team can do anything about with the skills that they have at hand and the resources they have at hand. And then if you have something that’s recurring like that, maybe you should move it up to a higher level; maybe to the manager, saying, "Can we get some help? Can we get some team-building? Can we get some psychological help? Can we maybe fire a person?" But that’s not something you can change in the retrospective. In the retrospective, you can make people aware of what has happened. You can make them reflect and you can make them learn but there’s a limit to what you can change.


15. We’ve talked about many aspects of retrospectives and also varying team sizes and varying organizations. It seems there are many, many ways to have retrospectives. Which pieces of retrospectives do you think are core and have to be there in order for it to really be a retrospective? And which things can change based on external variables like team size?

I think ideally I should say that you need all five stages in every retrospective; otherwise it’s not a retrospective. But that being said, as I mentioned before, the retrospectives I have done more than once with 80 people, I still would call it a retrospective even though we didn’t generate a common insight even though we didn’t together decide what to do. There wasn’t really a buy-in from everyone about what things we decided to change with that organization.

But I still believe that it is a retrospective because it gives people the opportunity to reflect about the incidents that happened and to reflect about what do I actually feel about this incident? Was it something that made me happy? Gave me energy? Or was it something that took away my energy or made me sad?

And that time for reflection is something that you often do not take and there can be various reasons for that: "I don’t have the time to do it." You are not trained to reflect on what you’re doing; or there’s a rush for you to not look at the failures that you have - if something has failed for you, you don’t want to look at it, you just want to rush on to something else.

So I’d say that any kind of meeting where people take the time to reflect about what happened, I would say that that is a retrospective for the group.


16. One of the things that I’ve noticed, (I’ve come in on many projects as an external consultant, etc.) and sometimes it seems that a team can have a fairly large and obvious problem but they don’t see it and when somebody comes in and is external, they see it immediately. Are there certain types of problem like that where you just have to absolutely have an external person or is there a way to have that reflection where you step back and kind of look at yourself and look at the situation around you? Is it possible to find those kinds of situations within just the team? At what point do you need external help?

I do believe that with the right amount of reflection, all teams can find and identify their own problems and identify changes. Sometimes you can kick-start this process by having some new eyes on it but you have to remember that the new eyes, it’s not just more experience or other experience, it’s also eyes that are taking a step back and looking at it from outside and that’s what you want people to do at the retrospective, you want to gather the data and then you want everyone to take a step back, look at the data, what are the patterns that you see, what are the stories that you see from this data; what can we make out of it; what is this telling us?

So I think that way of making people reflect and take a step back is as good as getting some outsider in there and it can even be much better because they will know already, well, it’s not because of that, they can already eliminate some of the root causes because they know the team and they know the story of the team.


17. Is it possible that in that situation when you look at something and because you’re familiar with the area, you will eliminate something as a root cause. What if that assumption is wrong? What if that actually is a root cause but you've just been around it for so long that you just naturally assumed that it is not?

You’re right, that can be a problem. Assumption is a big problem in retrospectives as it is everywhere. You have to try and rid yourself of the assumptions. So, of course, leaving out the root causes can be difficult. But, for instance, if the newcomer would say, "Well, the reason for this is that you have not been working together as a team long enough or you have not been trained in doing pair programming or TDD or whatever- that's sort of a very objective root cause that you can say, "Well, that’s not part of the problem." But of course, you have to be really aware that your assumptions are not making you blind towards things. And the only assumption really you can make is that people did the best they could.


20. I’m not sure, in either case, like if you have a team that is more conservative, how would you approach it?

If I had a team that was more conservative and I was a developer in that team and I thought that a retrospectives would be a good idea, what I would do is that: I would look at the problems in the team that make me think that a retrospectives would be a good idea and then I’ll take it up with the other developers saying, "So, have you also noticed we have these problems and would you like that we will find a solution to this? And there are various ways we can do this. I suggest we make an experiment." It is always a good idea to suggest something as an experiment because experiments are fun.

And the good thing about experiments is that even though we do not get the result that we wanted, it can still be a successful experiment. So, experiments can basically never fail. So, the results can differ but they’re always a success because you actually performed an experiment. So, if you say, "I want to make an experiment with this team," then you can introduce the retrospective like that.

Problems with introducing retrospectives can be that maybe some of the developers have tried retrospectives before and it might not have been a very good facilitated retrospective. So, some of them might think that it had been a painful retrospective because there had been naming and blaming in that retrospective, they'd been made a scapegoat. It could also be that they’ve entered a retrospective where they thought it was a waste of time because there was not really an insight generated or the solutions that you found were not followed through like with the smart goals that was regulated, measurable and with responsible person.

For these, you have various activities that you can perform in a retrospective to make people relax about that. But, of course, first you have to get them to enter into the room where you facilitate the retrospective and that’s where you talk about an experiment and once they’re there, you could describe what a retrospective is and what you intent to get out of it is a chance to reflect and to learn.

And one of the things that’s useful for me when people say, "This is going to be a waste of time," is to make everybody in the setting the stage part of the retrospective to write down on a piece of paper what would they have spent their time on these two hours if they hadn’t been in that room right now.

So, let them all write that down, pick it up, put it in a little stack of paper at the table, you don’t have to look at it right now. And then, after the retrospective when you’ve gone through the data, you’ve generated the insight and decided what to do, look at the things that you’ve decided to do and try to articulate how much time do you think you would have wasted if you did not change this in the next sprint or the next project?

How much time do you think you would have wasted if you hadn’t generated this insight, if you hadn’t made these decisions? And then you can ask people to compare it to what they wrote on those notes in the beginning of the retrospective to make them think about that this might be a waste of time in the short-run because you could have been coding for these two hours but in the long-run, you might have actually not wasted as much time as you would otherwise in the next sprint.


21. Work out frustrations or?

Oh yes, that too. It’s not just time that you lose sometimes in projects, it can be very stressful, it could be very painful also for your family and your friends. So, there are lots of things that can be wasted, not just time.


22. What do you think is a good length for a retrospectives is and is there some kind of a homework you can do to try and make the process maybe shorter than is because retrospectives can sometimes expand, it seems, when there are a lot of things that come up and a lot of discussion start, can you do that?

Yes, you can do some homework before a retrospective. So, a rule of thumb, for your first question: How long should a retrospective be? A rule of thumb is that for every week that you work in the project, you should set up half-an hour for the retrospective. So, if you have two hours’ sprints, there should be a one-hour retrospective. And you have really to time-box it. If you let the retrospectives take longer than what you'd planned, people will not like it. You have to think about these retrospectives as something that’s recurring over and over again. So, if every retrospective takes 15 minutes longer than intended, it’s a lot of time spent more than you had planned. So, it’s very important that you make sure the facilitators are able to end the retrospective on time.

So, say we only have one hour for a retrospective, it is not that much time to gather the data and to generate insights and to decide what to do and you also you have the boilerplate in the beginning of the retrospective by setting the stage and then you have to end the retrospective again.

So, one thing you can do when people are used to doing these retrospectives is that you have one activity for gathering data that you always do. For instance, it could be the timeline. The timeline where you put PostIt notes on the walls saying, "This was the first day; this was the second day; this was the third day" and then people can put PostIt notes under these days in the chronological order on the timeline saying, "This was an incident that happened to me on day 1; this was an incident on day 7."

And they can prepare these PostIt notes beforehand because if they know every time that this is the way we’re going to gather data, so instead of starting the gathering data with a 15-minute brainstorming, individual brainstorm about the incidents, they could bring them and then we could cut down the brainstorming to 5 minutes.

Another interesting idea I heard about doing homework for retrospectives is in the presentation that Linda Rising gave at the GoTo Conference in Aarhus this year where she talked about real-time timelines. And what she meant with the real-time timelines was that instead of just drawing the timeline at the retrospective, you should always have the timeline, a real-time timeline in the group room where your team is working or in the room where they can go to easily.

And then if something happens in the morning one day an incident maybe something, problems with the test or problems with the teamwork or a celebration that they really like; maybe it was nice to get out and get beer with the team, any kind of incident, they can already put that PostIt notes on that day.

And then you could say that when the retrospective is there, you already have the timeline. And people don’t have to think about what happened, a week go, what happened two weeks ago which could be difficult but they put it down when it was there and when it meant something to them and they can still remember it.

And actually if there’s an incident popping up during the project development, that everybody can see, this is an issue that we have to do something about. This is an issue that was articulated and would otherwise have not been articulated other than in the retrospective then instead of waiting for the retrospective, you could do something about that right now. So, it’s a way of taking the temperature of your team everyday.


23. It kind of reminds me of the lean or Kanban approach, the idea being in continuous flow or having that constant ability to grab new work as opposed to fixed length federation.

Yes, you could say it’s along the same line. I believe that everybody is becoming aware that it’s much easier to solve problems when they’re there. It’s much easier to articulate things that when you’re in them than later on; and thus, if you make a continuous retrospective, you’re training people to reflect about the things that happen all the time. And that reflection is something that people can become better at. It’s not something that comes naturally to people but it’s something they become better at and I've become a much better reflector after I started facilitating retrospective myself.

So for instance when I’m teaching a course, when I’m 15 minutes in the teaching or half an hour into teaching and something happens, I might start reflecting already at that stage. When it’s taking place, reflecting about: why did this happen? So, instead of just seeing , okay, somebody’s falling asleep or somebody’s getting angry or didn’t do their homework, I’m already reflecting on: why did this happen? What was the cause of this? How can I change this? So, it's become more natural for me to reflect.


24. It also kind of reminds me of the idea with the Toyota production system of pulling the chain-stopping the line. Do you think there’s some similarity there or would you stop what’s currently being done to address that if it’s a large enough issue? And how would you identify an issue that seems large enough to kind of stop the line?

I think it’s difficult to give a general answer to this. I think that when you see a PostIt note saying, "I really hated the meeting today," or, "Why do we have to test the software like this?" or, "Why do we have to work for this manager?" I think it will be pretty obvious for you as a team to see when you should react to these things because it could be one person always complaining about the same but not really wanting to change it or not really want to put in the energy into changing it.

And then something that seems like a major incident for one team can seem like a smaller incident for another. It grows to be something where people have seen the warning signals of a stressed person for a while and then there’s just a bit more red PostIt notes from that person being frustrated and even though might seem as a small thing for one team, a team which has sort of got its eyes open towards this problem and see this as an incident and react.

So, I think it’s very difficult to get a general answer to this. It will depend on what kind of team you have and what kind of people you have.


25. Another style of retrospective I’ve heard of is ‘start-stop-continue’, you know: what should we start; what should we stop; what should we continue. What are your thoughts on that? Is that a retrospective or what is it?

The problem with the start-stop-continue retrospectives is that they only treat symptoms. They don’t really look at the causes behind the symptoms. They never get down to the problems. So, if you have start-stop-continue and that’s the sole activity that you do, it can be a good activity for later, for deciding what to do. But if that’s the sole activity you’re doing, you’re not really making people reflect, you’re making people think back and jumping to solutions, to these problems.

So, if you have to think about what to start doing, it is jumping to a solution. And also, when I see people having these start-stop-continue, what I often see is that it’s the same thing that we have on the start-poster, but it’s just with a different wording. So, in a sense I often feel that it’s not useful with three posters, but can be just my taste.


27. And oftentimes, the lists get so long that people stop reading it because it got, say, 70 or 80 or 100 items on it and you get into the retrospective and you want to start by reading the list and after about your retrospective, you say, "Yeah, yeah, we know what's on the continue list."

So a way to avoid that, that’s also something called the Groundhog Day as I see it in retrospective. It’s the same issues recurring over and over again and it’s good to air the issues from time to time but then it’s also important to have a focus on a retrospective. Sometimes the focus can be on the team, the team communication; sometimes the focus can be on how they deliver software, how they get it into production. Sometimes the focus can be on how do they maintain the software; it can be how do they discuss the design of the software. It’s good to have a focus on a retrospective because then you won’t enter into to that problem where you have a hundred item continue list.

I think an important factor about retrospectives that we haven’t touched upon yet it is that they are a chance to give appreciations. Developers, at least, developers in Denmark, are not that prone to give each other compliments on what’s going well. They are not that prone to thanking each other, saying, "I really appreciate you did that," or, "You’re doing a good job and the thing you did there really changed the work I did today, or, "I really appreciate how you always do this in the right manner or that you manage the meeting so well," or something like that.

So, the appreciation is also a very important factor in the retrospectives where you have the chance to look at what has actually gone well this time.

But people seem to focus more on the problems because they’re really into solving problems. As developers, we are really keen on solving problems but it’s also a chance to reflect and look back on what worked well and what do people do make things easier for each other.

Feb 15, 2012