Team Retrospectives

Jon:  Hey, everybody. Welcome to even keeled episode two. I'm your host, Jon Kinney, and today we'll be talking with another developer on the headway team, Andrew Stuntz. Welcome to Even Keeled Andrew. 

Stuntz: Thanks, Jon.

Jon: So Andrew, you recently wrote a blog post on the headway site about team retros. I'd love to dive into some of your thoughts on retros project work in general, but first, why don't you give us a little bit more background about you?

Stuntz: My name's Andrew and I'm a senior software developer at headway.   I've worked at headway for about a year and a half now. I've worked on some big projects some little projects. I mostly work in Ruby on Rails, but also do some react and react native work. In fact, we just finished launching a react native app that went quite swimmingly.

Over my years, I've worked on  lots of different development teams from very small teams to very large teams. Anything between like just two of us all the way up to giant projects that have 50 plus developers on them, and trying to organize and figure out what everyone's up to and how that all works.

I mostly work on large consumer facing projects, but have also done business to business and CRMs and inventory management systems. I've kind of been all over the stack, with backend and front end.

Jon:   Have you mostly been contributing to those project teams as a developer? Or have you ever done any project management work in any of your roles or technical oversight?

Stuntz: So I have worked mostly as an individual contributor on those teams, but really try to lead up and down the stack while, working on those and am trying to  maneuver myself into more of a developer project manager role as it is. So I care a lot about teams and team building and project management and agile, and making sure that the development team is working well and following those processes and setting us as the developers up for success on any given team.

 Jon: And part of setting up for success is talking about what went well and what didn't go well. So we're here today to talk a little bit about retros and how to be effective in that communication.  How have retros impacted you and your career so far?

Stuntz: I love retros. I think they're my favorite meeting in the agile process. I really think that they get at the root of what agile is. And in high stress projects, I really think that retros have helped to diffuse a lot of the stress and sometimes the frustration that comes with being a developer on projects, where things aren't always going right, or things aren't always moving as quickly as we want.

And retros are really an opportunity to take the temperature of the team and readjust and reevaluate  how things are going and work to make those things better.  A lot of people think about agile as this process that's supposed to minimize the risk of working on software or working on the wrong software as the case may be, and I think retros are really  a tool for managing that same risk, but for the human oriented aspect of that. So you get to manage the risk of a team falling apart, or manage the risk of a team, not following a certain process in a certain way so that you can work better together moving forward. 

Jon: That makes a lot of sense and we value retros that headway, but it isn't always one of the things that's first on people's list in a software project, they don't always think about, you know, hey, we're going to design some stuff, we're going to develop some stuff and then we should really talk about how it went to every sprint.  The demo is very important, but then oftentimes I see teams jump right into the next sprint plan and not really take time to reflect on what went well or what they could improve. And I'm sure a lot of our listeners are in that same situation either they might believe that retros could be somewhat optional or as a developer they're feeling, that their voices aren't being heard when they're asking for a retro. So what, what's your opinion on that?   Are retros truly optional or are they a nice to have? They definitely take up a lot of time, so what do we get?

Stuntz: I think retros are not optional if I had my choice, but obviously not every team has the opportunity to run a retro. But I think they're extremely valuable. They provide the context to allow us to kind of get out of our shells a little bit as, a human being that's maybe looked upon as the person that's taking a ticket from a backlog and then does the little bit of work and puts a pull request up and then they take another ticket off the backlog and they put it up because we are more than that, and as a developer, I think that we bring a lot to the table to product teams and having feedback for that product team is crucial.   As developers, I think we make probably more decisions about the product then, like anyone else in the process on any given day, especially while we're working on individual tickets or individual stories and that really means that our feedback should be listened to and is extremely valuable and I think retros are great way to get that feedback and a great way to talk more about how the process is working for the development team.  

