Welcome to the Rabbit Hole podcast!
Our panelists today: Aaron Streiter, Emmanuel Genard, and William Jeffries.
In this episode, we’ll talk about retrospectives. To be clear, we’re using the term in reference to retrospective meetings in the Scrum framework, not about art or other retrospectives (though we’ll touch on that in the episode!).
In short, a retrospective is a regular, recurring time to air grievances and make suggestions for how to move forward and make the team better. Its focus is generally on how things went, not about how people behaved, so it doesn’t tend to devolve into a blame game. And it’s important to keep in mind that a good retrospective addresses positive things as well as constructive things.
Generally, the people in the retro should be the people who were involved in the sprint it’s addressing (and who were in the planning meeting for that sprint). In some cases, though, it may be beneficial for an outsider to run the retro.
A good retro should have three distinct phases. First, the ideation phase gives everyone a chance to put everything out there. This is the “yes, and” phase. The second phase is more constructive and involves grouping ideas. This is the “yes, but” phase. Finally, the third phase is where you focus in on key points and is based around action items.
That should give you some sense for what a retrospective is and why it’s important. To learn much, much more, tune in to this episode!
[00:22] - We start off with a teach-and-learn moment about Vim.
[01:38] - Another of the panelists managed to teach someone sync settings on Atom, he explains.
[02:53] - What is a retro? In short, a meeting that is one of the recommended ceremonies in the Scrum framework. Its purpose is to look back on what happened over the course of the last sprint.
[03:55] - Somewhat surprisingly, retros don’t tend to devolve into blame games.
[05:36] - We learn about the etymological root of the word “retrospective,” and what that means in terms of these meetings.
[07:27] - The purpose of the retrospective is to do better during the next sprint. It allows you to make a plan for how to get better.
[08:54] - Who should go to the retrospective? Should anyone who isn’t part of the team show up?
[10:55] - The panelists discuss how long a retro generally takes.
[12:28] - We hear about the good things that can come out of a retro.
[16:09] - After the break, the panelists kick things off by talking about the phases of a retro.
[18:20] - In the brainstorming phase, does everyone write down ideas? If not, how do the ideas come up without allowing certain people to dominate the conversation? In response, the panelists also discuss the pros and cons of anonymity.
[22:11] - We move onto the part of the retro that involves identifying trends
[23:17] - William expands on what he meant about this being the “yes, but” phase. They then discuss the tendency to pile onto the popular topics.
[25:58] - The third section of a retro involves action items.
[28:37] - When do you check on the previous retro’s action items?
[30:29] - One of the positives of the Scrum recommendations on which ceremonies to have is that they cover your bases. The panelists then discuss some reason why people may push back against Scrum.
[32:55] - We hear some tips and tricks for having a successful retro that runs smoothly.
[36:18] - The panelists share their closing thoughts on retros, including that every team should have one.
[36:58] - We hear the picks that the panelists want to discuss for the upcoming week.
Michael Nunez: Hello, and welcome to The Rabbit Hole Podcast. I'm your host, Michael Nunez. The panelists today are ...
Aaron Strider: Aaron Strider.
E. Genard: Emmanuel Genard.
W. Jeffries: William Jeffries.
Michael Nunez: And today we'll be talking about retrospectives, the whys, the what, and the how. We got any learns, and teaches today?
W. Jeffries: I have a teach. I was programming with some colleagues, and I was using Vim again, which I haven't done in awhile. And one of my colleagues noticed that I had made a change, and wasn't sure what the hot key was that I'd used. I told him that I'd used the dot repeat, and he got really excited. It reminded me of how excited I was when I found out that you could hit period, and it would repeat the previous command in Vim. It's super useful.
Aaron Strider: Have you read Vim At The Speed Of Thought? That's a book about Vim, and that is the number one suggestion. That's the first tip. 'N dot', 'N dot', 'N dot'. It's very useful.
W. Jeffries: I'll have to check that book out. I've heard people talk about programming into Speed Of Thought, I did not realize that that phrase came from a book. But now that I hear it I'm sure that it did.
E. Genard: What does the 'n' do in the dot? I know the dot is repeat.
Michael Nunez: Okay, so let's say you're searching for [inaudible 00:01:26] on the page.
So you search, [crosstalk 00:01:27]and then when you go to the actual add an extra read ticks Yeah so in this particular book he recommends instead of doing replace all you make a change on the first one, and you go to the next example. 'N dot', 'N dot', 'N dot'.
E. Genard: all right very cool
Michael Nunez: Today, I managed to teach someone sync settings on ATOM. So ATOM is the preferred editor of choice at the client that I'm at, and someone was getting a new laptop, and was afraid that they would lose all the configurations, but with Sync settings you can save all that. You get the application, or the package, install it. You then make a private gist to remember your data. It creates a chase in a file with all the configurations that you have in ATOM so that all you have to do is when you install sync settings on another computer you just get that gist hash, and then it'll install everything like right on the fly. You set it, and then boom. It just awesome.
E. Genard: Is gist required?
Michael Nunez: Yes, I believe according to the settings it looks for a gist.
Aaron Strider: And is ATOM owned by GitHub, right?
Michael Nunez: Yeah.
Aaron Strider: Right. OK, that makes sense.
Michael Nunez: That's their motive. I think they try to push you to use their services to get that done. But it's great because then you want to make sure that all your configurations are exactly the same from one machine to the other, and sync settings will definitely help you do that, which is dope.
Today we're talking about retros. Does anyone here want to want to enlighten the room? So what is a retro ?
E. Genard: Yeah I've never been to a retro don't tell anyone. So I'm really interested in what a retro even is, really .
W. Jeffries: Yeah, I can talk about that. So a 'retrospective' is a meeting that is one of the recommended ceremonies in Scrum, and the purpose of it is to look back on how things went over the course of the past Sprint. Talk about what went well, what could have gone better, and most importantly what we're going to do about it. So they should have action items. People have different ways of doing Retros. There are lots of different techniques that you can use, and you should be flexible, and do whatever works best for your team. But overall the purpose is to give people a regular recurring time to air grievances, and make suggestions for how to move forward, and make the team better.
E. Genard: For that, does it ever kind of devolve into the blame game or is there a way to avoid that?
W. Jeffries: I don't think I've ever seen a retro devolve into the blame game because it usually - I mean I'm sure that's a thing that happens, and it just hasn't been my experience. I think maybe I'm making it sound more team focused than it is really is. It's about how things went, not about how people behaved. Generally. So usually the kinds of things that come up are like "Oh we weren't able to deploy this week. Let's talk about why that happened" or "Oh we got a new team member, and our velocity jumped up. Like, let's celebrate that". There's positive things as well as constructive things that get brought up.
Michael Nunez: There are times where you may end up, I guess, playing that game, but before that ever happens you have to make sure that retro is a safe space. A safe space for you to be able to express those feelings, but it's not always about "Hey this person didn't do to us" more like all that we as the team didn't do well. So rather than the blaming someone for, you talk about actions that you were able to do, that you were unable to do, and then you try to create ways to ensure that you do more of the things you want, and do less of the things you don't want. But it's not like you sit there, and be like "Oh, this feature didn't happen. I wonder why", and then look at someone who may have had issues throughout the week. But it's more about "Hey you know we were unable to achieve this goal that we said that we would. How can we ensure that that can happen next time?", and that can bring up you know action items like knowledge transferring is a thing. If that person is out, and you make sure that everyone knows what to do. That kind of stuff.
W. Jeffries: So I just want to point out that 'retrospective' is from the Latin root 'retrospectare'. [crosstalk 00:05:44]
Aaron Strider: Nice.
W. Jeffries: Which obviously means 'look' - 'spectare'. And 'retro' - 'back'. [crosstalk 00:05:53] And in other context, such as you know, an art exhibit or every three years the film forum has a retrospective of Fellini films. It's usually his best films. The ones most remembered, not the ones that he's remembered for. So, yeah, retros can be a celebration of what you did well in the previous sprints.
Michael Nunez: That's awesome. And that's a really good way to look at it because that's exactly what you do at a retro: you look back at the previous sprint, and talk about what happened. You mention Fellini - is that the name of the person?
W. Jeffries: Yeah, sure the film director.
Michael Nunez: In those retros, they may just look at his best work, but in a retro normally in Scrum you look at everything which isn't good, and the bad, and try to maximize the good, minimize the bad and make sure that everything goes well. So that the next time you have a retro those action items have been covered in one.
E. Genard: So it sounds, for me, like the biggest why to do a retrospective is really to have, at least, a forum or maybe to space set out that so that you can or the team can, I should say, the team can take a look at itself, right? And that probably is one of those, like you know, feedback things that it's really built into the Agile Manifesto of getting that constant feedback about things so you can know training prove whatever you're doing. And change if you need to really. Any other ideas why you would do a retrospective?
W. Jeffries: To me, the purpose of the retrospective is to do better next sprint. You identify the things that went well this sprint so you can do more of them, things that didn't go so well so you can do something about it. And then you make a plan, like here is how we're going to get better.
Michael Nunez: Yeah, so that you use that time, and retros should be something that happens like often so that you have that time, and that space to share your thoughts about what went well, what didn't go well. Often time people look at retrospectives and thinks is nothing, but like all the bad things, but it's usually a really good time to celebrate like "Oh we deployed a big feature that's getting a lot of good reviews from business". That kind of stuff. And you never get those celebrations like often times you don't get the celebration because "Oh, just on to the next feature". But with the retro on hand, you can take fifteen seconds to say "We deploy this, and we feel great about it".
E. Genard: I would actually like that on a project I'm on right now. We deployed a bunch of stuff. It was just on to the next one.
Michael Nunez: Exactly yeah. So with that space it allows you to celebrate. Take, you know, fifteen seconds to appreciate the work that you did, and the work that the entire team has done.
E. Genard: So, who should show up at the retro? It seems obviously that people in the team should show up, but is there anyone else that may be would be useful to have a retro? that maybe is not there every day with everyone else.
Aaron Strider: I would say no. I think they it's pretty rare for it to make sense for somebody who's not part of a team to be in a retro. The one exception maybe is a facilitator. If you have somebody whose job it is who's like, particularly if you have a team or nobody knows how to run a retro You might want to bring in somebody who does to act as if it to a facilitator. And have that person be in charge of making sure that there's a good rhythm, that you know everybody gets a chance to speak, that you cover all the major sections, and make sure that good action items get taken down. I think that you get that SIEGEL effect, you know, where somebody comes in, and they're not a member of the team they just swooped in to the retrospective and they poop on everything. You really want to avoid that.
Michael Nunez: Yeah yeah I absolutely agree that an outsider can run the retro, but who should be in that retro I think the people who are in the planning meeting for the sprints, and the same people who plan the sprints should then be at the retro. And in fact it's pretty common to have a retro for the previous sprints, and then right after that you have the planning meeting for the following sprints. So you piggybacked them so it's the same people yeah in the same meeting.
E. Genard: Ah so it would be like one right after the other? more or less?
Michael Nunez: Sure.
E. Genard: Yeah.
Michael Nunez: And it would be much more helpful to have the retro first, and then the planning meeting and not the other way around because they want to be enough time to do a retro if it were otherwise.
Aaron Strider: Also you just book a room a new you talk about last week.
Michael Nunez: Sure.
Aaron Strider: And then you go on to the next week. Excuse me the next sprint, and from there you just hash it out.
Michael Nunez: Sure.
Aaron Strider: No one leaves the room.
Michael Nunez: Ten A.M. Thursday morning to ten forty retro. Twenty minute coffee break. Eleven A.M. to eleven forty planning for the following sprints. Next Thursday ten AM repeat.
W. Jeffries: that's pretty short [crosstalk 00:10:49] forty minutes for a retro?
Michael Nunez: What's average you guys have experienced for planning a retro? Curious.
Aaron Strider: I'd say two hours.
Michael Nunez: For each?
Aaron Strider: Yeah yeah. If you have a small team, and you're doing them every two weeks or every one week you can get away with an hour, but one hour is, I think, like the shortest that you can really get by with. I mean I don't know. I mean if you're having good luck with forty minutes, and that's great. I find that an hour especially for retros always feels tight. And I've seen I've seen them drag on for three or four. It depends a lot it's I think primarily a function of how many people are in the retro and how long of a period of time you're retrospective on. So if you have really short sprints then your retro is going to be shorter.
Michael Nunez: Right. Yeah because I think on average for me it's one hour for both the retrospective and the planning. And that usually works out. I've never felt like it was too long, and the reason why one hour work is because we had them every week which you get to cover a weeks worth of retrospecting in one hour. But if like your sprints are a month for some reason that they're really long then you might need a longer retrospective. So it all depends on your sprint on how big the retrospective could be.
E. Genard: What has been the thing that you feel you've gotten the most out of a retrospective? Is there something that sticks out for particular one or maybe what happened in a more regular basis?
Aaron Strider: I think one of the things I do like about a retro is that like often times, and specially in my team right now there are some people who are like very quiet, and to themselves, but they know that in the retro they want to share something they can do it. They'll write it down, and make sure it's posted so that the team can see that they have that there's an issue that everyone agrees on, and then we can talk about those things. I just think like ensuring that everyone's happy about their work is the one big thing I get from retros. I'll be like "Oh we want to make the team better how do we do that?", and everyone joins forces to do that.
Michael Nunez: I enjoy the first phase where you can get your thoughts on paper, and you share with the team your thoughts, and concerns. I'm a software developer it's my opportunity to show that I'm interested in the business side, and wondering if something's going alright on their side if I've a particular issue on the software development side that I just want to share, and it's a very open space where I can get it out there. And that feels good.
W. Jeffries: I think hearing what other people have brought up is my favorite part about the retro because I always feel like my whatever it is that is most on my mind is going to be the thing that it's on the top of everybody else's minds. And sometimes it is, and sometimes it's not. Like seeing where there is a difference of opinion is, I think, often the most telling part of the retro.
Aaron Strider: One thing I find useful about the Retros as an engineer there are different parts of the team that I may not be aware of not that I'm not aware of, no that I'm not aware of but you know Q.A. is going to do something different than what I'm building. So I'm building this feature, and then Q.A. has to ensure that all the features are working well, but I get to hear their concerns at the retro. It's not just, you know, the engineers who are dealing with issues, but also the infrastructure engineer who had issues with the pointing officer production. It's the Q.A. who had an issue with testing a particular feature very very for a very long time, and with that in mind everyone gets to listen to everyone's problem, and if there's a way that another team can step in, and help them iron out those problems it's a good way to just make sure that the team works well.
E. Genard: Yeah it sounds like retros are vital team building tool [inaudible 00:15:00]
Michael Nunez: I absolutely agree it's crucial for the team to come together, and to a lot of stuff gets ironed out, and you work out issues, and it should be a great team building exercise.
W. Jeffries: Yeah I hate to get preachy because I feel like there's more than one right way to do it, and there are probably people out there who have awesome teams that don't do retros, but I agree I feel very strongly. This is a really important meeting to have all of the ceremonies that are recommended in Scrum; this one I think is the most valuable for me personally.
Aaron Strider: Yeah I actually look forward to it because it's like everyone's going to join in, and talk about how we can be better at the end of the day. And the fact that people being enthusiastic about making oneself better something I look forward to because that's what I want to do. I want to be better. I want to be awesome in everything. So if I get a chance to do that with my team, and if I can help out the team in any way shape or form then I'm willing to do.
W. Jeffries: Very well I think the we all made a pretty good case for why retros are useful. We're going to take a quick break, and then we'll come back in talk about how to actually have a retro.
Aaron Strider: And we're back from the break. Tonight we're talking about retrospectives, and we were going to get into faces of the Retros. Does someone want to kick us off on the first phase of a retro?
W. Jeffries: I think that retros are like a lot of other meetings where there are three distinct phases. One is the ideation phase where you're coming up with all of the, you're coming up with all the ideas, and there's no such thing as a bad idea and you just want to get everything out there. And then there's sort of a more a constructive phase where you in a retro you would start grouping the different cards that people had put up there. Organizing them in terms of things that are positive versus things that are constructive or changing, and maybe grouping like items. And then lastly the phase where you cut, eliminate, focus in the key points. I like to think of the first phase is a 'yes, and' phase where the creative juices are really flowing. And then the second phase is a 'yes, but' phase where you're really starting to apply some critical thinking, and then that last phase where you kind of settle in, and create action items to. Do other people have a different perspective?
Aaron Strider: That sounds about right to me. And like the brainstorming can literally be anything that happened on the team. So like you know a positive could be a new team member who's joining, who's bringing you know a fresh pair of eyes into the team, and how things run. A negative could be a snowstorm happens so not a lot of work was able to get done because the network was down. Like, there could be that could be issues that are of the reach of the team, and then there could be issues like "unable to fix this feature because business kept changing the requirements", and what you get action item out of that. Like what do we have to do to ensure that we can get a feature done from A to Z with no interruption from the product owner or the business in that aspect.
Michael Nunez: Yes, so should we talk about the different phases individually for a little bit?
E. Genard: I have a quick question about the brainstorming phase. When you are doing this, is it automatically everyone has just writing down the ideas? how do the ideas come up? Because I've been in groups where if the person is saying something or if it's like everyone just shouting stuff out certain people will dominate the conversation, and other people like me feel, you know, well I don't have to say anything everyone is saying something or maybe I don't want to say anything. Or maybe I'm kind of shy here. It doesn't really matter what I say.
Aaron Strider: Yeah, there's many ways to run the brainstorming phase, but I think a key point is that it's quantity over quality. Just get them out there. Everyone has a voice. If you have something to say, this is your time to share, and a good facilitator will enable this. So a facilitator might ask people to write little sticky notes like a brief sentence that they would read out loud. You know, one person might be happy about that they completed this feature this week, and then there'd be a sad that there's lots of technical debt and both of those ideas would go up on the board.
Michael Nunez: Yeah, like Aaron mention, you get a ton of stickies. I guess like if you had a one hour retro You probably take five minutes, and each person has you want to keep like the same color so that you can identify who's writing what. So if you have plain yellow Post It notes and Sharpie, and everyone's writing their ideas out, and just putting them up. All your ideas are there, and there's no one over shouting or talking over you because everything is just written out on the board. So even if a person who doesn't is really shy they still get the opportunity to voice their opinion when they put the sticky note on the wall.
Aaron Strider: It's human nature to start addressing each issue right away to start discussing possible solutions, but it's actually not the time for that. It's more important to get more ideas out there so a good facilitator will cut short any, like, extend discussion over any particular idea.
W. Jeffries: Yeah I think it might be helpful to go over some of the nuts, and bolts.
Aaron Strider: Sure.
W. Jeffries: Like equipment that you're going to need.
Aaron Strider: Yeah.
W. Jeffries: Like sticky notes or index cards or if you have a remote team then either a Google Doc or a Google Doodle. Something where remote people can share their ideas. Some people think it's important to identify who it is that contributed each idea. Some people don't. Have done it both ways I kind of like anonymity. I think that people tend to be more honest if they can't be directly traced back to the action item, but there's I'm sure lots of good reasons for making things that identifiable too. So, in addition to the thing you're actually going to write all of your retro items on, you are probably going to want to have a board that has a parking lot for things that we want to discuss more later, you want to table for a while. A list of who, what, when for your action items which I guess we can talk about later when we get to that section, and you probably want you might want to have a one sentence board where everybody writes down a sentence about what it is they're hoping to get out of the retro. At a minimum you need the cards. I've seen on some team I've done free form bullets, and another team's I've done cards. And what's nice about the cards is that they kind of force you to be succinct.
Michael Nunez: Here let's move on to the identifying trends part. So what does that involve?
Aaron Strider: So usually in a retro a lot of people may have similar ideas that they put on the board. So the facilitator will then, after the time allotted to actually put the ideas up, the facilitator will then try group them into different trends, on different, like, pockets, and separate like "Oh Okay people are happy this person join the team people", "People want to discuss our deployment process, and how we can make it better". A lot of people are concerned about tech that, and the facilitator takes some time, maybe three minutes to five depending on long takes to find these different groups of ideas, so that we're not talking about each one specifically, but we have a general idea "OK we have something here", "We have something there". And some trends may have three stickies, some trends we have seven. That way we don't have to read each individual one, but just grasp the idea of all the ideas that were up there.
Michael Nunez: So, William, you mention this as the 'yes, but' phase so I wonder if you could expand on that. What did you mean?
W. Jeffries:So one of the things that usually happens during this phase, after you've gone through, and taken all the cards that are similar in group them together, is you will dot vote on which items should have the floor, because you're probably not going to have enough time to talk about every single item that people put up. Nor would you want to, because a lot of them are like "Thanksgiving happened that was awesome". Like that's nice, true, I don't know that we want to take time out of the meeting there to talk about it. So dot voting allows everybody to hone in on the things that they feel need the floor, need to be discussed. So usually everybody gets three dots or maybe however many dots you want.
On my current team, we do you three dots for positive things, and three dots for constructive things because the positive things tended not to get a lot of votes. And I think it's important to take some time to celebrate during the retros, and to reinforce that good behavior and the good process. So then once you actually get into discussing the items that have the most votes that's when people often start to push back, and say "Well yeah our cycle time is higher, but there are all these good reasons why that happened, and it's just a fluke, and we should probably not have any action items related to it because it'll probably go away next sprint" or whatever.
Michael Nunez: I always find how it's interesting how certain topics people just rally around. I don't really understand what the wisdom of the crowds is. I don't quite understand it, but it's always fascinating what people tend to choose during this phase, and it's interesting when I like a topic that only maybe only belongs in one trend only one person mentioned it during the retro, but then everyone decides to vote for that one. For example, usually you know people might talk about you know tech design or one day one person said "Stand up meetings are late", you know, and everyone chose that one. And we came up with a whole you know I guess we'll speak about that more in the next phase, but it's amazing what gets chosen during this process.
Aaron Strider: Yeah, because like even though you have you can have a topic that has seven different post its, could be that one that everyone's actually really interested in or may overlook realize "Oh snap - that's a problem. I'm going to vote for that because I want to talk about that". It's interesting. I know it's happened before, but I never realized that.
W. Jeffries: It seems like there is a herding effect sometimes where people just want to pile on to the popular topic.
Michael Nunez: OK. Well, the final.
W. Jeffries: Action items.
Aaron Strider: Right, so then after having that discussion, and trying to figure out what are some of the ways we can know a particular issue if it is an issue. Because if it's a good thing [inaudible 00:26:18] reasonable action of action items you keep doing that like there's not much for that, but let's say if we had too much tech debt that we need to go through we have the who, what, and when or by when. And suppose we had a discussion about tech debt, "Okay who's going to tackle the tech debt. Bobby is going to take two hours at the end of the day to look over, and work on tech debt next sprint". That way Bobby can then work on that, and he's responsible for that. So if you want to know the status of that particular action item you know who to go to. It's not just "All right team, lets all do better. That isn't a goal that you can point out, and say "Have we progressed or have we not?"
E. Genard: How do you decide the person?
Aaron Strider: I think it happens in the in the group I mean well what do you think?
W. Jeffries: So you want to have who, what, when, and where. There's a very specific person, a very specific thing, in a very specific time for completion, and it usually seems like there's one person who is the most likely candidate for it to ask. I find that most often it's the product manager or the project manager who is the one usually the one leading the retrospective, and who usually handles a lot of the admin stuff. I find that often the retro items are "We should have this meeting" or "Schedule that". But for things that are more directly really related to the code, and things that an individual team member could take on it usually, in my experience, is who doesn't have that many action items already. So you can kind of share the burden. You don't want you know just that you're one team lead doing all the action items.
Michael Nunez: Yeah, you can't them all at Bobby, and then expect him to go, and just tackle every single action item that has been written out in a retro. You want to spread it out. Make sure everyone has, you know, a good amount of work to ensure that those action items got done.
Aaron Strider: Yeah, and it's important to have those, like, expectations for when it's actually going to get done, because if you don't, if you're not checking that next retrospective to see that everything actually got done, then it's really easy for action items to drag on forever.
Michael Nunez: And when you check the previous Retros action items?
W. Jeffries: I've seen it different ways. On my current team we have a separate story board, and we make stories for all our action item. They're not written out like user stories as "me: I'm going to-
Aaron Strider: -do this by that."
W. Jeffries: I mean, that's interesting, right? We got into the bolts of this year, and it seems like I don't know every time I learn more more about Scrum, Agile, and all of those things it just seems to me that there is ultimately a set of things to try, and have people talking to each other. And be on the same page about things, and moving it in a direction they want to move in. Let me say that. And yet at the end of the day, at the end of this podcast, end of the meeting it's just seems like all of this is trying to make a better team or a better communicator team. Some things like that I don't know if that makes sense.
Aaron Strider: Yeah, because at the end of the day you want to ensure that everyone's on the same page, and that particular idea is "Let's be better then before we start this retro, and by the beginning of the next one we should get better by obtaining and completing these action items". At that particular point in time, the entire team gets together, and express their feelings, and their ideas. And it's important because you want to make sure that everyone knows the main points of coming into work, and if there is any. If everything is fine and dandy, which 99 % of the time there's always something that you can work on, that space is there for you to do that, and when everyone comes in looking to better themselves, as a team, your team gets better.
W. Jeffries: Yeah I think that what's nice about Scrum, and their recommendations around which ceremonies to have is that they cover your bases. Like you should have a plan, and you should touch base regularly so that's the planning, and you should touch base regularly to communicate with your team members about what it is you're doing as a stand up, and then you should periodically revisit the things that you've done, and try, and see how you can get better, and that's the retro. And the I guess there's also demos, and perhaps a few other things, but generally it tries to focus you on the bare minimum number of meetings in order to be able to accomplish that kind of communication in that kind of process because if you don't have a framework, and you're just ad hoc trying to schedule meetings when it feels like we should have a look back, and see how things are going or it feels like we should get together, and talk about our general plan, then you end up having too many meetings or too few. Too many meetings of the wrong kind.
Michael Nunez: I'm amazed that anyone would have to be convinced to try this out. I mean, don't you want a better team?
Aaron Strider: You'd be surprised though because, like, a lot of people see a retrospective as just another meeting, and it's like "Oh, I don't want to". Be rather be you know putting out these features than having this, but it's not until I usually find that I have struggle with the product owners who just want those features, but the developers, and the engineers are the ones that really want retro, because they want to express some ideas that they have, and how to make their process better.
W. Jeffries: Yeah I think often when people push back against scrum, or against Agile in general it's because they've had a bad experience with a with improper implementation, and so they've been in retros they take an entire day, and the action items never get done anyway, and it's like, why would you bother?
Michael Nunez: Right. I had someone, a client express that to me at this afternoon right before.
Aaron Strider: Oh, interesting.
Michael Nunez: Yeah the retrospective they were having, they were just pointless to him.
Aaron Strider: Well, have him listen to the podcast and see if they change their mind.
Michael Nunez: Do you want to talk about any retro tricks? Tricks that you may have up your sleeve to ina retro to facilitate or facilitating or being a part of, and the types and what not.
W. Jeffries: So one thing you can do if people are waiting to see how other people voted, like, you were talking earlier Aaron about hurting everybody ends up voting on one item, and it's unclear why I think sometimes it's because they see the team leader or somebody higher up picking that to talk about. So they want to be agreeable. One thing you can do is you can make it anonymous or you can give the last person to vote one fewer vote as an incentive to go quickly.
Michael Nunez: Interesting because that last person just saw everyone vote so he's probably going to pick the ones that he or she sees me as going to pick the one that has the most just finish it off.
Aaron Strider: Yeah I think another thing that I like to do, I guess you could call this a trick, is to give people a way of piling on without voting for a thing. So like we had a team member move on to another project, and everybody wanted to express that yes we make somebody put that up as a hard thing that happened this week, and everybody wanted to say yes I agree we missed this person who just left, but there wasn't really anything to discuss later. We all knew that he was leaving we knew for a while now he's gone. It's a bummer. OK moving on. So I have like on my current team we have plus ones on the cards, and anybody who wants to can go and do a plus one, but that's not their dot vote.
Michael Nunez: Oh I see. Just a plus one to acknowledge that they agree with that, but that's not their vote that they're willing to discuss with on.
Aaron Strider: Right, It's like a "Hell yeah, totally on board, but you know I'm not going to spend my vote on that. I just want to be supportive".
Michael Nunez: Oh interesting, I like the plus one. I should use that. Introduce that to our retros.
Aaron Strider: Yeah I would my tip would be to be honest if you are saving your sad face for someone leaving a team that is sad, but is there something that you're not sharing. The retro is often a good time to raise your concerns I would also say like any other meeting put down your smartphone on your computers, and pay attention, and be present that's a really crucial for retro to work.
W. Jeffries: Absolutely. Seconded, plus one.
Aaron Strider: Yeah because like even the law top out kid definitely like just the fact that everyone will see like this person on a laptop like what's going on what's more important than making the team better, right? And it's almost disrespectful because like you have to pull that person "Hey maybe next time close that laptop. We gotta make the team better, and that doesn't really look good.
W. Jeffries: Yeah, I am guilty of that. I've totally done that, and it does make me less present, and it makes me less able to contribute and I HATE IT. I hate it when other people do it, I hate it when I do it. Just be present close your laptop.
E. Genard: All right so we have learnt a lot about Retros today, and I've learned a lot about retros because never had one, and all of the other panelist have had one. I look forward to hopefully having a chance to try them out. There are a couple of things I'd like to speak about at the client I'm at. It's a pretty good client I enjoyed, but there are a couple of things that could be made better, and would lead to a better team, and working environment. Any closing thoughts?
Aaron Strider: Every team should have a retro. I definitely suggest that. It's pretty dope to get to listen to your team members opinions in their thoughts, their main points, what they're happy about, what they want to work on, what they want to make better. And when everyone has that energy, it just makes the team better. Like you know that your team, people in your team want to get better.
Michael Nunez: All right. Awesome. That was a great conversation. Does anyone have any picks they want to discuss for this next week?
Aaron Strider: Well I recently moved to a new client, and I'm working in a front end javascript react project so it's been a while since I've worked on the front end. And we're using web pack to compile all of our Java scripts, and CSS into one file. The CSS and the javascript file so when you open the source its just one loading of one source, and it blew my mind. It's like magic. Just Like magic just like this whole thing that gets compiled.
Michael Nunez: Yeah, it sounds like you've been working with it for a while?
Aaron Strider: Yeah, we have it. It's been a configuration that happens in our react project, but I never really fiddle around. The pack has like just been set up, and I say my project, and it gets bundle, and that web pack does some magic, and it's amazing.
Michael Nunez: All right.
Aaron Strider: That's my pick me. There you go.
Michael Nunez: All right ladies, and gentlemen I like to thank everyone, and all the panelists who are here today to talk about retrospectives. That was awesome. And thank you all for listening to the Rabbit Hole. Will see you next time.
Stride Consulting
Rabbit Hole on Twitter
Practical Vim: Edit Text at the Speed of Thought
Scrum
