The retrospective: continuous improvement reviewed by it-economics

“The Retrospective is like sending off a mini New Year celebration…, you are seeing the old one out with all sorts of rituals and you always start the new one hopefully with some old and some new promises” (Veselka Zdravkova, Senior Software Developer).

We asked 10 programmers in it-economics to explain in one word what Scrum Retrospective means for them. What would make it more attractive for them, what do they like about it, and what they don’t like or find less productive? We found that this Scrum event is mostly associated with positive connotation words, even though the prevailing perception is that programmers hate Retrospective. In our short research, we came across associations such as Improvement, Constructivism, Candor, Analysis, Equilibrium, and Review.

As a result, we were able to summarize lessons learned and form them as rules (we don’t claim that they are golden) for a successful Retrospective. However, these rules are certainly a good reality check and serve to accept Retros as they are. Our rules are without claim to comprehensiveness. We are sharing this based on our experience in the field, and we hope that it will be useful to the agile community.

Off-topic for a better start:

The beginning of each Retro is what sets the tone for the entire meeting that follows. “When the meeting starts with a smile, people accept/give criticism more easily because they free themselves from the seriousness of the fact that the Retro is after all a work meeting.” (Ivan Ruzhev, Lead software developer).

Whether everyone will keep an eye on the time until the meeting’s over, will be totally bored out, or will participate actively and willingly is very often encoded in the opening part of the meeting. “It’s the relaxing conversations by the coffee machine before every meeting” (Kevin Koenig, Developer). As such, it is also a good idea not to extend the meetings too much, so that the focus of the Retreat is not lost, and that there will be enough time left for discussion. Undoubtedly, however, at the beginning of the Retro meeting, we want to create the kind of conditions that will encourage each team member to be frank/honest.

Variety is welcome, lack of focus leads to a loss of interest:

Variety is welcome, “uniformity is what kills the creativity of the team” (Ivan Ruzhev, Lead software developer). Participating every second week in a uniform and monotonous Retro meeting, where you are asked the same questions, where the same words on the same board distributed in the same visual layout are standing, is disastrous for the effectiveness of this Scrum event.

Even the same concept presented through a variety of formats can yield different ideas and different perspectives on a problem. Getting away from the expected and predictable in the Retro sparks more desire to participate. Having the opportunity to get away for a moment from the day-to-day work or from a bug you have been struggling with for three days is an additional bonus. Also using this time to think in a different direction or even have some fun. However, no matter what format we use, it’s important to remain constructive.

Precisely because the goal in almost 100% of cases is the same: improvement – to find the team’s weak spots, to optimize in order to ensure more efficient and productive teamwork. Losing focus on that goal and getting distracted is not a good practice. Topic concentration and quality discussion of a problem are important as they will help us understand how and what we can move forward and what the team specifically wants.

“It’s nice that in our team we take 2 or 3 things and implement them, rather than take 100 and do nothing” (Christoph Dietert, Solution Architect). Making progress in implementing two, or three things in the foreseeable future is much more achievable and gets much more approval from the team, than deriving 100 action steps and trying to implement them all at once (even if they all undoubtedly bring positives).

A minute is too much:

“I don’t like it when time limits are too strict. Sometimes I feel like I’m looking more at the time left on the timer than thinking about the issue. In the end, you can’t add something that comes additionally on your mind because the time is up” (Maria Popova, Expert Software Developer).

Anyone who has attended a Scrum Retrospective may know that often the timer runs the meeting, not the team. There are many prescriptions for how long a Retro оr every single part of it should last, how long it should last, so it can be effective. Actually, it’s quite subjective and depends on how big the team is, how aligned the team members are with each other, and what are their needs. There is a variation where, for small teams in very dynamic projects, even 30 minutes of Retro would suffice for the purpose of the event. Although such a short time for this kind of meeting is not appreciated.

It is important to remember that the Retro is first and foremost a Balance. A review of what we have achieved and what we still want to achieve.

In this sense, the Retro can get a better overall evaluation if we regularly monitor the progress and take the formed steps to completion, so that in the end some added value for the team is obtained. This does not always happen. But even if it doesn’t happen, the effectiveness of the Retro method also comes from keeping the information open and accessible to everyone, reviewing the tasks we’ve set relatively frequently, and concluding together about the best way to bring them to completion, even if it’s not the most optimal way.

Feedback in some way is also a form of stock-taking and review. No matter if it refers to the Retro or to yourself, how happy you are with what you achieved/invested in the meeting/sprint, how you felt, where you heard etc. This is an essential part of the Retro that is not good to be missing on a regular basis. Everyone is checking their own clock here, it’s another way to openly say what you think and to give a sign if something isn’t going as you think it should. This is often where thoughts and ideas for follow-up meetings and improvements come up, which is valuable for both the Scrum Master and the team.

One person does not make the Retro but you can’t do a Retro without them

Speaking of reflections and ideas for improvement, we must say that the Retro has the character of an analysis, and in one analysis all points of view are relevant and must be taken into account.

Many teams have a bad experience with the Retro because not all team members take part in the meeting for a number of reasons. Whether it’s because they don’t find it useful, they don’t think it takes effect on them, they don’t find the time, and so on. From experience, it can be concluded that every team member is important, and it is advisable to participate in the Retro meeting. Each team member has a voice and an opinion, and it should be heard and shared. This of course does not mean that everyone has to be competent in everything and contribute ideas everywhere.

“I didn’t like the obligation for everyone to give ideas on every topic. It is better for everyone to give the ideas they have, no matter what topic they are on” (Teodora Hristeva, Senior Application Maintenance Developer). However, it is recommended that everyone feels more authoritative and confident in their position in the team, and this happens when their opinion is solicited, even if they only have to say “Yes, I agree/I think so too”. Disregarding in any context does not lead to cohesion and better teamwork and systematic domination by only one person who is speaking over or for everyone else would lead to discrediting the Retro.

“In my day-to-day work, communication with my colleagues is constantly two-way, allowing us to share ideas, and quickly adapt our work. This constant evolution can be good for resolving issues and adjusting processes, but it can also lead to leaving team members out of the loop or allowing poor decisions to gain momentum. That’s why I like to use Retrospectives to find points of contact with colleagues on workflow issues and solutions to common tasks.”(Valentin Genev, Advanced Software Developer)

Retrospective as a method itself, even outside of Scrum, is something that brings many positives when the prerequisites for its successful implementation are met. it-economics strives to incorporate this approach in its internal structure as well, for problem-solving, process improvement and getting feedback among employees. Something that certainly improves Retro’s good image in our company is the clear formation of specific problem themes, systematized goals, and clear steps that we will take in the next sprint or in a foreseeable time to make the working environment and atmosphere better for the team.

In conclusion, we can say that continuous improvement of the individual team and the company is far from being a utopia, but a matter of desire and effort based on good methods and practices, such as Retrospective, and their effective implementation. Continuous improvement is part of our culture and always finds a place in project work. You can take a look at our projects and open positions here.