Agile Retrospectives have been used as a great tool to improve teams and organizations over the past years. An Agile Retrospective is a meeting that ́s held at the end of each iteration in Agile Development and it serves for the team to reflect on how to become more effective, so they can tune and adjusts its behavior accordingly.
WHAT IS AN AGILE RETROSPECTIVE
An Agile Retrospective is a meeting that ́s held at the end of each iteration in Agile Development.
We can use one of the Agile Principles to define Agile Retrospectives:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
The Agile Retrospective is a ritual that belongs to the team: it is indeed a meeting, but it’s a meeting where the team has full ownership of the agenda and the outcome, nobody dumps anything on them.
It’s an event where teams stop and analyze their way of working. The Agile Retrospective is a perfect opportunity that allows the team to stop and reflect upon their way of working.
It is very common, during the retrospective, to find ways to become more efficient. It’s an opportunity to look back and think about how the team performed.
Ideally, Agile Retrospectives are events where issues are discussed without blame or accusation; this means that criticism is given to the working output and not to the people.
Agile Retrospectives are a cornerstone of any inspect and adapt cycle; even though teams should not limit their learning to Agile Retrospectives.
I like to remind people that retrospectives are also a great place to analyze the current working environment and engage in some team-building activities that usually would not take place outside of this meeting.
Retrospectives are a crucial part of a team´s work. Management has sometimes difficulties understanding the importance of retrospectives.
Below you find several reasons why you should use retrospectives.
BUSINESS VALUE OF AGILE RETROSPECTIVES
Sometimes people (usually managers) tell me they have problems understanding why retrospectives have to be held every two weeks and why the whole team stops for a couple of hours just to play with post-its.
Agile Retrospectives are important, and I will explain several reasons why.
Agile Retrospectives as a Team Energizer
A retrospective can often be used as a team energizer: an essential place where the team gets together and gets excited as they find new ways and new possibilities for tackling old problems.
Retrospectives should not be boring at all; this is a perfect place to have some fun and relax a bit while you are working.
Agile Retrospectives are used for people to let go of their frustrations
The Retrospective can be a place where the team feels safe and comfortable, allowing them to talk freely about their frustrations.
This is highly beneficial because, during the retrospective, people have an “official” window of time within which they can be listened to, and any human being loves (and needs) to be listened to.
Agile Retrospectives as a team-building artifact
I use some of my Agile Retrospectives as a team-building activity. Sometimes when working as a team, things get rough, and it’s difficult to set them back on track.
The retrospective is the perfect place to do a couple of team-building activities to bring harmony back to the team.
Agile Retrospectives are the right place to learn and help the team/company to improve
One of the biggest problems that we as human beings have is that we do not stop to reflect (or at least most of us do not). To learn, we must stop and reflect on what has happened.
The Agile Retrospective is the perfect place for this to happen; During the retrospective, everyone stops and reflects on what they did, which in turn allows teams to grow and avoid making the same mistakes in the future.
Agile Retrospectives create continuous improvement
An Agile Retrospective is a ritual that enables teams to create a continuous improvement culture, where they reflect on past experiences and define future actions.
Agile Retrospectives increase customer value
Agile Retrospectives have a positive influence on the value that is delivered to our clients. As I mentioned before, the primary purpose of this ritual is to enable continuous improvement.
This means that teams will get better over time, and as an outcome of this, they will figure out the most efficient way to deliver the best value to their customers.
Agile Retrospectives serve to empower teams
One of the nicest things about retrospectives (in my opinion) is the chance that they give teams to own their decisions. This ritual provides an opportunity to empower teams (not in all cases, but in most).
Teams own their decisions and their actions, creating a fantastic feeling of empowerment.
Agile Retrospectives as a place to honor or grieve past events
Team performance can be profoundly impacted by changes within the groups. Sometimes people leave, other times new people join the team and the dynamics of the team change.
People that are not aware of relationship and systems coaching do not understand what ́s going on, yet sometimes teams cannot recover until they face their new setup.
The retrospective can be used precisely to help the team in this scenario.
Agile Retrospectives as a place to raise positivity within the team
Personally, I do not know many Scrum Masters that use Appreciation exercises in retrospectives. I had already started to use this approach some years ago. I try to start or end an Agile Retrospectives with a round of appreciation.
Many studies have suggested/shown that positivity within the team is directly connected with high performance.
Running Appreciation exercises is a fantastic way to raise positivity within the team, creating an excellent environment where team members will be enabled to contribute to the success of the team.
Agile Retrospective as a tool to communicate with Management
As I mentioned earlier, Agile Retrospectives are the cornerstone of improvement. Unfortunately, many companies think that retrospective meetings belong to the development team and do not utilize their potential.
Agile Retrospectives can be used as a way for teams to articulate their message to management, thereby raising the sense of urgency for problems that need to be addressed in the organization.
If well applied, Agile Retrospectives can be used as a fantastic tool for enabling communication between management and engineers.
A GOOD AGILE RETROSPECTIVES FACILITATOR
Many people might think that retrospectives can be done by anyone in a team and that skills don´t matter. They do! Check out below several characteristics of a good facilitator.
A good Agile Retrospective facilitator should not take any sides.
If the facilitator takes sides, team members might feel attacked and might stop contributing to the whole event. This can break the productivity of the Agile Retrospective.
Be able to choose different exercises for different situations
One of the main reasons why Ben Linders and I wrote the "Getting Value out of Agile Retrospectives" book was to provide people with ideas for Agile Retrospective exercises.
Each retrospective is a different event, yet all of them are unique, and they should tackle a different- the most appropriate- problem.
A good facilitator should be able to identify what issues are troubling the majority of the team during the current sprint and find out what exercises can be used to make sure the team will gain lots of insight from the Agile Retrospective.
Be able to summarise everything that happened during the Agile Retrospective
The closing part of a retrospective is very important. Many times Facilitators do not pay enough attention to this part.
It is very important to support the team in summarising what has been agreed to be tackled during the next iteration. It´s the ideal time to recap what follow-up actions should be taken, by whom and by when.
Create the right environment where everyone is comfortable speaking
Encouraging people to speak up, and making sure that everyone is heard is very important. Another responsibility of the facilitator is to promote everyone to talk and ensure that everyone is heard.
The facilitator should not force anyone to speak if they do not want to. This is a pre-requirement for a successful Agile Retrospective.
However, he should make sure that everyone is heard and that everyone has an opportunity to speak.
Clarify Insights
We are in the software development industry and as we all know most of us to have good technical knowledge and mindset, and because of that we do not have the right touch to elaborate on our ideas.
This is not a bad thing; it´s just a fact. We are good with numbers and algorithms but most of the time not that good with communication. With this in mind, the Facilitator should clarify all insights that people offer.
He should be responsible for making sure that every single insight is understood by everyone in the room. This is the only way that people can understand and analyze the data that will be generated within the Retrospective.
Challenging Insights with lots of questions
The responsibility of the facilitator does not end with insight and subsequent clarification. The facilitator also needs to take the role of a coach and ask many questions.
He must help the team to see different angles and different options.
It´s his responsibility to challenge team members with their insights. Only then is the team able to see different points of view and generate numerous ideas on the topic.
It´s important to underline that it´s not the responsibility of the facilitator to give the answers; this is where the coaching role is important.
He is there to ask questions and help teams to generate as much insight as possible, rather than sticking to the first idea that pops up.
Think positive
One of the prime characteristics of a good facilitator is positivity. This is especially crucial when the facilitator works with a young team.
That does not mean that the moderator will not allow the team to talk about hard topics, but he should aim to keep the environment as constructive and as active as possible.
It´s very important to pay attention to this! Sometimes teams face many problems, and if the coach is not aware of the importance of positivity, the Agile Retrospective can become a complaint session.
Dragging everyone to become very cynical, and in turn, impacting the team´s future performance.
Develop yourself as a Professional Facilitator
Many people think that facilitation is something very simple and easy. To be honest, I have been doing facilitation for several years, and I still feel that I have so much to learn.
If you want to become an exquisite facilitator, then do invest in a Professional Facilitator program.
There are several places where you can get information about the topic, but you can start with the International Association of Facilitators (http://www.iaf-world.org/site/)
SAFE ENVIRONMENT TO RUN AGILE RETROSPECTIVES
One of the important parts of successful Agile Retrospectives is our ability to be able to create a safe environment.
Bringing the Prime Directive to the meeting could help, but there are many other things that can be done to create this safeness. This part was inspired by my original blog post which can be found here.
Keep the Agile Retrospective for the team, not for management
The team members should be the participants of a retrospective. Sometimes it is necessary to call on external people who are not part of the team, but who were involved in sprint activities, and that is OK.
However, I do not advise having management in the Retrospective. I know that in most cases management just wants to help; they have the best intentions, but their presence will cause people to shut down and not talk about the real problems.
So as a rule of thumb, I recommend having only people that are part of the team present.
Team members decide what information will go public
It’s very important that a team decides what goes public and what stays in the room. As I explained previously, an Agile Retrospective gives team members the opportunity to ventilate serious issues.
If they feel comfortable, they will talk about all the problems that are bothering them, without thinking regarding consequences, and this is very good. If some of this ventilation goes public, it can be disastrous.
Therefore, people must choose what information can go public and what should not. By default, I prefer to coach the team to use the rule: “Whatever happens in Vegas, Stays in Vegas”, meaning that everything that happens during the Retrospectives will stay there.
Proper feedback training
One of my clients is investing a lot of time and money in providing feedback training to their employees. I can see a significant effect of this training in my clients’ retrospectives.
People are getting better and better at providing specific, tangible feedback without getting into personal attacks.
The same thing happens to people who receive the comments; they now understand that nothing is personal and they have the tools to use the feedback in a positive way.
Encourage but not force participation
Sometimes people are not in the right mood to participate in all of the activities. The facilitator should encourage, but not force, the participation of people in the activities during the Retrospective.
Yes, I know- most of the time these people will have something to say- but maybe they are not ready to say it at that moment. Give them some time, and they will participate in upcoming activities.
The location of the Retrospective is a Key Element
Some years ago I started something completely different. The idea here is to make you aware of the energy of the location where the Retrospective is taking place.
Sometimes developers have very challenging sprints; a lot of things happen during the iteration, and the energy in the room is not that active. In this case, you should consider taking them out from that place to a more positive or neutral environment.
On the other hand, if the sprint was very productive and they are very happy with the outcome, it may be that utilizing this positive energy is the right approach to have a fantastic Retrospective.
In any case, before you have your retrospective session, think about the team energy and decide if it’s better to stay inside, or to choose some other place to perform the Retrospective.
Not only the environment for running successful agile retrospectives is crucial, but also certain pre-requirements should be in place. Below you can read some tips on what to talk about before retrospectives.
PRE-REQUIREMENTS FOR AGILE RETROSPECTIVES
To run successful Agile Retrospectives, there are several factors that need to be present. Norman L. Kerth refers in his book to: “Project Retrospectives”, five important ideas that should be present, in order to have a successful retrospective: “The need for the ritual”, “Naming the process”, “Prime directive for a retrospective”, “The darker side of the Retrospectives”, and the “Facilitator”.
This part was inspired by the original blog post that can be found here.
The need for ritual
Usually, humans do not stop to reflect on any project; this is not a natural activity, and that’s why it´s so important to formalize a behavior and make it a ritual.
Rituals are important because they serve to bring people together, allowing them to focus on what is important, and to acknowledge significant events or accomplishments.
Naming the process
In our industry, retrospectives have a different name. Some of the names were: “post-mortem”, “post- part”, “post-engagement redress”, etc.
In Agile software development, this process is called “Agile Retrospective”- nowadays this is a familiar name. In my opinion, it is important to call the process in a clear way so as to have everyone’s understanding.
Usually, a team knows what is meant by the process, but it is not uncommon to have top management who do not understand the meaning. “Retrospective” is a straightforward and self-explanatory word.
The prime directive for a retrospective
People must feel comfortable sharing their problems, opinions, or concerns. It is common to realize that things were not performed in the best possible way.
When this happens, people must feel comfortable enough to say things out loud and suggest different ways approach the same problem.
Before starting a retrospective, we should communicate a prime directive:
Regardless of what we discover, we must understand and truly believe that everyone does the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.
I used this idea several times, and I can guarantee that it works; only write the Prime Directive on a flip chart and carry it to your Agile Retrospective.
If someone’s behavior is not aligned with the Prime Directive, just remind that person about the directive.
The darker side of retrospectives
I have had opportunities to see several retrospectives being transformed in complaint sessions. It is quite common when a retrospective is not well facilitated.
It is important to understand the reasons that people complain, and this can reveal a lot of problems, but if a complaint session gets out of control, it can ruin the overall retrospective.
People do not do this with bad intentions. They simply exteriorize what is affecting them: they have some needs that are not being fulfilled, and they need to symbolize their emotions.
The problem is the fact that a receiver is put off by the complaint and immediately enters into defensive mode, attacking back. This can result in a not- productive retrospective.
If all retrospectives end this way, people start to see retrospectives as useless, and they will stop attending them. One technique that I use is to request that people express themselves in the form of “wishes”, rather than accusations.
This changes the tone, creating a “safe” environment, and as it was explained above, having a safe environment is one of the most important things for a successful retrospective.
The retrospective facilitator
All of the previous topics are critical, yet if we do not have a good facilitator, a retrospective most likely will be a disaster.
To become a good Facilitator, experience, training, and a lot of self-reflection are required. Before starting a retrospective, the facilitator should have a clear idea of what he or she wants to get out of that session.
Above you can read about the topic "Facilitator".
To run an excellent retrospective, you should follow five stages. See those below.
THE FIVE STAGES OF AN AGILE RETROSPECTIVE
Some years ago Esther Derby and Diana Larsen, in their book “Agile Retrospectives”, explained to us that there are five different phases during an Agile Retrospective.
1. Set the Stage
If you want people to be engaged and willing to work with you, it's a good idea to take a moment to thank them for investing their time in the retrospective, as doing so will make them feel like valued contributors.
Having done so, make the purpose of the retrospective clear, and outline the goal for the session. You should also give a timeframe for the meeting.
After the basics have been laid out, it's imperative to have everyone in the room speak up. It only needs to be brief (a word or two from each person describing what he or she hopes to get out of the retrospective), but it's important to break the ice in this manner.
Most people automatically “tune out” mentally when they feel they are about to be subjected to an aimless, dull meeting- so keeping a sense of space is integral to a productive group session.
Post the existing working agreement (if there is one) and adjust it as needed so that it effectively applies to the retrospective. If there is no working agreement, draw one up before the retrospective goes any further.
These should have fewer than five points — any more than this is too complicated to be practical.
2. Gather Data
Iterations, while often brief, are packed with important events and interactions;
Data, in such instances, is needed to create a clear shared picture of what has occurred. Data should cover events (this can be anything suitably meaningful to the team.
Decision points, changes in group membership, milestones, celebrations, and implementing new technologies). Metrics (burn-down charts, velocity, defect counts, etc.), and any features or stories the team has completed.
Calendars, documents, charts, and so on should be used by the team to enhance this data further.
Data should be reported during retrospectives using a mix of verbal reporting and visual aids such as task boards and charts; if you're going far back in time, a timeline will also be useful.
Without well-planned visual aids, people often cannot detect relevant patterns and make other connections efficiently.
3. Generate Ideas
Data is useless without interpretation and insight; as such, every retrospective should contain a stage where people ask candid questions, where they point out what they see going wrong—and going right—and ask, “Why?”
As part of doing so, one should examine the various situations that arose in the prior iteration, breaking down the interactions that occurred within them and looking for patterns of either functionality or dysfunctionality.
The team should assess risks and factors in unexpected events and outcomes. This should take the form of a measured, logical approach; remember that people tend to leap to any and all available solutions once a problem is presented, and the first solution posited is often not the best one.
The insight-generation stage is crucial as it allows the team to see how both circumstance and their actions and behaviors affect their ability to develop software. Without this stage, there can be no establishing of cause and effect.
4. Decide what to do
Once the team has agreed on a handful of the best possible solutions, they need to settle on just one or two of them to utilize in the coming iteration and decide on how best to do so.
The Decision Stage should involve the use of story cards or backlog items during the planning process, as this will make it easier to implement improvement plans during the actual work that will occur in the next iteration.
Remember that the retrospective should segue naturally into iteration planning, so try to hold retrospectives just before said period (having the retrospective in the morning and iteration planning in the afternoon is ideal).
5. Closing
Try to close retrospectives in a proactive, inspiring, and motivating way—the team will need this sense of momentum to take into the coming iteration.
People should walk away with a clear idea of what is necessary, how is documented, and what the follow-up will be.
The team should also leave with a host of reminders that will help them remember what they have learned during the retrospective; otherwise, at least some of it will slip away.
These are great tips on how to run retrospectives smoothly, but it´s also great to be aware of what should not be done and what can go wrong. Below you can read about agile retrospectives' anti-patterns and solutions to them.
AGILE RETROSPECTIVES ANTI-PATTERNS
There are several things that you should watch out for during retrospectives; these may also happen to you.
What Happens In Retrospectives, Does Not Stay In The Retrospectives
I saw this anti-pattern quite often. In a company that I worked for in the past, management requested to record agile retrospectives. This part was inspired by the original blog post that can be found here.
The management expected that if the retrospectives were recorded, other teams would be able to learn by observing the problems of their peers.
Nobody was open to speaking about their problems if the retrospectives are registered. They knew that anyone in the organization could listen to those sessions, and therefore no one touched on “severe” problems.
Solution
Only team members should participate in the meeting; to tackle the issue of sharing learning from Retrospectives, action items can be displayed in public places. However, I would keep detailed notes just within the team.
If the organization is serious about knowledge sharing, it can support communities of practice. It is a much better approach to knowledge sharing than forcing people to share the outcomes of Retrospectives with the rest of the organization.
Change the world
The team commits to an ambitious list of actions without considering whether it has time to get them done in the next iteration. This leads to disappointment because the actions do not get done and the team continues to add more actions to the list in every retrospective.
Solution
The answer is not complicated at all. I believe the right thing to do is to only address one topic at a time from your retrospectives.
Select a topic, but perform a proper analysis of it. Thoroughly understand the root cause is the problem at hand (you can use techniques such as the “5 Why´s”) and implement the change during the next iteration.
No Time To Improve
The team takes five to ten minutes after their iteration demo to have a quick chat about how things have been going and calls that an Agile retrospective.
This is a sign that the team sees no benefit to Agile retrospectives. If individuals do have ideas for improvement, they face a struggle to implement them in the absence of a forum for enlisting the support of the team.
Solution
The role of the Scrum Master is very important. If the team does not see the value of agile retrospectives, maybe the coach should organize a workshop with the team to explain how and why agile retrospectives are very important.
But remember to stick to what I mentioned in the previous anti-pattern: change one thing at a time. Coach the team to choose one single topic, understand the problem, and implement it.
Let the team see the improvement and use this momentum to reinforce the idea of how important the Agile retrospectives are.
No Responsibility is Taken
The team spends the Agile retrospective grumbling about how bad things are without taking responsibility for improving the situation.
Retrospectives are about making changes for the better, and that cannot happen without a discussion of what the team can do.
Solution
In this situation, I like to transfer the responsibility to the team. Let them speak, but at some point ask a simple question: “What are you going to do about the situation?”
This is usually a very powerful question. It sends a clear message to the team: if they do not do anything, then nothing will change. They will be trapped in their daily frustration and crappy environment.
Usually, they wake up and try to define some actions to correct the problem, but many teams end up saying: “We cannot do anything, it´s out of our control.”
Do not fall into this trap! There is always something the team can do to improve the situation. Be imaginative, and help the team to find their ways to solve the problem, but do not allow the Agile retrospective to become a complaint session.
Wishful Thinking
Actions discussed are rather vague and with no appointed owners, so for example, “improve communication” or, “do more refactoring”. These are not actions; they are problems to work on.
Without more discussion, the team does not know what to do to implement these ‘pseudo actions’.
Solution
Arrange action items in a way that they can be determined as ‘done’ or ‘not done. ‘Refactor more’ is not a helpful task because one cannot only identify whether it has been completed or not.
‘Improve the User Model’s Code Climate grade from an F to a D’ is actionable, and therefore the team should take small steps that are achievable and contribute towards improvement.
No Review Of Past Action Items
A common mistake is when teams do not check if what they decided to implement did improve their situation.
Teams define topics for improvement for the next sprint, but very few teams stop and analyse whether their actions resulted in some improvement.
Solution
Each retrospective should start with the team reviewing the past action items. The Scrum Master should guide the team and check if the previous items have been carried out.
Each team should come up with Success Criteria to attach to each improvement topic that emerges from each Agile retrospective. If teams use something like this, it is very easy to check in during the next Agile Retrospective if the item was able to solve the problem.
Action Items Are Automatically Assigned To The ScrumMaster
It is quite common, in that most of the teams see the Scrum Master as the person to whom all the topics should be assigned. But in reality, the Scrum Master might not be the best person to solve the problem.
Solution
Usually, the topics that emerge from the retrospectives vary a great deal. Depending on the topic that arises, different team members should take responsibility for tackling the problem.
If the Scrum Master takes ownership of everything, the result is a team that fully depends on the Scrum Master to solve all issues.
The best approach could be to choose different people within the team to tackle the different topics that come up in the retrospectives.
I believe these are the most common anti-patterns you might experience. When you follow my tips, you will get better Agile retrospective results in time.
AGILE RETROSPECTIVES IDEAS
To run a fantastic Agile Retrospective, the facilitator must be able to pick up the most suitable activity for the specific Agile Retrospective.
In order to help you, I collected several exercises in this post: "Agile Retrospectives Exercises", if you prefer videos, you can access our youtube "Agile Exercises Playlist".
In Summary
An Agile Retrospective is an event that ́s held at the end of each iteration in Agile Development and it serves for the team to reflect on how to become more effective, so they can tune and adjusts its behavior accordingly.
I believe this practice is mandatory for every team that is serious about continuously improving the way how they work.
