Agile Retrospectives Making Good Teams Even Better

Transcript

Shane Hastie: Good day folks, this is Shane Hastie for the InfoQ Engineering Culture podcast. I'm sitting down with Esther Derby, Diana Larsen and David Horowitz to talk about the new release of Agile Retrospectives, Making Good Teams Great. Esther and Diana were the authors of the original book, and David's been roped in to help with the new release. Folks, thank you so much for joining us today.

Diana Larsen: Happy to be here.

Esther Derby: Thanks for having us.

David Horowitz: Thanks for having us.

Shane Hastie: Obviously, we know each other and most of our readers will have heard of you, but I'd like to just do a quick introduction round. So, Esther, tell us, who's Esther?

Introductions [00:55]

Esther Derby: Well, I started my career as a programmer, which not everybody realizes about me. I was an assembler programmer, so down with the bits and I have done a lot of different things and been in a lot of different roles over my career. I was a team lead and a dev manager and an internal consultant and one of the things that struck me from all of those roles was the importance of learning and the ability that we have to improve our environment, to improve our working environment, no matter where we sit in the organization. And so, I started doing retrospectives a long time ago and that morphed into Agile Retrospectives. And somewhere along the line, I met Diana and somewhere along the line, I met David and here we all are.

Shane Hastie: Diana?

Diana Larsen: I started my college career in computer science department, but I didn't end up ever working there, but a similar path to Esther's doing a lot of different kinds of things in organizations and spending some time consulting. And mostly, my consulting was around work process redesign and things like that. And so, the idea of people learning about their work processes and improving them has always also been a part of my outlook on work. And these days, I'm co-founder of the Agile Fluency Project and still thinking about how teams learn. And that's been also a focus, is how do people learn in groups, not just learning on your own, but how do organizations learn, how do teams learn? How do people learn in groups? And like Esther, I've been kind of hooked in with retrospectives since Norm first published his book and have been part of that community as well.

Shane Hastie: David, you're the new kid on the block here.

David Horowitz: I accept that as a compliment, thank you, Shane. So, I've been doing software development in various capacities for quite some time now and started writing code when I was a kid and then transitioned to making that into a career eventually. Was suffering from the problem of working with distributed teams much longer before that became the norm as it is now, and could not for the life of me, figure out how to help them learn and how to help them grow via the retrospective. It's a hard enough meeting as it stands, when you introduce distributed teams to the mix, it becomes that much harder. So, ended up jumping off a cliff, as they say, and starting my own company called Retrium along with my co-founder Ryan and it was through that crazy endeavor that I ended up meeting Diana and Esther and here we are today.

Shane Hastie: The original book, Agile Retrospectives, Making Good Teams Great, it's one of those absolutely foundational pieces of content that every agile team has. Almost every scrum master that I know of has a copy somewhere. The more dog-eared the better.

Esther Derby: With many post-it notes stuck in it.

Shane Hastie: We certainly hope so and mine looks like that. What needed to change?

What’s changed since the Agile Retrospectives book was published? [04:00]

Esther Derby: Well, the world has changed since we wrote that book. For one thing, when we wrote that book, there was huge emphasis on co-located teams. And most of the teams I worked with were co-located and that's not the case anymore, so that's one reason we wanted to do a refresh, was because that's the reality for so many teams now, so we really wanted to address how do you support learning and have good retrospectives and create a collaborative online space.

And the other thing is, we've just learned a lot. We've learned a lot since we wrote that book 15 years ago, so we wanted to incorporate not just the distributed retrospectives, but also the things we have learned about making them more effective. And a few other things.

Shane Hastie: Let's explore some of the, "We've learned a lot." It's 15 years, agile as a way of working is at least 20 years old now, 20 years since the manifesto was signed anyway. There's a good argument that it's been around for a long time before that, but that was a point in time and then 15 years since the book, what are the big changes?

