Get certified - Transform your world of work today


A Retrospective on Our Changing Retrospectives

Changing Scrum retrospectives throughout team transformations

19 June 2017

Marcello Rossi
Altran Italia

In this article, I want to share my experience with Agile retrospectives and my observations about how this type of meeting changes along with the transformations of a team.

My first retrospective

I will always remember my first retrospective. It was a rainy and thundering day during the dawn of my first work experience as a software developer. In a lucky fluke, for which I'll never be grateful enough, I was about to begin my career with an amazing team composed of amazing people who had embraced Agile methods long before my arrival at the company.

Back in the day, I was a new graduate. I had a poor understanding of what the software development world was, and an even poorer understanding of Agile. After a couple of weeks, most Scrum events were pretty clear to me: I had attended sprint planning, several daily stand-up meetings, and a sprint review was scheduled at the end of our one-month sprint. I was learning coding as much as I was learning Agile. There was just one missing piece to the puzzle: Throughout the iteration, my colleagues whispered, "sprint retrospective," and the shadow of this strange and mystical meeting was summoned every time a problem or an unfortunate occurrence happened during the day. The team had faith that this retrospective would address and solve all their problems. I was confused about this meeting yet curious enough to overcome my shyness, so I asked for clarification from the person in charge of my tutoring. However, my colleague refused to explain anything, smirking at me and saying, "You'll see for yourself."

Scrum retrospectives and team transformations

So, my first retrospective happened, and more meetings followed. Through the reiteration of this event, I began to understand the value of communication that Scrum uses it to enforce. Among all Scrum events, it best represents the core of the inspect-and-adapt principle. It occurs at the end of each development cycle, and its purpose is to offer a timebox in which people can "reflect" on the previous iteration and identify what was bad and what was good. Too often people tend to address only the bad during their retrospectives, but I think the best part of the team can emerge both from the inspection of our defects and the nurturing of our strengths. Maximizing the good is as important as minimizing the bad. The only objective of this meeting is to identify actions and implementations to make the team's life easier. How this is achieved is up to the team members.

My team underwent several transformations during its life, with people coming and going, and every change was followed by a consequent change in how our retrospectives worked. As the Scrum Guide states, retrospectives are about inspections of people, relationships, process, and tools, and each of these concepts had a different weight in each of our phases.

The "Magnificent Three"

My first three-member team was strong in communication, and we didn't have any forbidden topic we couldn’t address. We were good about people and relationships. The retrospectives were a moment for sharing frustrations about processes and tools, and we tried to find innovative solutions to our problems. In that context, our retrospectives were creative problem-solving sessions. First, they were to identify an issue the team wanted to work on. After this, there was a divergence moment — an idea generation phase — in which we tried to imagine solutions, piling up all the wild thoughts we could came up with. The purpose of this phase was to generate as many ideas as possible, going for quantity and the freedom from others' (and our own) judgment. Afterward, there was a convergence moment, during which the "best" ideas were chosen, voted on, and aggregated to take the form of our retrospective actions.

We made use of several instruments during these sessions. We frequently implemented the Forced Connections technique, whereby new ideas were generated from the inspirations of random images. Other times we used the Layer of Abstraction technique (similar to the Five-Whys), useful for understanding the hidden causes of a problem. Everything was seasoned with the proper icebreakers and games to release creativity. This kind of retrospective is particularly useful for a team of strongly motivated people who are willing to understand the weak links in their chain of production, and to substitute inefficient procedures with effective solutions.

We didn't always come up with concrete ideas to improve our development cycle; our retrospectives stopped at the identification of a problem. Those confrontations were useful to becoming conscious of our way of working. This is itself a victory, even if it is not accompanied by a specific action.

A dysfunctional new entry into our team

Eventually the context changed and a dysfunctional element joined our team. The newcomer was not used to teamwork, and his "lone-wolf" attitude was behind his refusal to work in the mode the company expected from its employees. The balance of our iterations and the quality of our work were at risk.

