I’m passionate about understanding what makes software engineering teams great, and applying and sharing that understanding however I can. And of the many different ways I’ve seen software built over the years, I’m convinced that Agile and Scrum – if they are applied well – combine to form a highly successful approach to building software. To that end, I have several posts about different aspects of Agile and Scrum, based on my own experience over the years. Here’s one of them.
Scrum.org says, “the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.” In my experience, this is the method that has worked most effectively:
- Review the outcomes of the previous Retro. Were all follow-up tasks completed? If not, why not? If so, did they have the desired effect? Why or why not? Is there something that should be done differently or in addition to the actions already taken? Is this course of action worth pursuing (at the expense of one or the other of the new work items that could come out of this Retro)? If so, then this becomes the scope of this Retro (and not what is presented below). If not, then document as necessary and move on.
For Retros to be effective, there must be follow-up to ensure they are actually having an effect. If a Retro is nothing more than “shouting into the wind,” then steps need to be taken to address this. This breakdown in the core purpose of the Retro (for that matter, any Retro-related breakdown) must be addressed first, because an effective Retro is the mechanism by which other things change. If the mechanism itself is broken, then it is unreasonable to expect change to occur effectively.
I’ve been a part of a lot of Retros that did not do this effectively. They didn’t revisit what was brought up before. This, more than any other mistake, is what feeds the “nothing ever changes here” mentality. If you don’t accomplish anything, then a Retro is nothing more than a gripe session. And if you do accomplish what you set out to change – when you begin your Retro by checking something off the list – then you’re kicking off a crucial meeting with a collective dopamine hit. What could be better than that?
- Through whatever means by which the team has agreed upon, you propose, discuss, debate, and vote upon candidate topics. There are a ton of apps out there for doing this. I prefer not to use the “What Went Well? / What Didn’t Go Well? / What Can Be Improved?” style (see this example). I would rather push the “What Went Well?” part of the discussion to a parking lot. It’s technically unnecessary, and having it after the meeting is officially over makes it more voluntary and less forced. And “What Didn’t Go Well? / What Can Be Improved?” are two sides of the same coin. But it’s a popular approach, and I’m not opposed to doing it that way. The important aspect for me – however you do it – is to ultimately arrive at a consensus on two items:
- An action that the team can take to improve its situation.
- An issue that cannot be addressed by the team itself, but should be brought to the attention of management.
Like all things in Agile and Scrum, prioritization is key. With effective prioritization, the team can make the trade-offs and other decisions necessary to accomplish its goals. So by prioritizing the one thing the team can change and the one thing it needs from management, the team can make the most effective use of this Retro. All lower priorities can wait until the next Retro. As long as the pattern is followed, all reasonably important items will be addressed in due time.
In my experience, this is greatly helped by every member of the team thinking about this ahead of time (and perhaps even logging their thoughts in some kind of shared document ahead of time as well). Sometimes, the roots of one or both items are obvious even before the meeting begins. But even then, identifying the problem is only part of it. You also need to figure out, as a team, what you’re going to do about it. If everyone puts some thought into this ahead of time, then you’re coming into the meeting with options to discuss and debate.
- Set the expectation for the one action to take. Ideally, it becomes a work item to be added to the next Sprint. As with all work items, there should be a clear indication of when the item is done. If its scope appears to extend beyond a Sprint, then identify what smaller portion of it can be done within the Sprint, and ensure that an appropriate follow-up for the remainder of the work is included in the Acceptance Criteria.
This one item does not need to be tackled by the whole team. It is often a work item assigned to just one person. There’s often one or two team members who are especially passionate about whatever the issue might be. Let them run with it. The important part is that it has been decided by the team as a whole that this is the highest priority action that can be taken by the team. It is not decided by one or two individuals, and definitely not by management.
I’ve often had these work items start out as great big plans. For example, one was to rebuild a shared development environment because the current one had deteriorated to a critical state. The scope that was eventually decided upon was to simply identify the steps necessary to make that happen. The Acceptance Criteria of that work item was something along the lines of, “There is a plan.” So by the next Retro, we had an idea of what it would actually take to rebuild the environment, and we could prioritize those steps against the rest of our work and predict when we might have that environment available.
- Ensure that the team’s representative to management has a clear understanding of the message to take to them. Have the representative state it to the team in their own words. Ideally, the team should be able to raise sensitive concerns this way, so it is especially important that they are communicated clearly. Bear in mind that even the choice of what to communicate is itself a form of communication. It says, “We care about this issue more than all others right now.”
The team’s expectation should be only that its concern is heard, not that a particular action is taken. It is up to management to decide how to respond, perhaps to take immediate action, provide a more detailed explanation of future plans, or even simply to acknowledge that the concern has been heard without any more context.
When I was that representative, there was a time or two in which our VP of Engineering heard our concern, acknowledged its validity, and chose not to take action. He had his reasons, and he did share some of his reasoning at times. But because his position made him privy to information that could not or should not be shared with us, we had to trust his decisions. But trust isn’t a feature to be bolted on at some arbitrary point. It’s an essential aspect to a team’s success, and he’d earned that trust over time (just like we had earned his). So he could say “No” and that was that.
- Once these objectives are accomplished, then the Retro is complete. This is regardless of the amount of time taken to complete them. While other Sprint ceremonies should be more strictly time-boxed, the role of the Retro in the overall health of the team and its productivity demands that it be given whatever time is needed.
Good meeting discipline is as important as it is rare. Start meetings on time. Have an agenda. Post that agenda ahead of time. Close the meeting once the objective is accomplished. Do not go over the limit. The Sprint Retro is the “exception that makes the rule.” As I said earlier, if this mechanism is broken, then change doesn’t happen. So, within reason, if the Retro goes over, let it go over.
I was on a team that scheduled 30-minute Retros. We were going through a rough patch, and we went over that limit once or twice. Very quickly, we adjusted the schedule to make them 60-minute meetings so that we would not go over. And then, over time, as we got things under control, we lowered that back down to 30 minutes. I’m happy to say that we even got to the point at which there were a handful of times that we met and decided that there was nothing to improve. We were happy with how things were going. We still found things to complain about, of course, but we decided as a team that none of them were worth tweaking the process, and that it was best to leave it alone.
I miss that team.