Diana Larsen: One of the things that's surprised me is the persistence of the idea that a retrospective is just two questions. And so, learning more about why is that and why do people think that's going to get them improvement and so on. I know Esther has probably had the same experience as I have, having many, many conversations over the years with people who are frustrated because they don't get to real improvement actions or their teams don't know how to put together experiments, that they have a hard time getting time set aside for learning from their organizations that don't see it as a regular part of the work.

And so, of course we've learned from people who have been able to overcome those things and we've learned from people who are still suffering from them. And so, gathering together all of that information, it feels like we've got some things that we want to share back with the community that's been so generous in sharing their experiences with us.

David Horowitz: One of the things, Diana and Ester, that you've mentioned already is this concept of learning and this concept of experimentation, which is quite different from what I hear from a lot of teams as the point of a retrospective, which tends to be action and improvement from that action, which of course is lovely if you can achieve that. But the lack of an action doesn't necessarily indicate the failure of a retrospective as long as you've learned. And so, focusing in on that as a success criteria, at least for me, is something that is important to share with the community.

Esther Derby: Yeah, and I think that's one of the things that we want to shift when we do the second edition is just to emphasize that, yes, it's good to have an action, but if the action is just there for the sake of saying, "Oh, we have an action, tick the box," then that's not useful. That really, it is about learning, it is about understanding something about how your system is working so you can make it better. And that yes, sometimes just sitting with an insight is what you need to do.

Diana Larsen: Yeah, if you go back to the old, at the time, it was called the Association for Quality or something like that. American Society for Quality, they had a definition of continuous improvement that had embedded in it continuous learning. You could not get to continuous improvement without continuous learning and I think that has gotten lost along the way.

Diana Larsen: And I've been doing this work long enough that I still remember those old American Society for Quality days, whatever ASQ stood for, but, I think, trying to bring that back in a fresh way to get people's attention, now that agile is so much more associated with lean and with the quality movement and some of those other things, I think it's time to knit together those connections again.

The emphasis in many organisations is on being busy rather than learning and being effective [07:58]

Esther Derby: And I think we're still fighting an uphill fight, because there is so much emphasis on organizations on getting work done, on being busy, on not wasting time, that people often talk about how important learning is, but they don't seem to follow through on or know how to follow through on how do we create an environment where learning is actually possible and where it's encouraged?

So, I think there's still a big old hangover from mechanistic thinking and sort of separation of head and hands that we're contending with when it comes to helping people in organizations learn, particularly at the team level.

David Horowitz: Which perhaps gets at one of the root causes, why there tends to be some amount of disillusionment around retrospectives when you talk to people in the agile space, that people seem to understand the theory, but when they try to put it into practice, there's a disconnect between what they're trying to achieve and what actually happens as an outcome of the retrospective. When an organization understands the theory of learning, but doesn't really know how to put that into practice and really emphasize it as opposed to just being busy, as Esther said, then of course, when you run a retrospective, you will fail, because you end up not emphasizing the learning component and considering it being an exercise that's a waste of time because you're not producing code, you're not producing product. So, trying to connect the dots between really learning and the retrospective as the catalyst of that learning is important.

Shane Hastie: What does a great retrospective look like and feel like?

Esther Derby: All sorts of different things. I don't think there is one way they look or one way they feel.

There are many types of retrospectives which can focus on different aspects of improving work [09:36]

Diana Larsen: That was my immediate take too, Esther. I mean, it depends, it depends on what part of the work you're focusing on in the retrospective, is this the time we're going to dig down into our relationship with our product owner, or is this the time we're really going to look at how the system is behaving and what surprises us about that? Is this the time that we're going to look at why we keep saying we want to take an action or achieve some kind of improvement, but then we don't follow through on that, can also be a purpose for a retrospective. So, depending on what that focus is, the retrospective may look different. And that actually is another thing that's changed, I think, in the 15 years, is a lot more people have been working on making retrospectives effective, and there's been a lot of work in that.