When a new member joins a team he can't fully integrate with, it would be superficial to blame only the newcomer. A dysfunctional member makes the whole group dysfunctional. Because a team fails or succeeds only as a whole, all members have to work together to solve the situation. There's no place for "I" or "him" when such a problem arises, and the retrospectives reminded us of that. We put aside processes and tools along with our creative problem-solving sessions, and we focused on relationships. Back then, retrospectives were a means to express our feelings and concerns. We were dedicated to the analysis of the situation, and we offered ways to try to involve and accept the new member in the group.

Unfortunately this instrument did not work that time. Even if our dedication was strong, the new member didn't believe that the issue was solvable. During the retrospectives, this person didn't share his thoughts with us — actually closing up even more. This sad situation went on until he left the company. It was a tough moment for us. We learned an important lesson: Despite the effectiveness of the framework, you can't force a member who does not believe in the principle of the openness of Scrum to work in such a fashion. People who are not willing to fully embrace Scrum should not work in Scrum. I think this is true for individuals as much as for companies. Agile events become only a waste of time, and their true values are defiled. Communication becomes superficial and impersonal, and it is used mainly as a way of hiding a person's true agenda.

Getting better

The team returned to its old configuration, but it had just survived a difficult and challenging situation that left it damaged and wounded. Back then, retrospectives were not about relationships, tools, or processes. They were about people. Moments for licking our wounds. Moments for soul-searching, dedicated to the exploration of our problems and regrets. In those days, I discovered the therapeutic power of a proper mourning. We grew as a group as much as we grew as individuals. The team survived and returned to its former strength, thanks to those moments of inspection.

A stronger team

Slowly the healing process ended and we returned to a situation similar to that of the beginning, until the company decided to move another person to the team. The scars of the last experience were still fresh, but we had confidence in the new member, and we welcomed this person with as much warmth as we did before. Fortunately, this time was different, and the newcomer was willing to blend in with the group, accepting our context as well as bringing new ideas to the table. From the point of view of the retrospectives, our focus was again on people and relationships, and our Post-its were a way to explore each other. In general, all Scrum events were occasions where trust and confidence were built with the newcomer, and, in particular, I think the retrospective was the perfect moment to involve this person in the Agile processes of the new team. I think that, in situations such as these, the inspect-and-adapt purpose is a secondary aspect and the main purpose of this meeting is to help build bridges. For a new team of people willing to work and work well, this is a moment when strong relationships are forged.


I'm very excited about retrospectives and what they represent. I see great value in them and, if I should give advice to any team, I would say, "Reflect, and reflect often on yourselves." It's a common mistake for a team that's undertaking a particularly stressful period to "forget" about retrospectives. This happens when at some levels people think that this event is a waste of time. But I believe that, especially when the situation is difficult, the team must rely on its capacity to inspect itself and the process. There's no other way to seek for excellence except — borrowing a catchphrase from the Lean philosophy — to keep asking oneself, "Why am I doing this?" But there is more than technical excellence here at stake. Cooperation among different people is always difficult, because every problem, internal or external to the workplace, can get in the way during the process of building confidence and trust, and every unexpected event can set the team back into an awful place. I truly think that we have a responsibility, as professionals and as people, to force ourselves to show the best part of ourselves to others. Retrospectives are meant for this.

If you do not want retrospectives, you must ensure that you have a back-up plan, a structured context in which people can express concerns and construct actions to improve their work life. The absence of this can result in latent issues and hidden problems. Teams in this situation are usually not aware of this danger and tend to think everything is good when actually it is not. If you are thinking, "I do have inspection moments, and everything is just fine," you are probably on one of those teams, and you should ask people who work with you whether they are really satisfied with the status quo.

From the experiences I have shared in this article, I learned that retrospectives change with time. They express the particular needs of a team in a specific period. For this reason, I suggest changing often the way this meeting is organized and to experiment with new tools to adapt to the transformations of the group. For example, in my last retrospective, I introduced a moment of reflection on the Agile Manifesto's 12 principles, asking the team to imagine a way to improve their development cycle while focusing on a principle of their choosing. I found this approach particularly helpful, and it gave the team a way to shift the focus onto the aspect that needed the most attention in that moment.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 5 (5 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up