Yeti Lunch and Learn: Retrospectives

Video Transcipt

America: Hello. My name is America and I am a project manager at Yeti, and today we’re going to be talking about Retrospectives. So you’ve all probably at least been in a Retrospective before. They’re meetings. They should be occurring on a regular basis where the team therefore has an opportunity to reflect on their past work. The work that you’ve done together, figure out what’s been working for the team, what hasn’t been working for the team, and ideally choosing what the team would like to improve.

So a lot of the time Retrospectives and Postmortem are used interchangeably. And for a long time I thought that they were just two words for the same thing. They’re not at all actually. Postmortem is something that has a much longer feedback loop. So you would do a postmortem maybe every six months to even once a year, or just after the end of a project. They are usually much longer meetings. And you’re looking at just overall how a chunk of time has gone. And potentially looking at items you can use moving forward towards a new project or a new phase. Whereas a Retro is like a shorter feedback loop. So Retro should be happening at the end of every sprint. If your sprinting on a weekly basis, probably every other week which is usually around when we run them at Yeti. And the idea here is that you can make micro adjustments to how your team is working. So just like how we iterate our products. We can iterate on how we’re all working together to make sure that our performance over time is increasing.

So how you run a Retrospective. A lot of the time you will start with something called the prime directive. At Yeti, we don’t need to go over this every single time because we’re such a small team. But the idea is to start the meeting with kind of just creating a space where everyone can be involved. It creates the sense that it’s not a time for blaming anybody. It’s not a time for pointing fingers. It’s simply a time for working together to try and focus on events that have happened and how we could improve the outcome of old events if they happen in the future.

The first thing that you want to do in a Retrospective is generate ideas. It can be done in a lot of different ways. Just kind of the classic good, better, best model. Recently we’ve been using liked, lacked, learned. And there is also a lot of other kind of fun activities like making a hot air balloon and you can look at what’s holding the balloon down, what’s pushing the balloon up. And then if there’s like any forces that could knock the balloon off of its trajectory. But at the end of the day, it’s all the same principle, and it’s ideally used to celebrate the successes that the team has had. And it’s also focused on what could actually be improved.

The next step is a discussion section. So once you generate all of your ideas, how will you generate them, then you want to actually choose somebody to talk to. Here there’s two separate camps that people usually fall into. There’s one big camp that says this is just discussion time and you shouldn’t take notes on this. You shouldn’t get action items out of this. I’ve never personally understood that because I feel like if we have a big good discussion and we don’t actually get anything out of it, then why did we pull everyone in to a meeting? So I fall into camp two here where I feel like you should be having a good discussion but that discussion should be focused on generating action points that could be reported to actually help promote that change.

So overall, like what is the point of these meetings? Improvement. Like I’ve talked about a lot. Also bringing team issues to light. So it’s a good opportunity to talk about in a constructive way if people haven’t been working together very well, if there is team friction, it’s kind of the perfect opportunity to bring that up. And overall talking about the group dynamics. That could be the group dynamics within your team. Or, we do a lot of client work, so the group dynamics working with our clients and how we can improve that.

And so the biggest question that is always sort of been lingering I think in both Yeti Retros and Retros in general is that you get all of these really great information, but what do you actually do with it? You can give people action items that they can action on. But how do you plan time to review the [inaudible 0:04:41] that have actually followed through on, and if they’re actually working. So that’s something I think everyone in the agile community is still figuring out.

A lot of the time also people don’t like Retros. They’re seen as kind of a big waste of people’s time, because there is a time commitment. Usually they take at least an hour, and so that’s an hour every other week of your team’s time. And I think a lot of the time people feel like they could be doing development work or design work or having other meetings during that time. But kind of like we discussed, Retros are really important and you won’t see team change unless you’re actually reviewing your behavior. And Retros can make people feel very uncomfortable because you’re talking about team dynamics, you could potentially hear from a team member that you’re doing something that is bothering them or isn’t working for the team.

And also there can be a feeling when teams are doing really well and maybe haven’t having Retrospectives really regularly, like they don’t need them anymore. But that is also another dangerous road to go down because no matter what you’re never too good to be reviewing your own work and to be learning from it. And so even if your Retro is really quick and it’s just taking 30 minutes, taking that time as team together is really important to just be re-synch.

So I’ve been pulling our Retro data for about a year now. I’ve been reporting every [inaudible 0:06:03] that we make. Every discussion point that we have. And I pulled this data into a big spreadsheet. Summer helped me organize it into kind of the top five things that we saw were going well and top five things that we could improve on. This data is a little bit stale because it’s coming from like year or a year and a half ago up until the end of this current year. So the top five things that have been going well for us is we are having really good cooperation between development and design. That’s something that I know has changed over the course of time because there has been a big friction point in the past. We’re also doing a lot better on our client communication. Having someone in a project management role has been cited as something that’s been very helpful. Doing regular design crits when we’re doing design work has been really great. And overall we’re having really great teamwork, which is awesome to see.

Some things that we could be improving on. A lot of the time I saw we were citing that we don’t have the dev and design start time exactly down part which I think is still a pinpoint for us. Synching tools like Invision making sure that they’re always up to date with like the latest and greatest set of designs is still a pinpoint. Meeting expectations. Making sure all meetings have agendas. The right people are invited to them. The right things are going on is still something that’s a pinpoint. This idea with branding in an SOW, how that gets back [inaudible 0:07:30] the right person to be doing that. That’s been happening since 2017 and it’s something that has come up a few times. And then I think this is something that we’re improving on now especially with our [inaudible 0:07:44] project. Providing higher level team leadership and strategies.

