Most development teams here in Amsterdam and Utrecht (and probably many other places) work with scrum to guide their work week(s) and development cycles. Part of this is the retrospective moment, it’s the last part of the scrum process in which you look back and see what you can improve about your team’s processes. I won’t go into the actual improvements you might think of in these meetings, because different teams have different interpretations and preferences on how to work. I would like to talk about the retrospective, because the process to improve the processes is pretty meta and super important.
A retrospective consists of 3 main questions that need to be answered: what worked well, what could be improved and what will we improve/change the next sprint. It’s seldom the case that everything is going smoothly. Developers almost always see things they might improve or change. For example, this can be inside the team communication, their own personal improvements or the outside pressure they are feeling from managers or other teams. After a retrospective the goal is to make actionable commitments to actually start alleviating some frustrations.
I’ve been in several development teams and I had some interesting retrospectives. I’ve also lead some of these meetings and seen some teams struggle to work together. As a developer or a manger or a stakeholder, might recognise some of issues in your team. Furthermore, I also hope that you might see how to better operate in these meetings. With the goal to make this entire process feel like less of a drag, and motivate your team to actually commit to fixing the fundamental problems in your team. I would like to start with some pitfalls which I have seen to cause trouble and distraction.
Issues
In a retrospective there is usually one person that leads the meeting and guides everyone though the discussion points. Some developers however have stronger opinions than others. And both extremes have the potential to kill a retrospectives potential. Developers with strong opinions might overshadow all other opinions. Enthusiasm is a good thing, but we can get carried away in the improvements we might want to try out. I’ve seen teammates who kept on repeating themselves to get their point implemented. I found it especially annoying that the ideas suggested where purely based on personal experience without the possibility to measurable if the suggested ideas would have a positive outcome. But in the end the team just started to adjust to the bullying and became complacent in fighting for what they thought would be actual good ideas.
Not every developer is the same and besides a bully I also witnessed some quiet team members, who are less obtrusive, but I was curious to find out if we were losing out on their good ideas. Sometimes people have good ideas but are not comfortable voicing them in a strong willed group. As a team we should always try to get all the good ideas on the table and work towards inclusivity. Asking a quiet person to participate and giving them the floor might actually force them to show their potential. But they do need to feel safe in telling you what they actually think. But if you are not able to create a safe space, individual talks become a lot more important to also take their good ideas into consideration.
Discussing stuff in an orderly fashion can be difficult. Some people feel very strongly about their work, and passion is a good thing. However, the team should always be able to ask the question if the effort that has to be put it wouldn’t be greater than the reward. This stage of the discussion is often overlooked. Developers don’t develop for their own efficiency, the business value that they provide is the most valuable thing to the company they work for. But the added business value is hardly ever discussed. When big changes are proposed sometimes it’s better to park and investigate an idea further before continuing a discussion. This so the team can make informed decisions, weighting the pros, cons and the impact of the proposed changes.
Improving processes usually has to be done next to everything else we have to do. So a time constraint is usually set by to actually do these meetings and to implement the changes. I often found that setting a maximum time for these meetings improves the amount of focus the team can maintain. But you might still be faced with team members who hog time in these meetings. To flatten the disparity between members I found that social pressure can help. Meaning that if one takes a long time in retrospective meeting others will not get a chance to speak. Which provides an implicitly social cue if you use the time of your team members. But you could also change the order of who answers the 3 questions so the quiet voices get heard first. These two measures together provide enough social pressure to keep it short and sweet while still giving everyone the opportunity to contribute with their best ideas.
Working towards a common goal
As a team you of course want to hear that everything is running hunky dory and that everyone is happy with how things are going. But getting to this stage usually means that all the noses need to be pointing in the right direction. It might happen that people actually have opposing ideas on how to solve a problem and both are just as valid. You could just opt for democracy, but all the facts should be on the table before a discussion should be reached. We want to avoid referendum in which no one knows what’s being proposed. But in the when a choice is made everyone should be able to get onboard that a majority of the team wants something.
On the topic of leadership, in my opinion the worst thing for a retro meeting is when a team goes off the rails and thinks it’s’ actually self organised and stops caring about the teams deliverables. Maybe developers want to keep refactoring just because they find it interesting, while from a business perspective it does not result in any upside or business value. Every team has a manager and this person should have the right to tell the team what the end result should be. If proposed changes are not in line with the business goals it’s only logical to deny the change. Even though politically this might give some clashes, I think developers should beek in mind who is paying their salaries.
However in the grand scheme change is always difficult, for developers, managers and people outside the team. But the inability to change anything might also frustrate developers enough to just leave. When frustrations run high everyone in the team can either fight for change, or flee. As a manager when this happens it’s good to investigate and actually find out what was going on, preferable giving them the chance to tell you. A retrospective can be a great help in this and a team should get the time to actually investigate proposals and to apply the proposed changes. The changes proposed by the team need to be implemented, preferable not by only one person in the team, to avoid a loss of support for the idea. But if good ideas are not frustrated or delayed and actually get the resources to be implemented the team can come together and run more smoothly.
Results
In the end you could find out that some people are disrupting the team balance, or that the process was broken or that deadlines where way too strict and demotivating developers. It might not be what you wanted to hear, but it’s always better to know what is going on in your development team. If this process is carefully nurtured, by someone who knows what they are doing, it could save you a lot of time and money. It can solidify a good team, help to lay bare a broken one, but it will almost always give you more insight that just staying on your island and not communicating with each other.
Retrospectives can give the actionable process changes and insights that are hard to gather from developers. I’m most definitely a fan of retrospectives, but we all should mindful what role we play and how others might feel in this meeting. Sometimes the hardest conversations can give you insights about yourself and your teammates that will make you come together and face the problems head on. So we can get back to developing (but now more efficiently).
