The Retrospective Ceremony can be one of the most effective activities you can use in an Agile Project. The Concept of Retrospectives is not new to Project Management. “Lessons Learnt” and “Post-Mortems” are also Retrospectives Ceremonies and are typically held at the end of a Project.

Retrospective Ceremony Types

The Sprint Retrospective is held at the end of every Sprint. It occurs after the Sprint Review Meeting. The Release Retrospective occurs after a Release. A Sprint Retrospective will include all of the Scrum Development Team. The Scrum Product Owner should also be invited to the ceremonies. The Release Retrospective should involve everyone who played a part in the Release.

A Retrospective Ceremony needs to revisit all the Events in a Sprint or Release. Do not skimp on the time needed for the meeting. Set aside a minimum of an hour for a Meeting to discuss a Sprint. A Release Meeting should be double that, or even half a day, depending on the scale of the Project.

You are looking to build new efficiencies for your next Sprint or Release. The Retrospective Ceremony is the best way to identify and implement these efficiencies. As everyone becomes more familiar and comfortable with the Meeting, the time taken should also shorten. The outputs from the meetings should also improve. To maximise the effectiveness of the Meeting, circulate an agenda. Any additional information that should be absorbed before the Meeting should also be distributed. This should happen three to five days beforehand. This encourages the Team to apply their minds in advance to any noteworthy wins and challenges experienced.

Retrospective Fundamentals: the Four Questions

There are 4 concerns that can be explored within any Retrospective:-.

• What Did We Do Well?
• What Should We Do Differently Next Time?
• Did We Learn Anything?
• Does Anything Still Puzzle Us?

You will notice that first of all, these are pretty comprehensive questions for reviewing the Work under discussion. Secondly, the questions are all framed positively.

There are many Opportunities for playing the “Blame Game” in Retrospectives. One of the easiest methods to avoid this is by using positive language. There will always be mistakes and circumstances that were not dealt with efficiently. The point of the Meeting is to understand why they took place and how to prevent them going forward. The outputs from this meeting can be considered for inclusion within the following Sprint Planning meeting.

While these questions in themselves are basic, getting the desired responses is a lot more intricate. If you are Facilitating the Meeting, you should ensure that everybody has an Opportunity to contribute.

Retrospective Ceremony: What Went Well?

It is important to start on a high and congratulate each other on Work well Done. It is likewise necessary to Record it, so that the success and the way it was acquired is not forgotten. You need to recognize if the success was due to a fortunate break, or because it was executed really well.

What Should We Do Differently Next Time?

This is a more tactful way of saying “What failed?”. It is geared towards getting frank conversation and feedback on problems that occurred. The phrasing also suggests that we require a solution or mitigation. This can then be applied if the situation occurs again. Answers to this concern should be neutral.

What Did We Learn?

This is where each Team member applies some introspection to how they Work. Perhaps one of the Team rushes into coding right away, rather of evaluating and understanding the user story. They may have discovered that this leads to Rework or a longer testing cycle. This is likewise an Opportunity for Team members to share experiences.

What Still Puzzles Us?

This question uncovers possible Risks and knowledge gaps in an non-threatening way. Framing the issue as a concern invites the rest of the Team to respond and concur that they have a comparable challenge. The problem could be a gap in Product knowledge, or not comprehending what Benefits the Project as a whole will bring to the Company.

We found these books great for finding out more information on Agile Scrum:

Retrospective Fundamentals: Deciding on Changes.

Until the Four Questions have been addressed, there ought to be no effort to come up with solutions and Changes:-.

• It will not be possible to apply every Change for every point raised in the next Sprint or Release, so, just as with the Product Backlog, the points raised ought to be prioritized and agreed by the Team.
• This is an Opportunity to share your results with the rest of the Company, from other Teams on the Project (if it is a large Project). The other Teams might be experiencing comparable issues and can embrace your Changes immediately. The Stakeholders would have been aware that things that did not go so well, and their confidence levels in the Project will improve when they see feedback on how these issues will not occur in the future.

Making the Retrospective Ceremony a Happy Place.

Tools and techniques can be used to engage the Scrum Team members (Agile Scrum Master, Scrum Product Owner and Scrum Development Team) and make them keen to get involved. You can gamify your Retrospectives; they are long Meetings and you want to create some fun. What is essential is that everyone in the Meeting feels valued and not threatened.