There's a lot of  emphasis that goes into planning, sprints, and making sure that sprint's get started nicely, but there's sometimes a lack of what happens when that sprint is actually started, and I think retros are a great way to kind of end a sprint and make sure that everything is on an even playing field and then start a new with that next sprint, rather than just being in the dredges of sprint after sprint, after sprint and never feeling like anything's changing or that you're not growing as a team and it really puts the pulse and the onus on the team itself to come together and become more than just a bunch of developers that are doing development work in a vacuum.

  Jon: So, do you have any anecdotes about like if you were an engineer and you wanted to bring the retro process to your organization, perhaps you're already doing agile, and you're doing standups and whatnot, but the retro piece is missing, do you have any quick wins or like examples of things that a, retro really helped save a project that you could share with an engineer who might be looking to try and bring this process to their company.

Stuntz: Definitely. I think you can go at it from a, this is part of the agile process and that in the agile manifesto, there is a retro that's referenced and it's important for the agile process to grow as a team and to grow together. But you can also look at it as a way of resolving some of those  issues that you have as a team. So if you are having issues like certain developers are angry at one another, or there's frustration around certain processes or there's processes that aren't happening, that you'd like to see happen, or there's no communication between development and design or there's no communication between development and product, or there's no communication between development and customer success. Really at any level, there could be any kind of communication breakdown and a retro lets you address some of that and work towards enhancing the team so that they can get better and they can work together to plug those holes and communication, or, add that process that they want to see or change the process that's not working for some people. And sometimes what I find is most enlightening about retros is that all you have to do is communicate about it and then all of a sudden people realize that there's an issue there and it's easy to fix.

The important thing here is that we're talking and communicating about it and that, some sort of action is happening from that. And a retro really allows that process to be facilitated.

Jon: It's almost like the TDD process, right? Red, green refactor. You have to start and sometimes writing that smallest first test really helps get you in the flow. And so if you're nervous about starting a retro process or getting that instilled in your organization, just trying to find 15 minutes even maybe it's at your lunch break or something if the company isn't sponsoring the time yet and just get the ball rolling. And I think the more folks that you can include in those discussions, the sooner they'll see that value and the easier it'll be to continue to have retros work their way as a more formal part of the process.

So, do you have anything that you would say to a manager or an owner of a company, from a different view. Maybe if the engineer was leading up,  that you help encourage those people who are listening to either, if their teams aren't yet doing retros and don't know what it is or how to do it, that they could be positively encouraging of that new practice. Or if they've been quashing the desire for a retro, how to maybe look at that a different way. 

Stuntz: I think from the viewpoint of managers that are outside of the context of a product team, it can be hard to say, hey, we need to spend an hour of our time every two weeks or every month to talk about issues that are happening as a development team. But I think for those managers, it's important for them to realize that it's, only an hour and you reap those benefits in all of the other time that the development team is working together.

At any point in the sprint, there could be issues that are coming up that are interpersonal or, within certain sects of the team or any sort of issue that's, outside of, oh, hey, development is going wrong.  Retros really are there to address those issues. So, even when you spend an hour and you feel like maybe it's wasted or not going towards  actual product development, you get that all back when the team is working better together for the rest of the sprint and that kind of benefit you can't necessarily measure because it's probably way greater than the wasted hour wasted hour in quotes that you otherwise would be spending on a retro.

Jon: Well, and a big thing about running a successful company or consultancy or developing a product that you're going to launch to market is risk mitigation. And trying to figure out your unknown unknowns. And if you're not talking about them, that can really easily just sail right over your head. And so if you aren't doing one on ones with your team, or you don't have a different way to surface some of these, challenges or frustrations that are just natural, you're going to miss out on a lot of the risk mitigation capabilities and having a retro where everyone can voice concerns or frustrations, and then also appreciations and wins and things that they want to lean into, I think could actually be extremely efficient in helping get all of that stuff worked through in a given hour. And that could even be perhaps more productive than some of the other more individualized strategies that folks might go down the path of to try and figure out what's going well or what isn't going well amongst their team.

