In this post we want to give you an idea on how to do a retrospective at the end of your project.
Hold on, wait, in a previous blog (see Garden Retrospective) you told us that in an Agile team you do a retrospective every sprint (two weeks). Why would you do a retrospective at the end of a project? Well mainly because in a sprint-retrospective you want to focus on the previous and coming sprints. With a project retrospective you want to have a larger view and see which improvements can be made for future projects. For example if you keep your stories in jira, it’s mostly hard to switch to a different software during the project, but in the project retrospective you can see if you want to change for a next project.
Having a context for your retrospective makes it more fun and interactive. So if you don’t know the history of the St. Rumbolds Cathedral you read it below. I’ve kept it very short and brief, but it will help you understand the retrospective format. And also I confess I like history :-)
Around 1200 the construction of the St. Rumbold’s Cathedral started. Between 1452 and 1520, the tower was built, financed by pilgrims and later by its proprietor, the City. The Tower was designed to reach 600 Mechlinian feet or about 167 meters. This is higher than any church tower would ever reach (Ulm Minster measures 161 meters since the 19th century). But the tower never got finished and only reached a height of 97,28 meters. For a very long time people thought the tower was never finished because the very heavy tower was built on land that once had been wetlands. However, even with foundations of only three meters deep the site appears to have been well-chosen. In the 1970’s a student calculated that it is technically feasible to build the final part of the tower.
Here is the true reason why it wasn’t completed: in the early 16th century the upper part of the tower was abandoned, not for technical but for financial reasons. St-Rumbold’s should have been topped by a 77-metre spire (to reach the 167 meters) but only the first seven meters were actually built.
As is common in many cities, also the inhabitants from Mechelen have their nickname. In this case they earned their nickname (or rather ‘sobriquet’) thanks to the St.Rumbolds Cathedral. The Mechlinians are said to have had ancestors running up their great Tower and passing on buckets of water to extinguish a blazing fire behind the windows, where it turned out to be mere dancing rays of moonlight through the clouds, hence they are called Maneblussers (Moon Extinguishers).
Everybody writes down a location and gives a rating. If possible you can give a small clarification about the location. The location can be linked with the project, but it’s no requirement.
If you want a nice Cathedral, draw it before the participants enter the room.
The tower represents the results of our work; elements which we are proud of or which we have achieved. This is focused on the product that is running in production and how we got there. For example: We have a code coverage of > 90%.
The unfinished spire’s focus is on everything we, or our stakeholders wanted but did not accomplish, this can be either functional or technical, … For example: a piece of functionality that wasn’t in the release or a technical improvement that couldn’t be implemented.
The wetlands: our swampy foundations. While the spire focusses on items we didn’t finish, the wetlands focus on what we did finish but can be improved. This can be anything that can make our tower (application) stagger: we have a nice tower and we don’t want a Tower of Pisa. For example: We are using an old version of java or an outdated framework or technology. Perhaps the architecture is not sound because we experienced pressure to deliver or because a lack of knowledgde.
The moon, the reason why they are called the Moon Extinguishers. Here we list all the items where we spent too much time or money for the achieved result. Here we want items which we spent way too much time and money on. For example: Making a piece of code too generic, or implementing a functionality which is rarely used.
Ask the participants to share their ideas on a post-it and place them on the drawing in the following sequence:
What did we learn during this project and what do we want to:
As a facilitator it’s always nice to get feedback on the retro format as well. The retro’s closing lends itself perfectly to this end. Here we end with a trivago review, and ask to give a 5-star rating:
In the last couple of blogs (see The Garden Retro and this one) we have been talking about SMART actions. What makes an action SMART? We have covered this in a previous blog. So next time we will blog about how to facilitate a retrospective, because a good idea and SMART actions are not enough.
Let us know what you think about this retrospective concept. If you tried it out, tell us how it went. If you’ve got other helpful tips/hints or great retrospective concepts, share it with the world.