And so now, there is the sort of cascade of group process activities kind of retrospective, but you can also get through that learning, thinking, deciding, moving into action or just what kind of outcome you want, you can get through that cascade through exploring a metaphor or a number of other ways. And now there are online components to that, we don't just have to be drowning in sticky notes and whiteboards and flip chart paper. So, there's just a much broader sense of what a retrospective might look like or feel like.

Esther Derby: And one aspect of that for me is the effective use of data. It's not always just brainstorming what happened. It's not always subjective data or perception data. You can actually use hard data in a retrospective and I was surprised when someone said to me, "No, no, no, you do not have data in retrospectives, it is just for discussing the team's feelings." And it was the one time in my life I was able to say, "Well, I beg to differ. I wrote the book and you can use data."

Diana Larsen: Which is funny when you think about it, Esther, because when we wrote the book, everyone was telling us, "Oh, you'll never get teams to deal with feelings." So, we had to dance around the idea, take out an event or a factual thing that happened and that the team might have some response to that. We came up with-

Esther Derby: Energy.

Diana Larsen: Yeah, 16 different ways to talk about the fact that engineers might have feelings. And the fact that that's completely gotten turned on its head is-

Esther Derby: It's amusing.

Diana Larsen: It's amusing and ludicrous all at the same time.

Esther Derby: And yet I still often find when I'm talking to people about doing retrospectives or teaching people to do retrospectives, that when we talk about data and they're saying we have real problems with our defects, and I say, "Well, why don't you look at some data?" And they say, "Well, what data would we look at?" For some reason there's often a disconnect about how you use data in problem solving or problem understanding, so I personally have a lot of energy around that one.

Shane Hastie: That leads me to a question, perhaps, what are some of the data points that we would bring to a retrospective to explore?

The types of objective and subjective data that can be useful in a retrospective [12:52]

Esther Derby: Data follows focus, so it really depends on what you're focused on in your retrospective and that will tell you what kind of data will be useful. If you are looking at your defects or you're looking at something about patterns of customer complaints, many organizations have hard data on that, so then you pull in that data. But you may be looking at how many interruptions you have, why do we have so much trouble getting things done? Maybe you just do a back of the matchbook data collection of how many interruptions people have.

So, all of those are objective data, things that can be counted, but sometimes perception data is important, like how are we doing on our technical practices? That's, to some extent, an opinion, but a discussion of one person thinking, "Oh, we're doing fabulously well." And one person thinking, "Oh, we're kind of crap on that." The discussion about the gap can be quite illuminating, but that's subjective data, right? That's people's perceptions about how they're doing with their technical practices, but you have to look at what are we trying to learn about in this retrospective and what data, whether it's objective or subjective, would help us gain some insight into that situation?

David Horowitz: And I've found, Esther, to build on what you're saying, that sometimes the subjective piece can lead to the realization that you need to collect the objective piece in greater detail. So, for example, you were bringing up interruptions, someone might mention in a retrospective, and this is a contrived example, but just to demonstrate the point, "I feel that we are being interrupted too often to be focused on what we're doing and therefore we're not delivering on our iteration, on our promises." And so, there might be some debate. Someone else might say, "Actually, I don't feel that way and here's why." But until you have data to show which perspective is, in quotes, the truth, and of course, that's also sometimes up to opinion and subjectivity, but it might lead the group to discover that, "Hey, maybe we should just make a little tick mark on a poster board somewhere every time we're interrupted” and then use that hard data to count the next time you have a retrospective to do a deeper analysis, so subjective data leads to objective data sometimes.

Esther Derby: And that would be an action that comes out of a retrospective. We know there's something going on with interruptions, our action out of our retrospective is to gather some data so that we can make some informed choice about what's going on, so that's an action, but maybe not in the way people usually think about the action that comes out of a retrospective. An action can be, we need to gather some more information about this, we need to investigate this, we need to learn something. Those are all valid actions.

Diana Larsen: And actually depending on what you're trying to learn about or what you want to improve, that may be the first step in the journey toward that learning and that improvement is to go, like you said, do some research, gather some data about it.