So what are some things you've seen go well in a retro.

Stuntz: The biggest thing that I've seen in retros is getting teams, just talking to one another. It's amazed me just how little communication there is, or can be between members of the team. And I've seen teams that have been very frustrated working with one another because there's, some folks that don't like it done that way, and some folks that will only write code in some other way. And really, it just came down to they weren't communicating about how they felt about those things and it just was rubbing everyone on the team in the wrong way. And just bringing those things out into the open, whether or not  any of the developers were interested in changing their ways, or it had an effect on the way that those developers worked, just having that communication was super important. And it really allowed other lines of communication to open up because we had a place where we could vent that frustration. So we were able to not only provide a place for communication when we were frustrated, but also allow for all of those people to start communicating better together in Slack and better together when we had standups so that when not everyone was feeling just like so angsty and frustrated with one another, they could really just start saying what they needed to say without any anger or any interpersonal issues, preventing them from being the best that they could be.

 Jon: So getting everyone talking is one of the things that is a huge positive benefit of a retro. Have you seen processes get instilled after a different  retro has happened? That has brought some issues to light. Or some things that used to happen in a project that, got removed.

Stuntz: One example that I have of that is that I was working on a product team quite a few years ago, and things were going mostly pretty well, but it was apparent that one of our key stakeholders wasn't willing to even look in JIRA So we were super frustrated that this key stakeholder wasn't able to communicate with the development team in any sort of manner, because he didn't see any work being done. So not only did he not think that we were doing anything, but he had no way to, empower himself to  figure out what we were doing. So because of that, we were able to, find and a different way to communicate with him. And what we ended up doing was sending him a summary email of JIRA on a weekly basis.  So we were able to sum up all of that work and push that email out and our communication with that key stakeholder was able to increase like tenfold because we were presenting that information to him in the right way. And that really came out in a retro one day when our project manager was telling us that he felt super frustrated because that key stakeholder wasn't willing to even look in JIRA. And so we were able to come up with an alternative and our project manager wasn't stoked on the alternative because he felt like having a different way of communicating was like usurping the use of JIRA, but it ended up working out in the end.

Jon: So you were able to identify a situation with your stakeholder in a retro, was the stakeholder involved in that retro? And I guess whether or not they were, when is the right time to include a stakeholder in a retro, and it should be the same meeting as the rest of the team, or perhaps a separate one. What are your thoughts on stakeholders involvement?

Stuntz: So in that specific case, the stakeholder was not involved and that was on purpose because he would have seen the negativity and the frustration from that specific team and things probably would not have gone very well. He probably would have taken that very personally and, things wouldn't have gone that well.

So mostly because of have that experience working with that specific team, I think that stakeholders should not be around in retros. There are certain cases where I think that stakeholders who are very involved with a certain team should be involved in a retro. Stakeholders that have a  strong stake in the work that is happening, or they want to be included in the communication  a little bit  better and they're not taking everything that you say personally, should be involved in retros, but for the most part, I usually discourage stakeholders being a part of retros.

Jon: So I could see a team maybe who hasn't done a retro process before or done any research on best practices, wondering who would be the best person to facilitate that retro. I could see perhaps a naive view saying, Oh, the stakeholder should  facilitate that. Right? Like let's have, whoever is in charge of owning this project or who we're going to report up to come hear about all the things that we would love to go smoother.

But that might not be a very good fit.     If we're saying that the stakeholders shouldn't even be involved at all,  then they, they almost certainly shouldn't be the one facilitating the retro.  So who do you recommend does facilitate that retro meeting?

