Improving how you work is a common goal for many organizations. With agile teams, this is usually done through retrospectives.
In other words, with agile retrospectives, you can focus on how your work is going and take things that are learned from success & failure for further implementation.
Such agile retrospectives help to improve processes, methods, and teamwork.
Getting started is not that difficult. Here’s how you should go on as a project manager…
What are Agile Retrospectives?
The agile retrospective comes from the 12th principle in the agile manifesto which states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.“
The agile retrospective, therefore, is a structured meeting adopted by teams to help them reflect on the way they are working and to participate in continuous improvement.
The agile methodology runs on iterations, where the idea is to split the development of the software into sequences of repeated cycles.
In other words, the agile iteration runs for a short period where teams take their customers’ most important user stories and build them as running-tested-software. Everything should happen within an iteration, from analysis to testing.
In a retrospective, the tea, discuss how the iteration went, and decide what they want to change or how they want to adapt their processes to allow for continuous improvement.
Whatever actions are agreed upon in the retrospective are followed in the next iteration. Thus, retrospectives are an effective way to do the short cycled improvement.
Reasons for Holding/ Conducting Agile Retrospectives
The purpose of retrospectives is to enable change. They provide a platform to identify where your team can work more efficiently and allows for continuous improvement to be implemented.
“We need to uncover better ways to improve and retrospectives can provide the solution.” – Ben Linders, Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises
Every project teaches you something about yourself, your product, and your team. However, holding retrospectives allows you to incorporate these lessons that you’ve learned and applied them to the project you are working on.
1. You create an Environment of Trust and Transparency
Holding a planned retrospective meeting that is executed properly allows you to provide a platform for your team.
This platform serves as a space where your team can highlight successes but also identify areas that need improvement.
By providing this transparency and being open about how the project went, you can create an environment of trust where your team knows that they can easily highlight concerns. They will also be aware that achievements will be appreciated and acknowledged.
2. Aid your Team to Learn and Develop
Team development is essential to ensure that your team continuously improves.
As a team leader or a project manager, you should aim to help your team improve, with every project that they work on.
There are multiple ways you can achieve this, one such way is through holding retrospective meetings.
3. Provide Team Building
Another reason for holding retrospective meetings is that it serves as a team-building platform.
The nature of retrospectives providing the opportunity to share praise and feedback makes it great for team building.
By discussing successes the team fulfilled and giving feedback and looking for a solution for problems faced, your team will work together thus improving both collaboration and communication. This will also boost team spirit and energy levels.
Check this out:
Best Agile Tools for Project Management
Who Should Attend Agile Retrospective Meetings?
As the retrospective meeting is a time when reflection is done on the way the process is running, you need to ensure that the entire team attends.
This includes the team members, the team coach (or Scrum master), and the product owner (or a functional project manager, depending on how the team is organized).
Collectively, all the members mentioned have a diverse set of perspectives. It is this diversity in perspective that will allow you retrospective meetings to identify process improvements that need to be done, from multiple different points of view.
Let’s go over each member in turn to explain their role in retrospective meetings and why their presence is important.
1. Team Members
Everyone who is part of the team and working on the product or service should be part of the retrospective meeting.
Namely, everyone who is designing, building, or testing the service or product should attend the meeting.
Not only does their attendance give them a chance to appreciate their work and acknowledge successes, but it also ensures that there is an open platform where any critical issues can be discussed.
Ensuring that each member is present will give the full picture of the way work is progressing rather than missing out on important contributions that someone who is not in attendance would have brought up.
The retrospective is a place to deal with problems, concerns, and issues and provides a safe place to address these.
2. Team Coach (or Scrum Master)
A team coach or scrum master is the facilitator of the team. He/she is responsible for supporting the team by helping them understand the theory, practices, rules, and values behind the work they are doing.
A team coach can help the team point out possible improvements and good practices that can be implemented in the next iteration.
Since the retrospective is a joint team event, having a team coach present that has a repertoire of formats to support this endeavor.
Therefore, the team coach or scrum master must attend both because she/he is an integral part of the process but also because she/he is the process coach for the team and can identify where the team is not adhering to its own decision and agreed-upon process.
Moreover, the team coach is also a valuable source of knowledge and ideas for the team to better the next iteration and collaborate effectively to get to the end product or service successfully.
3. Product Owner
The product owner on the other hand is the leader of the team who is responsible for maximizing the value of the products or services created and delivered by the team.
There is some debate that the product owner should not attend the retrospective meeting.
This debate is because some people feel that having the product owner present in the meeting will hinder the team from being completely open and honest. This inhibition may result in the team not being able to reveal difficult issues that they have faced in the iteration.
Although this may be a problem in certain organizations, the product owner is still an integral part of the process and ideally should be part of the retrospective meetings.
If, however, the presence of the product owner will hinder the open discussion, this is a problem that needs to be addressed and solved quickly.
Perhaps, the team coach could attend a few retrospectives without the product owner so that he or she can help the team create that trusting environment so that in later iterations the product owner can be present.
Provided that there is reasonable trust in place, a product owner is critical to accomplishing the quick and flexible flow of business value. Therefore, the product owner’s presence in retrospectives is important.
Apart from the three entities mentioned above, you may also want stakeholders to attend your retrospective meeting.
However, the attendance of stakeholders is not normally necessary. In fact, having stakeholders present may hinder the open and honest discussion by the team of how the iteration went.
Remember, candor and honesty are essential in a retrospective. Without them, the retrospective will be unable to bring about the change that can help your team’s process with continuous improvement.
Related:
Types of Scrum Meetings and Scrum Best Practices
Is There a Way of Organizing Retrospectives?
As a matter of fact, there’s a lot more to Agile retrospectives – or any type of retrospectives than what meets the eye.
Typical retrospective meetings take up to around three hours to be concluded. However, the length of your retrospective is dependent on the length of the iteration that is being reviewed.
Basic retrospective meetings can be divided into 5 effective phases.
These phases include:
1. Provide an environment conducive to open and honest discussion:
When the team meets for the retrospective you should aim to avoid distraction and everyone should agree to participate in an honest and open discussion about the iteration that just passed.
Ensure that each person is treated with respect, given the opportunity to be heard, and create a culture of trust so that this discussion can take place.
2. Identify which issues need to be discussed:
Knowing what needs to be discussed before the retrospective makes the way the meeting progresses more organized and ensures everything that is of the issue is covered.
You need to identify what issues are being faced so that they are addressed and do not carry forward to the next iteration.
3. Gain insight
Each participant in the meeting should delve into the issues that were faced during the iteration and have a deep discussion to get to the solution or the root cause of the problem.
What were the causes? What specific steps can be taken by the team to improve them in the next iteration?
4. Reach decisions
As a team, try to decide on one to two improvements that should be carried on to the next iteration and be implemented for continuous improvement.
5. Conclusion
After you and your team reach a decision in phase 4, it is time to conclude the retrospective. The team members will begin with their work for the new iteration and try to implement the improvements that were discussed.
Formats for Holding Retrospectives
Depending on the size of your team, the culture of your organization, and what you are working on there are different formats you can adopt for your retrospective.
Here are a few examples to get you on your way.
1. Happy, Confused, Sad Retrospective
This is a common retrospective format. This format does not require a lot of planning up-front.
In this format, the members of your team will discuss the progress and team’s context in terms of being happy, sad, or confused about it.
The team coach in this format only needs to ensure that the discussion is productive.
You can ask questions such as:
- What was everyone happy about this iteration?
- Were there any things that made anyone sad this iteration?
- Is there something that the team is doing that you are confused about?
2. Sailboat Retrospective
The sailboat retrospective format allows your team to analyze the work they are doing with respect to your broader goal.
You use a sailboat metaphor and consider what is propelling the team forward towards the goal.
In this metaphor, the team is represented by a boat and the goal is an island. The wind in this metaphor represents what is propelling the team towards the goal. An anchor is representative of issues that are slowing or dragging the team down. Finally, rocks represent risks to the project.
The way the team coach uses this format is up to them and what they are looking to achieve.
There are many other formats to run your retrospective, you can also come up with your own formats. Remember to keep the focus on continuous improvement and making sure that everyone is part of the input.
It is always a good idea to experiment with different things and see what works best for your team.
Conclusion
There you have it! everything you need to know about running and organizing spick n’ span agile retrospectives for your teams.
We hope this guide helps in getting your team to improve their processes to get a positive outcome in the most efficient way possible.
Good luck with your upcoming retrospective meeting. Don’t forget to share your thoughts in the comments section below!
Recommended Readings:
