TLDR:
The retro should be the first activity that day. It should happen first thing in the morning. The ideal is that individuals are coming to the retrospective fresh.
After everyone finishes writing cards, we will have a 30 minute break. This is to accommodate anyone who prefers to read all of the cards before grouping.
Maybe the Team Lead needs some time after the retro and before Sprint Planning to reflect on the discussions that came up in the retro. This is a good time for team members to sharpen their axe.
Maybe. . . just maybe . . . this is also a good time for any of the developers to come to the TL and let her or him know if they no longer want to be part of the team.
At the very end of the day, do Sprint Planning.
I've been thinking a LOT over the past few days about what makes a good retrospective, as a result of my previous blog post.
And today I was trying to figure out my ideal retro "schedule" (for lack of better terminology). Here it is:
I think that the ideal is to have Sprint Demos shortly before the Sprint Retrospective. Because Sprint Demos often highlight issues that should be discussed in the retro. So it is vital to have Sprint Demos before the Sprint Retrospective. I am thinking that ideally, the sprint demo is at the very end of the workday (bear with me, this will make sense in a second).
The reason I want the Sprint Demos at the end of the day (might actually adjust this opinion in a second) is because I really want to have the Sprint Retrospective FIRST thing the following morning. The reason that having the retro first thing in the morning is so important to me is because I really want the team coming to the retro fresh. I don't want to get them after they are already tired from working a crazy morning or putting out fires or when they are hitting their afternoon lull.
(However, now I'm thinking that maybe it'd be better to do the Sprint Demos earlier in the day the day before, in case we find a small error--that way there is time to fix it before the end of the sprint! I'll think more about the Sprint Demo later - maybe a separate blogpost. ANYWAY.)
Then I am thinking, I will begin the retro, and go through the steps (as I described in my previous blogpost). And I think that after everyone has finished writing their cards, I want to give everyone a 30 minute break. This break would happen after everyone has finished writing cards and before we begin grouping cards.
The reason for this break is: in many retros I have attended, it seemed to me as though a not-insignificant number of people struggled with the grouping step, and I think it's because they would prefer to read all of the cards before they start grouping. This doesn't have to be everyone's approach to grouping, BUT it is an approach I would like to support if I were Team Lead.
So this 30 minute break will allow anyone who wants to read all of the cards before grouping to do exactly that. For anyone who does not feel the need to read through everything before grouping, they are free to go make a cup of tea, chit-chat with a colleague, grab a snack, do some yoga, take a nap, take their dog outside, run some errands, have a snack, meditate, take a walk, whatever. Ideally, I'd like them to use that break in a way that allows them to bring their best self to the second half of the retro. I would discourage them from doing sprint work during this 30 minute break (I am actually thinking it might be best to "close" the sprint before the retro - that is definitely something I'd like to try if I were a Team Lead.) At my current workplace, we use JIRA, and closing a sprint without immediately starting a new sprint is definitely an option!
After the 30 minute break, we will go ahead with grouping, voting, and the main discussion. And all the other steps I mentioned in my previous blogpost. And then, lunchtime!!!! Everyone go relax!!! You have all worked very hard this morning! Retrospectives can be emotionally draining - I think it would be relatively silly to expect people to be productive immediately following a retro. They are humans! Not robots!
After lunch, I think that I, as the Team Lead in this scenario, would want some time to reflect on the discussions that came up in the retro. And if there was not too much to reflect on (maybe none of the feedback was news to me that week), I would use this time to begin addressing any actions that came out of the retro. For example, if everyone on the team had agreed that we really needed to have a flow chart in order to better understand the architecture of part of the code, I could start creating that flow chart. But most likely I think I'd spend ~2 hours reflecting on the discussion points that came up in the retro and the resulting discussions. Another thing I'd like to do--and I'm almost afraid to share this because I think this will be waaay too "radical" for some of you out there and you will write me off as an idiot--is tell the team members, at the end of the retro, that if they are no longer happy as a member of this team, this afternoon is a good time to come and talk to me about switching teams. The thinking behind this is that, I don't want anyone on the team who does not want to be there. And looking at it from the opposite view, I want everyone on the team to consciously choose to be part of the next sprint. I don't want anyone staying because they feel trapped (this is how I feel about romantic relationships as well!) While I (the TL) spend the first portion of the afternoon reflecting and also managing anyone who would like to leave the team (calm down, calm down, this isn't the logistical nightmare you think it is - they can join a new team immediately, we are all on the same sprint cycle. If no team has the bandwidth for a new joiner in the next sprint, what's wrong with them remaining a sort of "free agent" and working on tech debt or tech improvements until they can join a different team? ANYWAY, back to what I was saying.) While I, as the TL, spend the first few hours after lunch reflecting, I would encourage my team to spend that time "sharpening their axe" i.e. improving their software development skills. Most managers and TLs I've observed really do not give enough time for this - and all that does is result in unhappy developers who spend their spare time interviewing, looking for a place where they will have more time for learning. And often end up quitting. And. AND. We won't have kicked off the next sprint yet at this point, so there will be no sprint work for them to do (and the previous sprint will have been closed before the retrospective in my ideal world). THEN. Finally, at the very end of the day, maybe 1 hour before the workday is over, we will have Sprint Planning. It is vital that Sprint Planning happen after the retrospective, because often the retrospective will influence how Sprint Planning is approached or what work gets pulled into the next sprint. If Sprint Planning ends early, then I will say EVERYONE GO HOME! No more work for today, thank you all so much for your participation and hard work, I really really appreciate it.
There are my ideas! That's all of them! I'd love to hear what others think about this proposal!
Comments