Stuntz: In the agile manifesto,  your scrum master is the person that is facilitating a sprint retro. And that's great, especially when there's a lot of trust between teams and those teams are already kind of operating well. And there's no like big frustrations. But when things start going kind of sideways or you're having issues. I think having a third party being that facilitator is important. It lets the facilitator be a part of the retro if they want to and it alleviates any tension that could be there for communicating about your problems.

 I've worked with a few managers who feel like any sort of problem is a really bad thing. And I think as developers, we know like problems happen all the time and we're always finding new ways to come up with solutions. And a retro is one way to come up with those new solutions and having problems is a good thing for retro because it means you can move forward and you can get better and I think we can all get better. So, back to the facilitator question, definitely try to recommend having a third party be involved, that can run the retro just to keep some of those weird relationships from rubbing the wrong way ,  or preventing people from talking about the problems.

 Jon: Yeah, that's good advice. One thing I've seen happen sometimes in retros, when you have perhaps, uh, like that scrum master or somebody who's a little bit more involved in the weeds, trying to help facilitate the retro is two problems. They aren't able to participate  fully themselves. And perhaps they'd be a little bit more on the defensive. And so I've seen, situations and I think I've probably even been this person who, we're getting feedback from the team and all of a sudden you want to explain all the reasons why their point of view perhaps, uh, is, misinformed, or here's the reason why we did a certain thing, and try to explain away or kind of dominate the conversation with fixing it, and trying to lead, but in kind of a poor way where you're taking over the time from your team members who really should have this opportunity to voice their concerns, the retro is for the team, primarily to be able to help lead up really and show some of the problems that they're seeing and perhaps give some opportunities to fix it. But have you ever had that experience where a facilitator tried to fix things too quickly or like kind of take over their retro meeting?

Stuntz: Yeah, definitely. I think  you and I have had a few retros where that's happened. But I think a retro is a great place to bring these problems to light, and the goal of a retro is not to have a time where someone's trying to explain why they made a decision, or someone's trying to come up with a solution for fixing those problems.

It's really a place to brainstorm what those issues are and to try to prioritize any of those issues that you want to work on  at a later date. So one way that we do that at headway is that  we make sure that we list action items as we go during the retro. So while we're retroing and having the meeting, we'll actually have a running list of action items that we want to work on in the future  and that kind of lets you be like, hey, I know you've got an explanation for this and I know you've got backstory for why we do this, but let's stick that in an action item and we can pick up that discussion later, and really lets you make sure that everyone that's involved in the retro can have their voices heard. Cause at the end of the day you want everyone's opinion. You want everyone talking and you want everyone talking with one another to try to better understand how to make the system worked for everyone on the team.

Jon: And I think another danger of that situation and we've seen this happen from time to time at headway is that you schedule an hour, perhaps an hour and a half and if we don't stick to the right schedule and we don't give the team the right time to have the meeting be about them and things that they want to surface, and we get too much into fixing of the problem, you're going to run over on your time for the meeting. And then you're going to miss out on some of the really good information that you otherwise would have been able to receive from your team. So I think trying to batch that,  fixing any of the issues that are coming out of the feedback is a really good tip.

 What are a few other ways that retros get off track that you've seen? What are some of the dangers that people should watch out for?

Stuntz: One that I think is very common across development teams is the no problems, retro. Which is a retro where everyone feels like they can't share the things that are going wrong. And so it looks like from the outside that there's zero issues. And this is frustrating because even if you kind of, push people into talking or sharing more, it's hard to get people to start talking about those issues. And what I've seen personally is that teams that have the no problems retro, are actually the teams that have the most frustration around working on that development team. And once you can get people talking, then all of a sudden it's like a minefield of things that people want to talk about and problems that they want to fix.