Shane Hastie: How do we at the team level, I want to say justify, convince, influence leadership to give us the space to go and gather that data.

Diana Larsen: That question always sort of baffles me. I don't know exactly how people get into a situation where they're pleading with their boss to allow them to do the work they need to do to be effective, so that's one reaction. But the other one is making the case. We need to understand this in order to get over this hurdle that's holding us back from accomplishing the goals that you have put in front of us. This is a hurdle we can't get over without understanding this piece better. I often think people are afraid that they won't get permission to do something like this and so they hold themselves back. I'm afraid they won't give us permission, so we're not going to ask for permission and we're just not going to do it. And how does that help, right? So, there's all kinds of complex interactions.

Esther Derby: Well, I think it was Grace Hopper who famously said, "I would rather beg for forgiveness than ask for permission." And frankly, a lot of these things don't take much time. If you can't get permission to make a tick on a piece of paper each time you get interrupted, then your retrospective is not your biggest problem. It's this incredible freaking micromanagement that says, "If you are not typing code, you are not working," so then you have a different problem. But a lot of it you can do without a huge expenditure of time. And on the other hand, I think setting aside time for learning sends the right message. When management just says, "Okay, half a day, half a day a week minimum for learning." I occasionally hear people say, "Well, have an hour a week for learning." And it's like, an hour out of 40? That tells you how much you really value learning, which is not much at all, but half a day, which is going to pay off in a matter of weeks or months at the most, that seems like a smart investment.

David Horowitz: At Retrium we were fortunate enough to have the opportunity to talk with thousands of companies, tens of thousands of teams regularly and on occasion we get that question, but it's much more frequent that we get the question that we have the time to run retrospectives, how do I engage the team? How do I convince the team that they want to be there as opposed to convincing management? So, that is something that comes up very regularly for us, or for me at least, and has quite a different number of ways you can take an answer to that question, depending on the root cause of the lack of engagement. So, the management piece seems to be much less frequent in my experience than the team piece.

Shane Hastie: So perhaps we could explore that question. How do we motivate people to recognize the value in this time?

No one in their right mind is opposed to learning and improving the way that they work. [18:55]

Esther Derby: I don't have data on this, I just have anecdotes that so many teams have been exposed to retrospectives that are indeed a waste of their time, that they assume that it can only ever be a waste of their time, right? So, if people have had that experience, I don't blame them for not being engaged at all. And then I may not try to convince them to have a retrospective, I may just say, "Hey, we had this issue come up this sprint, let's get together and see if we can figure out what contributed to it and what we can do to make it better." And I don't call it a retrospective. I may go through setting the stage and gathering data and generating some insights and some alternatives and then make a decision about what we want to try or learn or change or do, but maybe I don't call it a retrospective. I just, "We're going to have a working session to try to figure this out." And then if it's useful to them, if they get some insights, then I've started shifting that dynamic.

David Horowitz: I could not agree more with what Esther just said. No one in their right mind is opposed to learning and improving the way that they work. That's something that is universal. Everybody wants to get better. What people don't make the connection between is the retrospective as the vehicle of that learning and that improvement. And you can always do the thought experiment with people who are a bit sceptical and say, "Look, imagine for a moment that I had this genie in a bottle and when you took that genie out of that bottle, that can make any wish come true that would improve the way your day-to-day at work goes about happening." No one would turn that opportunity away. Everybody would say, "Yes, of course. Genie, fix this, fix that." So, the problem isn't the retrospective outcome, it's the way that the retrospective has been done in the past, as Esther was saying. And so, trying to find a way to fix that is why we're doing the second edition here also and encourage better habits is very important.

Examples of a bad retrospective [20:52]

Diana Larsen: Right, and somehow people fell into a trap in their retrospectives. I don't know. I can't speculate about where this all happened, but I have had the experience of watching in a split second a team go from disengagement in a retrospective to vitally engaged in the retrospective. And I've seen it multiple times. And in general, in broad brush, what is happening is they walk in, they're dispirited, they get in a chair in a conference room or you all show up on a screen on a Zoom call or something. And everybody's just like, "Oh gosh, what's going to happen?" I mean, you can see it in their demeanour.

And then one person takes charge, sometimes it's the product owner, sometimes it's the product owner slash scrum master, or sometimes it's somebody else. And they say, "Okay, let's open up our confluence page and they do all the typing and they ask people, "What went okay this time? What do we think we ought to do differently? Great, got that list. Those two lists. Okay, anything anybody wants to appreciate from somebody else?" That's a bell or a whistle that gets added on sometimes and then they're done. Then they say, "Okay, well now we've done the retrospective, we have our lists.

Esther Derby: You forgot the dot-vote on something we're not going to do.

Shifting to engagement [22:14]

Diana Larsen: Well, very often they aren't even doing that. And what happens is I get invited in to sort of watch these boundary meetings as they call it, and give them feedback. And when I say, "What were you going to do with those lists? Were you going to turn any of those into an opportunity for improvement?" All of a sudden, the team members are sitting forward. "Yeah, when do we get to work on these things? When do we get to improve what we're doing?" I mean, it's instantaneous and I don't have to say another word. It's amazing, really.

Esther Derby: The other thing is, I think a focus can help with that. Rather than just making the same two lists every time it's like, "We're going to focus on something” and choose something the team cares about or something they've been struggling with. So, choose something they care about and then they're far more likely to be engaged rather than just, let's make two lists. And the lists very often, what went well is an opinion, right? Subjective data. But unless you mine it, you don't know anything else about it. And what did we do well is also an opinion, but it's a conclusion, so it's like they're starting in the middle. They start in the middle and don't go anywhere else, so who would be engaged in that?

I mean, I've been in retrospectives, not ones I've led, but I've been in retrospectives that consists of two lists. What did we do well, what would we do differently? And very often the same things are on both lists, but there's no conversation about that. That in and of itself could be an interesting thing to explore. And I want to say it is possible to have a good retrospective that starts from two lists, but it takes really, really strong facilitation skills and the ability to ask probing questions and tease out details and get people to look beneath the surface. Notice patterns, notice common threads, so I'm not saying you can never have an effective retrospective that way, it's just your chances aren't very good and I prefer to make the chances better.

Shane Hastie: So, what do we do to increase those chances?

Esther Derby: David, did you have something you wanted to add?

The difference between an engaging retrospective and one that lacks engagement can be the time needed to shift from deep technical work to contemplative thought work [24:19]

David Horowitz: Well, it actually might be related to, Shane, what you were asking there, that sometimes the difference between an engaging retrospective and one that lacks engagement can be fairly subtle in the sense that a scrum master who cares about all of this might spend a lot of time researching, "Okay, how am I going to facilitate the next retrospective?" And kudos to them for doing that, right? Which activities will I pick? And why am I picking those activities for this particular team in this particular context? And they go in with a lot of gusto and into the next retrospective excited about the experience. But then picture yourself in the shoes of engineers who have been heads down all week long and trying to solve some complex technical problem and they're really still focused on trying to get that out the door by the end of the day, so they don't have to think about it at nine o'clock when they're actually getting ready for bed.

And you're asking them to go, instantaneously almost, from deep technical work to a much higher level order of thinking without giving them an opportunity to breathe, take a moment to collect themselves and shift their mindset. And so, the same exact retrospective facilitation experience can be engaging or not engaging depending on if you have that separation of time between the deep work and the thought work that happens in the retrospective. And that can be as simple and this is the setting the stage of portion of the retrospective in the book, it can be as simple as let's just go around the room, take a deep breath together, pause, go around the room and ask, "How are you feeling right now?" And let people just share. It's very simple and it might sound silly if you've never done it before, but for those who have, you'll find it, I think, to be a fairly effective way of producing and providing that space.

Retrospectives are real work [25:57]