So one thing that we started to implement is this Lessons Learned document. It’s a spreadsheet. You can access it in the team drive under Company under Project Management. Anyone is welcome to look at it, add things to it. Basically after every Retro if there’s a big item that we would do differently and [inaudible 0:08:09] it there, and finding a project that it is coming from and what we would do differently. So that, ideally, in the future when we start a new project we can take a look at that to just remind ourselves. I’m not sure exactly the best way to really utilize this document. So if anybody has suggestions we’re open to hearing them. But I think we’ve taken the first step which is the hardest which is just reporting all of our data. Yeah, that is Retrospectives. Does anybody have any questions? We can dive more into the actual Retro points that we brought up specific to Yeti. Any questions?

AM: How much more effective do you think the hour long retrospectives are as opposed to the shorter ones?

America: I think a half hour is just not going to be effective at all because if you take into account everyone’s going to be a few minutes late to the meeting. So let’s say you’re starting out five minutes late. [Inaudible 0:09:03] generation takes everyone between six to ten minutes.  Then actually putting up the [inaudible 0:09:08], talking through them is another roughly ten. So then you’re leaving about 30 minutes for discussion. I think on some projects that have been Retro-ing now for like months, like [inaudible 0:09:19] is a good example of a project where everyone kind of like gets in the room, knows what they’re doing and gets everything done. It will take about 45 minutes. But I’ll tell you don’t what to schedule anything less than an hour.

AM: Do you have any feelings or opinions on how to prompt people that might be a little less verbal or sharing in Retros? Maybe kind of ways that you can facilitate getting the actual information out of them that [inaudible 0:09:55]?

America: Yeah. So I think a big part of that is the [inaudible 0:09:59] generation because everyone does that is a silo by themselves. And then something that I have been trying to do more is to have, rather than like dot voting on post steps, like calling on each person to think of something that they want to talk about. And hoping this will help to get people who maybe don’t feel like they are as opinionated or would hold back normally at least to the topic that interests them the most. Whether or not that’s actually the most important topic for the group to be talking about, sort of doesn’t matter at that point because usually there is only a couple of them that are really important then. So I think everyone having a voice is awesome. But in terms of like during the discussion, I’m not sure because it’s a little hard because you don’t want to also like push too hard on someone. So if anybody has suggestions on that I’m definitely open to hearing them.

AM: How do you say… Because one thing that we’re looking at is like trying to take the Retrospectives item so we also look at the possible working agreements. Since working with like [inaudible 0:11:07] on working agreement, how would you say is best to kind of like let… This is when working agreements with Retrospectives, [inaudible 0:11:17] yeah.

America: What I’ve heard with working agreements is that usually they’re brought sort of up during the first part of the Retrospectives. The first thing you do is actually review the working agreements and kind of do [inaudible 0:11:29] voting on if we feel like we’re following it, if we’re not…If we’re not following it like where are we not following it, and that would intend to become a Retro item to discuss. And then, especially where we have a working agreement with a larger client, like during those regional alignment meetings that we have with executives, bringing the working agreement to them because they’re not seeing it as often and it’s kind of easily forgotten, it’s always a good plan. Especially if we have feelings on areas that maybe aren’t working as well for us to kind of like know where those are going.

AM: What would you say… It’s like we do Retros externally. We’ve done some Retros with clients. What would you say is the level of involvement that would be ideal based on like should we get our executive stakeholders involved in Retrospectives? Should we [Inaudible 0:12:21]. Who should we involve in our Retrospectives?

America: It’s really tricky because a big part of what we do is very consultative and so we don’t really necessarily want to just get really down on our clients in a medium like that. So I kind of feel like they sort of want these to be [inaudible 0:12:41] meetings. In a situation like [inaudible 0:12:43] where we’re actually really engrained with their internal team, I think it would totally be acceptable to have like Rob, Matt, Andy come to our Retrospectives on a regular basis. And then to treat the vision alignment meeting tomorrow is like a timeline. We would bring in more key stakeholders. Just because you want to make sure that it’s always a safe space for the team on the ground to be able to express frustration or like talk through things that wouldn’t be as appropriate to bring up like with a key stakeholder in the room. But it’s also important to be able to [inaudible 0:13:19] key stakeholders what things aren’t working and what they could be doing better, and letting them be part of [inaudible 0:13:24]. Did that answer your question?

AM: Yeah, I think so. I’m trying to figure this out.

America: Yeah. It’s definitely tricky especially when the key stakeholders are not members of like our company and they’re kind of outside agency.

AM: [Inaudible 0:13:44 to 0:13:57]

America: Yeah, totally. I think it definitely can be. I think it can be effective to run Retrospectives with different teams and also with different team make ups both within the span time and also outside of the span time. So I feel with a lot of voice it could have been good to be running Retros with Sharon and Carey during the design time. And then also to have more of a postmortem which I think we’re going to be doing for looking at the whole design process to see like how that went. If we were working with a team kind of like we are with [inaudible 0:14:38], if there was a situation where our internal team just solidly wanted to Retro I think that’s totally appropriate to ask for, and that not everyone always has to be included in every single meeting as long as those meetings are intentional like the time as usual [inaudible 0:14:53]

Anybody have any ideas like what to do with all these Retro data that I’m like gathering?

AM: Like a lot of them. [Inaudible 0:15:10]

America: That would like cover every single inch of our –

[Inaudible 0:15:16]

America: Yeah, definitely.

AM: It’s really good for like blogposts and like videos. Like top five mistakes we’ve seen in projects. Like lessons learned when working with whatever. I think there’s all kinds of really big data.

America: Well, there’s a lot of it. So, we can definitely look through it.

AM: There is a lot you could do with it, before you start with clients [inaudible 0:15:55]

America: That is all I have. Thanks guys.

‍