So I see this as, kind of a systemic issue, driven from usually managers being too involved and managers having any sort of backlash against people talking about issues. So in my example earlier where we had that stakeholder that didn't really want to hear that there were problems,  he's the kind of person that should not be in a retro because there are problems and it's okay that there are problems and we want to talk about those problems. Yet he would argue the opposite and want there to be no problems and so just having his presence in that meeting would cause everyone to be quiet and to not want to surface any problems and therefore not come up with any good solutions.

  I think there's some other issues that I've seen in retros.  One of them that I see on occasion is oversharing. So retros are certainly a place to be emotional and to have feelings, but  they are also professional meetings and we're here as professionals, so it's important that we don't get too personal there's no attacking of people. There's no personal conflicts that are coming out of that. If those are issues that are coming up in retros, I strongly encourage those people to have a face to face meeting or move that conversation someplace else, or facilitate some other, conflict solution meeting.   And the last thing that I've seen happen on occasion, is having, a facilitator that has too much control over a retro. And this really just drives towards making sure that everyone is heard on the team. So if you have  a facilitator, that's only interested in talking about, a certain subset of problems or, problems that would only address like one part of the process.

You can have issues with people feeling like they aren't heard, or even if they are heard that there's nothing that comes out of the retro. So they think the retros worthless. We definitely don't want that. Cause if your manager thinks that a retros worthless , and you think our retros worthless, then you're never going to do a retro and nothing's ever going to change.

  Jon: Yeah, definitely three good things watch out for in retro meetings as you're ticking these off or refining your retro process. 

As I mentioned, you wrote recently, a blog post for the headway blog called level up your development team with better agile retrospectives. And in that post, you provided a template for retro meetings that we use at headway.

One of the problems that you just mentioned or places that retros go wrong is that it's hard sometimes to get people talking and, to avoid those no problems type retros, we have an intro section in our template that kind of helps get people in the right mindset. Would you talk to me a little bit about that template and how you came to have that in your bag of tricks and, and what that intro section helps do.

Stuntz: Yeah, I definitely want to give a shout out to my friend, Amy Marco, who was the inspiration for a lot of my desire to do and research retros and make them better.  She was the encouragement for this question, and we ask for a feel color, at most of our retros, which sounds ridiculous. Especially as a developer who kind of lives in the technical world and I kind of consider myself like a backend developer and don't like colors.

 So...

   Jon: Has anyone ever given a hex number?

Stuntz: Oh, yes, absolutely . Yeah. So we ask for a feel color and the idea is to force you out of the developer or engineer mindset so that you're not just always coming up with solutions that you're connecting with your emotions a little bit, and that you're able to communicate those things and it really just sets up the conversation to be a little bit more playful, a little bit more emotional, a little bit less, everything went wrong and we need to fix it all because we're all developers and engineers and we want everything to go perfectly. Some other things that have been suggested for that lighter question is too ask about weekend plans. Really just have any sort of, question that encourages conversation that's not just about development, or any other icebreaker topics that can get the room talking.

 Jon: I really enjoy trying to come up with the feel color in our retros and people always kind of giggle and and figure out the different combinations of color names that try to perhaps  explain their feelings for  that particular retro. And I don't know if this is something that you all did in the past or that Amy would recommend, but we usually go through and briefly explain the color so that people aren't maybe assuming what a color would mean to them. So it's really just a kind of a kickoff, even to that explanation . Just to get in the right frame of mind to share that and open up. 

So, what are some of the other sections in this template, doc, which we will make available both on the blog post and in the show notes for people to check out what are some of the other sections that we have  outlined in that template?

Stuntz: So we always start with, the feel color. Some of the other sections that are included are kind of the three main things  that you should get out of any retro, and we label those as things that made you sad, which , if you're looking at the retro from the agile manifesto, it's,  what could have gone better? And then we had things that make us happy. So those are things that did go really well in this project. And then we always have action items and those action items are the most important part of it. And they're the part that allows you to have all of these issues that are coming up and you're brainstorming   and it's what sets you up to change those for the next sprint? So the action items are where we collaborate and include as many action items as they want to, and then we will discuss them at the end and usually we try to assign them to specific folks so that we can bring those action items back up. And then when you have a retro again, you can discuss what those action items were and what the changes were and see if it helped anything or changed anything. So the action items is really how the sprint and the teamwork becomes more agile like, so it's, how you set up for the changes that you're hoping to implement during the next sprint.

Jon: Yeah. So that's the meat of that template, doc, the meat of the meeting, that's the things that made you happy things that made you sad. And then of course, those action items, similarly to how we kick off the meeting with a way to kind of open up yourself for, for being a little bit, ready to share. We also have a nice conclusion  section in the template doc too, that's one of my favorite sections. Do you want to talk about that a little bit?

Stuntz: Yeah, definitely. So we always include appreciations in our retros, and this is a place where you can personally give a shout out to someone that you thought did a really great job on that sprint. And I've seen this go in a couple of ways. Oftentimes if there's like an individual that maybe messed something up or was having a hard sprint or something like that, you can like appreciate them for leveling themselves up during the sprint and it's a great place to let someone know that, or it's a great place to let people know that you appreciate that they like, uh, did, uh, an outstanding job and. I often see that happen when teams are working really well together and you get just lots of appreciation for everyone because everyone's working together and that's always a good feeling.

And then the last thing in our conclusion, we always try to rate the retro and you rate the retro based on what you wanted to get out of the retro. So if there was like a specific thing that you wanted to talk about, in the retro, then we identify that at the beginning  and then at the end, if you have talked about it or there's an action item to work on that specific item, you would give the retro  a really, great rating.

  We consider a, ten to be my whole outlook on life has improved. Whereas a one is a complete waste of time and nothing is ever going to change. So usually you land in between a one and a 10 based on what you wanted to get out of the retro. But it's good feedback for the facilitator and for the people involved, so if this was a particularly bad retro, you could go and have a new retro, or maybe switch up the facilitator and work on figuring out ,what was going on.

Jon: Yeah, I like that the ratings is great. It's something we do actually for all of our meetings at headway, because we use  EOS  , the entrepreneurial operating system, and one of the things you do in that system is rate your meetings at the end. And so it's always fun to see what those scores look like and how we can improve.

Sometimes it's almost like a retro of the retro. Right. Which is great. I think one kind of fun pro tip that we could throw in there is if your team is already using something like planning poker, where it reveals the ratings , after everyone has put their scores in, that can be a pretty useful thing to do to rate a meeting so that we don't have an anchor of somebody saying like, oh, it was a nine and then everyone else is like, well, I was thinking of seven, but I don't want to sound pessimistic. So I'll, I'll go an eight like it can kind of influence other people so if you have a tool like that, definitely would recommend using one of those. 

So as we talked about Andrew action items are one of the most important, if not the most important aspect of a retro, it's not just talking about it, although that is cathartic and sometimes is a benefit in and of itself.

One of the really important things is to roll up that feedback to the right people at the right time. And so do you have any recommendations for how to take some of those action items and bubble them upstream in a way that can help influence your next sprint in a positive way?

Stuntz: Like we were talking about earlier, when you have action items that are coming out of a retro and if you've run a retro well, there will definitely be action items. I don't think I've ever been in a retro where we didn't have action items. At the end of our retros, we will always assign  the action items to folks so that they will at least take some time to work on those, and then in the past, in places where I've worked, where there's not as much accountability around those things, we'll set up either like some sort of calendar reminder or an email reminder or something, that just checks in with those folks about those action items, a couple days after the retro, and it just helps them realize like, yes, we want to take action on these things and we want to move forward with them. The other thing that I like about action items is it empowers the team to make their own changes. So if there's action items that come up around a certain process that you're working on and  you assign that to a specific person on the team, then that person is able to work on that making that process better.

Jon: Yeah that makes sense. We use notion for a lot of our meetings and documents , and unfortunately, while they've grown leaps and bounds, since we first started using them surfacing todo's and tagging things for a specific person to do while possible is still a little bit tricky in order to get back to that specific item and have it be actionable for you. And so, one thing we've done in the past in certain circumstances is add them as like a GitHub issue or we use stories on board so we could add a new story card for someone follow up as it pertains to the next sprint.

Just to make sure that those things are adequately captured and followed up on. And like you said, a calendar reminder could work too, but I think having single place for that to be captured for the team so everyone knows what the expectation is there would be definitely a recommendation of ours.

So in your blog post, Andrew, you  talked about some ground rules for retrospective meetings as well. Could you cover some of those ground rules that help everybody feel like they can contribute to the meeting adequately?

Stuntz: I think laying ground rules really helps to frame the conversation and sets people up to think about any sort of conflict that they want to bring up in a retro. I don't want to say, like, it keeps people from bringing up conflict because you want that to be brought up in a retro. This is the space for that.  So it's just important to tee it up with, being respectful is the number one thing. Even if the issues are something more personal,  or like there's a specific person that you're calling out and a retro, which , I don't always encourage,  but in certain situations it could be the right place to do it.

  You just want to be respectful to everyone. There's no reason for personal attacks or, anger or personal frustration or anything like that. And then another ground rule that I like to set is that what's said in a retro stays in the retro. There's no reason that if you, as a team are having issues and you guys are still performing, adequately in, a business setting that anyone else needs to know about the issues that you're having in your team.

Especially if there are other consequences that could happen from that.  The goal is always to work on process. And so whether that process is communicating with another developer over a pull request, or that process is how the project manager is inputting stories into whatever project management tool that they're using. It's best when everyone works on process, cause that leads to issues that are easier to track and allows you to better understand what everyone else is working on and when there's that better understanding then everyone else gets to work together better.

Jon: What do you find Andrew is the right cadence for a retro. Is it something that you should do each week or does it have to coincide with your sprint? What's the best amount of time to pass between retro meetings?

Stuntz: I think to start, if you've never done retros, I would suggest having retros happen at the end of every sprint. In the agile manifesto they recommend doing one every sprint as well. It just kind of goes back to that agile thought process and having feedback and reducing that risk, for every sprint.

That said I've been on teams where things usually go pretty well and things are pretty dialed and the retro happens every other sprint or every third sprint and there's no reason that you shouldn't change that if things are going well.

Jon: There's usually something to work on each sprint.   So it can be celebration of the wins and an encouragement of the team of what went well, but then also probably some minor corrections here or there, or perhaps you're adding a new person to the team and that'd be a good opportunity for them to  get familiar with that cadence and what the right thing is.

One thing we do at headway sometimes for like a six week build to just add some firepower to an existing team  and it's weekly sprints one week of effort, and then we'll do a small sprint plan and then do another week of effort with kind of like a mini demo in there too. And I think sometimes  we've been able to do a bit of a retro with the client, even in the demo meeting itself where things like you said are generally going well, we don't necessarily own 100% of the project from a project management perspective. But we can still suggest a few things that could go better as a part of the demo. And maybe it doesn't have a document per se, and we don't make a big ceremony about it, but we still find it super valuable to work with the client and the other developers and designers that we're partnering with in order to tune and tweak things on a week to week basis so that we can just be more effective in that next week. Would you say that that is helpful , or should folks always try and run things through a more formal process?  What's the balance there? 

Stuntz: I think there can be a balance there, although I'm definitely a proponent of pushing for more process. So to me, if there are documented action items that are coming out of whatever that meeting ends up being, whether it's the, client demo and you guys want to talk about, how the process went over the last week, or it's like , a true, serious retro than I think it all counts on some level and it's, it's always it's always good to be thinking about.

Jon: So something is better than nothing, but a more formal process that can take a step back and really evaluate the sprint is better. What about the situation where for whatever reason you weren't doing retros throughout the project, and now it's over, is it still worth doing a retro at the end of the project or is it too far gone at that point?

Stuntz: No, I think it's always worth doing a retro. And especially if you haven't done one, those feelings can just fester. And I know like personally, even if I don't have a team that does a retro, I will retro projects for myself and just be like, these are the things that I identified personally that I want to work on and this is how I would like to make that happen. But definitely have a retro at the end of each project. It really just lets you finalize that project and talk about the great things. Talk about the, not so great things,  and kind of put that project to bed and let that project, be what it was.

Jon: Good tip, don't skip the end retro. Even if it's a last ditch effort to try and figure out what went well or what went wrong with that project, it's still very useful. And I would say, probably do that retro within three to five business days of the project ending. So things are still fresh. Find the time to sit down with your team and make that be a priority. 

So one sort of technical question about running a retro itself, let's say you're, coming up on the end of your 90 minutes that you blocked on the calendar. Sometimes you can do them in an hour with a smaller team. We've found sometimes they take even upwards of two hours and  there's this kind of situation where it gets to the end of the 90 minutes and we're trying to figure out, do we keep going? There's more to dig into here. Is that okay to continue to extend and that retro? What are your tips for when not everything has been covered and we're running up against the time?

Stuntz: Yeah. Yeah. I think this, is good meeting management period, and I think you should set a time and you should try to stick with it, and you should try to get through all of the parts in the retro within that time. But, there are occasions where it's more important and if you have the time, then certainly do it. But it's more important to have the discussion than to wait to have that discussion. So if everyone's gung ho about the way that the retros running and there's no one, that's going to be frustrated that you're taking the extra 30 minutes to finish the discussion. Certainly finish that discussion because it can lead to even more meaningful action items. It can lead to people feeling better or feeling like they have concluded the sprint better. Yeah, I think it's certainly best to get to the end of the retro, but...

Jon: it's something I think teams need to refine over time. They'll learn how to self manage that time block. And that, hey, we spent 40 minutes on the feel color and the intros and the small talk and it was our first retro and maybe that was okay this time. And maybe we'll go over a little bit, but, then I think the facilitator should recognize that and understand that, you know, Hey, we've got 10 minutes for this intro part here where there's eight people that all want to get heard, and we type things out I guess that would be another good thing just to cover here for the folks that, haven't been able to participate in a formal retro yet, or just to lend some, expertise in how we run those meetings.

We actually don't talk through everything in real time . Do you want to talk about the process there with typing out answers and voting and all of that?

 Stuntz: We've alluded to it a few times, but it's really important that everyone's heard within a retro. Otherwise people can feel even more frustrated than they did before the beginning of the retro. So one thing that we do a lot of at headway is we type out the answers and we use like some sort of collaboration software, whether that's Notion or Google docs and everyone has their name listed and is able to type in few things that went well and a few things that went wrong, as well as keep track of those action items in real time. So what happened is that everyone types in all at the same time, and then as soon as everyone's finished typing, then we all vote on the things that we want to discuss. So usually on like a team of five or something, we'll wait until one has four or five votes on it. And  then we'll pull that down into a discussion and we'll talk about it, but we'll only do that for couple of the issues or the good things that happened in a specific sprint. And then you can bring action items out of that.

 It's also important if there's something that stands out to the facilitator, like, something that went wrong that the facilitator thinks needs to be discussed about those things should get pulled down into the discussion as well. But it allows us to focus on the things that everyone wants to talk about  and not spend time on every little issue that everyone's having. Which it's important to be heard, and that's why we all type it out. But, at the end of the day, there's only so much that you can change in a single sprint.

  Jon: Very true. Well, thanks so much for the discussion, Andrew, is there anything else you want to cover on the retro meeting before we conclude?

Stuntz: I don't think so. Jon, that's pretty in depth on the retro.

Jon: All right. Well, we need a rating for the meeting. Does your whole outlook on life changed?

Stuntz: I'll go with the nine and a half, because I'm hopeful that other people are going to use our retro template. And they feel like it's as life changing to the development process, as I thought it was.

Jon: All right. Well, I'll go with a nine and a half as well since you anchored me to that number. I appreciate it. Andrew,   the blog post again is called level up your development team with better agile retrospectives. You can find it at headway.io/blog. And thanks again, Andrew Stuntz. It was a pleasure having you on the show.

Stuntz: Thanks, Jon.