Esther Derby: There needs to be that little separation and that shift from one mode of thought to another. So, I think, another reason that people get disengaged is for a while, everybody was coming up with games for retrospectives. You can order a pack of games and it has a little script that you read from and you do your little games, or you have these cheesy little things you do for icebreakers and all this stuff. And I think many people find those unserious and resent being forced to do these gamey little things. Games can be great when they serve a purpose to support participation and to support learning, but games for the sake of games, I think are a big turnoff for a lot of people.

Diana Larsen: I think that's an important point. Retrospectives are real work, they're not extra team building things you're doing off to the side. This is part of the real work and every part of the retrospective, the setting the stage, the gathering data and everything, even the closing has to be focused on the work and whatever learning and improvement we need to do around the work that we do together. Now, there's a lot of different aspects of that and we might be looking at our teamwork or our work process or what the quality of the product is, or interruptions or relationships outside the team. But that's also part of the work and I think when we start thinking about retrospectives as something that's separate from the work, is where we get ourselves in trouble. It's just the same as the sprint review or the product demo or the planning, retrospective is a part of the work.

Esther Derby: And that doesn't mean you can't have fun doing it.

Diana Larsen: Right.

Esther Derby: But don't make it gamey for the sake of being whatever game has popped up on the internet recently.

Retrospectives are for the benefit of the team, not the facilitator and need to be focused around what the team finds most useful [27:49]

David Horowitz: Well, and also make it as gamey as the team wants it to be. It's not for the facilitator, it's for the team. And there's a bit of a cottage industry in my mind around, like you said, games for retros that are designed to intrigue the facilitator. These people fall in love with the games, but that is not the purpose. The purpose is to serve the work of the team. So, some teams will have an appetite for that sort of thing, in which case great, but some teams may not and be much more interested in a hard look at real data coming out of Git or Jira or some other platform and be much more engaged with that sort of approach.

Timing and cadence should depend on when you need to learn [28:23]

Diana Larsen: Another aspect of this is the timing of the retrospectives, and that has changed enormously. I mean, when Norm Kerth first wrote his book, the retrospectives were only happening all the way at the end of a project that may have lasted for three years, right? And then when we wrote our book, the idea had come along that, "Oh, you could do a retrospective at the end of every iteration or every sprint or at the end of a release, because that expanded it." Now, there are a number of different points of time. It depends on if you're doing Kanban or scrum or what methodology you are going on, what cadence you're doing.

I happen to know some teams that are doing, whether you want to call it mob or ensemble programming, that are having tiny retros at the end of every Pomodoro. 25 minutes of work, three minute retrospective, take a break, come back and start again, and actually getting huge value out of that. So, that also is a thing that's really changed over the years. When does the retrospective happen? Well, when do you need learning to happen? It could happen anytime you need learning.

Esther Derby: I know teams that have a small retrospective every day and maybe a longer one occasionally, or as you said, at the end of every mobbing session or at the end of every time someone switches, it can be, switches the driver. So that's, I think, when people start really getting huge benefits out of the retrospectives, when they're just incorporated into the rhythm of the work and not as some burden.

David Horowitz: And it doesn't even have to be necessarily on a pre established cadence, so it could be when the team says we need to talk about this topic, then you have a narrowly focused retrospective on that topic. And even if you're using an iteration based approach, like scrum, that doesn't preclude you from running your retrospective when you need to. So, if you see them as the vehicle for learning and improvement that they are, and if that has been your experience, then it becomes appetizing to use them when you need to, as opposed to an event that's just a checklist item at the end of every sprint.

Diana Larsen: Way back when in like 2004, Linda Rising came to a retrospective facilitator gathering with a great new thing, she had invented that she called the surprise retrospective. And she had been working with a team whose company had gotten acquired by another company and their product was on the bubble. And so, she said, "Well, let's have a retrospective." Something changed in their environment. And she said, "That's a great time to have a retrospective." And so she named it the surprise retrospective, something unexpected happened. And so, anytime you need learning, anytime you need that.

Esther Derby: I think there's something related to what David said about the cottage industry in retrospectives games, is people think you have to have games. I personally don't do games. I do activities or exercises that are designed to engage participation and get people out of habitual thinking, but you don't have to have those in a retrospective. I mean, the whole process that underlies a retrospective that says, first, you have some focus, then you get data, then you have insights about the data and your response to the data and then you have some candidate actions and you make a decision, that can be done with questions.

You can just ask questions about, "Okay, we're going to focus on blah, blah, blah, what data do we have about this? Okay, let's look for patterns in the data. What patterns do we see in the data? What does that tell us about what's going on? How might we address that?" So, if you're doing one of these spontaneous retrospectives, or you're doing a retrospective at the end of a Pomodoro, you probably don't have any activities. You probably are just asking a series of questions generally in an order that helps people think together well, which almost always means focus, data, insights, decision.

Shane Hastie: Some really, really inspiring and interesting thoughts here. Really looking forward to the new book. How far away is it? When are we going to see it?

Esther Derby: We are writing.

Diana Larsen: Yeah, that's a tricky question.

Esther Derby: We are writing, Shane, we are writing.

David Horowitz: That's like asking an engineer, "When will it be out?"

Shane Hastie: Is there a roadmap? Is there a target?

Esther Derby: Yeah, there's a roadmap.

Share your stories to contribute to the new edition [32:46]

David Horowitz: We're working on it. We're at the stage where there's going to be a website, agileretrospectivesbook.com. If you're interested in hearing more, as we make progress, you can sign up there, enter your email address, you might even get some teaser content there. And also, we're very much in the market for hearing your stories too. If you have some story of a retrospective that was particularly powerful or led to some insight you were unaware of before... Or a failure story for that matter, of when that really just blew up in your face. These are things that we'd love to hear and potentially talk to you in more detail to add to the book. So all of that will be available on the website, agileretrospectivesbook.com. And we're hard at work to get this next edition out, it's really important and exciting, and we're really motivated to make that happen.

Esther Derby: And we're going to do it in an agile-ish way, so we're approaching end of our first iteration and at that point we will have some data about how quickly we can move. And that will inform the overall release schedule. So, we aren't locked into a schedule, but we're going to get some data about how much progress we can make in one of our little iterations and do it the agile way.

David Horowitz: And we eat our own dog food a bit too. I remember when we were just talking about this, it wasn't a set plan, Diana said something to the effect of if there's ever an issue that comes up, don't sit on it, let's talk about it. In other words, let's run a little mini retrospective on it when it happens so that things don't simmer inside and it's better to get it out and talk. And so, we kind of eat our own dog food there and practice the concept of running retros on demand whenever we find they're necessary.

Shane Hastie: You've given us the website where people can find the book. If people want to continue the conversation, where would they find the three of you?

Esther Derby: Well, I think the place to find the three of us together is at the agileretrospectivesbook.com. And then you can always find us individually. I'm estherderby.com and Esther Derby on Twitter and you can find me on YouTube and I have a podcast on change, so lots of places to find me if you search on Esther Derby.

Diana Larsen: And on Twitter, I'm DianaOfPortland and I do some activity on LinkedIn and I'm pretty easy to find there and you can always find me at agilefluency.org, which is the Agile Fluency Project's website and we have a list of workshops and things that are coming up there. And if there's anything retrospective related, it'd probably show up there.

David Horowitz: And I'm a bit old fashioned with this stuff, I don't have Instagram or any of these newfangled things, even though I might be on the younger side of people, but you can email me at David@retrium.com, R-E-T-R-I-U-M.com or just visit the website to check us out there as well.

Shane Hastie: Diana, Esther, David, thank you very much for taking the time to talk to us today.

Esther Derby: Thank you for having us.

David Horowitz: Thank you.

Diana Larsen: My pleasure.

Mentioned

• Agile Retrospectives (1st Edition)
• Agile Retrospectives Book website
• Esther’s website and twitter
• Diana’s website and twitter
• David’s website and email