A “Positive” Retrospective

One of the Agile principles states that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” These “meetings” are more likely called Retrospectives and can be held in many different formats (here are some examples https://trello.com/b/40BwQg57/retrospective-techniques-for-coaches-scrum-masters-and-oth er-facilitators and http://retrospectivewiki.org/index.php?title=Retrospective_Plans)​. The most famous is the “Mad, Sad, Glad” format, and many others are just variations of this very basic format.

Read on for the “positive retrospective” format and exercises.

Click to learn more about how you can help your PO

These formats are based on the aim to analyze the previous team’s activities in order to achieve better results. Sometimes, it may also help to analyze the successes of the team in order to understand what helped in achieving them and how to replicate such successes: that’s what I call a “Positive Retrospective”.

The period we may wish to analyze may vary; last iteration, last month, last year and so on. What do we need to organize this retrospective? The usual materials such as some stickers, pens and a whiteboard or a flipchart.

The first action to take is to create a collaborative and positive atmosphere, so ask the attendees to write down some few words of appreciation for a colleague (or more), thanking him/her for something he/she did during the given period, for the person or for the team. Give the team 5 minutes to write.

Then ask each attendee to read aloud what they wrote, speaking to the colleague they want to thank. This phase shouldn’t take more than 5-10 minutes.

The next phase is to list all the positive results achieved in the period.

Ask the attendees to write down on the stickers all the positive results achieved, using a short statement (one per sticker) – they will be given the opportunity to explain in the next phase. Give them 5 minutes to write.

Now ask the attendees to explain the individual positive issues, one by one. They should be concise in their description but still be able to let the other attendees understand the issue. Then the sticker is pinned to the whiteboard. If any other attendee has a similar issue, he/she has to discard it. Please be careful to avoid starting any discussion. This is the time to list the results and not to discuss them (moreover, the discussion will be shaped in a particular way, as we will see in the following stage).

Once everybody has explained their issues (this stage should last no more than 10 minutes), you’ll have all the stickers on the whiteboard. It’s time to vote.

Each attendee will have six votes to give to the issues stuck on the whiteboard: three votes to vote the issues by its intrinsic or technical value (for example, the team reduced the technical debts by 50%, or has stabilized the daily standup) and three votes to vote the issues by the positive impact it had on the product (for example, thanks to this new feature, the customer increased his sales by 20%). You can use any means to vote: in my example, we used little red self-adhesive dots for one and green for the other, but you can use different signs, different colored pens, and so on.

Why differentiate this way? The answer is easy: teams tend to identify their success with the product’s success; we delivered this feature, the customer were happy, we eliminate that bug and so on, forgetting that with success stories, many other aspects must ​ be considered. For example, adopt a more effective framework for the chosen programming language, start unit testing, practice a scrum ceremony in a more efficient way and so on. The team must learn these positive issues as well, as they allow the team to be more effective ​ (as per the above mentioned Agile principle).

Once the voting is finished, just rank the issues by the numbers of votes (any kind).Voting and ranking shouldn’t take more than 5 minutes.

Once the stickers are rearranged on the whiteboard (the most voted ones are on top) you can start to discuss. The format may be free (you can discuss any issue as long as you want), or fixed (an issue can be discussed for a maximum amount of time of 5 or 8 minutes, for example). Choose the format you like, what counts is the discussion itself.

Ok, let’s discuss, but about what? We usually discuss what’s going wrong, and how to fix it. Now, here instead, we’re discussing what went right! Well, we can first identify what made that positive issue possible. Usually, we can identify two main paths: one internal to the team, and one external. The internal one refers to all the actions the team takes to achieve a result, which may impact the team, the process or the product. For example, by autonomously adopting a new programming framework the team was able to deliver those given features and the customer was very happy. Note the ​ word “autonomously”: the team was not forced by any external entity to take that decision, but reached a result that had an external impact anyway.

The external path refers to all those actions taken or conditions set up by the system (your department, your local agency, your company, and so on) that made it possible to achieve that given result. For example, the team was able to learn how to deal with noSQL databases thanks to a dedicated budget for training on new and emerging

technologies/methodologies. In this case, an external reason made it possible to achieve an internal positive result. Nevertheless, we mean to say that an internal result will sooner or later reflect itself into an external positive result (or at least, this is what the system hopes…).

The discussion stage may last up to 50 minutes, to keep the whole retrospective no longer than 2 hours.

And now, just like any Retrospective worthy its name, let’s write down some action points.

Like any positive issue in any field, we aim to replicate it and also do something to improve that experience to feel even better. So we can define the underlying actions that will lead us to even better results. Some questions easily come to mind: can we replicate the positives we had during the period, applying them to current or new issues? For example, we may ask for a new course to learn a new language to create a new software asked by our customers. Or, can we improve the path that led us to have positive results to have better results or even the same results but in different areas? For example, improve the continuous integration process to have a faster/safer deployment of our deliverables.

Or just have more frequent retrospectives to improve our work!

Discussing and writing the Action Points may take up to 20 minutes.

Now the meeting may be closed. See you next Retrospective!

About Enrico Di Cesare

Always interested in improving the quality of the software produced for himself or for his customers, Enrico became an Agile enthusiast as soon as he discovered it. With extensive previous experience as a Project Manager and Coordinator, Enrico works as an Agile Coach, Scrum Master and Product Owner, introducing, mastering, facilitating and refining the adoption of Agile with new collaborative tools.

Alex Fürstenau explains how retrospectives can help teams get out of the “us vs them” anti-pattern

When a team faces a problem they have a choice between blaming someone else (“them”), or taking ownership and making it happen even if that improvement looks beyond their reach. We as Scrum Masters can help teams take ownership, even when they need to involve other people in the resolution of the problem. Alex explains the problem, and some of the possible techniques to get the team to understand that they own the results of their work.

About Alex Fürstenau

Alex Fusternau scrum master toolbox podcast(1)When he was 12, his father bought him his first computer, a C64. The moment he saw characters appearing on the television was the moment when he knew he would do something with computers. Several years and a computer science study later that “dream” became true.
Alex quickly realized that the customers were not happy with our product. The first approach was to fix more of the requirements but it made things worse. During that time (around 2002) he thought “There has to be a better way” and he found several, among which was Agile.

You can link with Alex Füsternau on Linkedin, or connect with Alex Füsternau on Twitter. Alex also facilitates a regular meetup in Hamburg on the topic of Liberating Structures, for more on the meetup visit their meetup page.

Alex Fürstenau reminds us that Retrospectives need energy

Often we disregard this very simple fact, by the end of the sprint people are tired. Hosting the retrospective at the end of the day, on the last day of the sprint is not ideal from the engagement and energy level point of view. Alex explains how he failed at keeping the energy level high in one retrospective and what he learned from that moment, that he still applies today.

About Alex Fürstenau

Alex Fusternau scrum master toolbox podcast(1)When he was 12, his father bought him his first computer, a C64. The moment he saw characters appearing on the television was the moment when he knew he would do something with computers. Several years and a computer science study later that “dream” became true.
Alex quickly realized that the customers were not happy with our product. The first approach was to fix more of the requirements but it made things worse. During that time (around 2002) he thought “There has to be a better way” and he found several, among which was Agile.

You can link with Alex Füsternau on Linkedin, or connect with Alex Füsternau on Twitter. Alex also facilitates a regular meetup in Hamburg on the topic of Liberating Structures, for more on the meetup visit their meetup page.

Zuzi Sochova on the “we’re already good” anti-pattern

Many teams get stuck in a bad place, but there are some teams that also get stuck, but because they think they already are “good enough”. Listen in to learn how Zuzi learned to work with teams that already think they are “good enough”.

About Zuzi Sochova

Zuzi help companies and individuals to be more successful. She teaches teams and their managers how to be more efficient, how to provide better quality and how to communicate and organize teams so that people have fun, they are motivated and have high commitment. Zuzi helps teams and managers find out how to handle customer relationship to help them improve customer satisfaction.
You can visit Zuzi’s website at: http://sochova.cz/, and link with Zuzi Sochova on LinkedIn, or connect with Zuzi Sochova on twitter, or your favorite conferece.

Sven Schnee on the importance of retrospectives for Scrum Masters to evaluate their work

Retrospectives are a key part of any Scrum team’s process. However, they are also key for Scrum Masters to evaluate their performance. Sven shares with us a process he uses to help him detect possible problems, and invest in solving the right problems to help the team, and himself succeed. We discuss plenty of practical advice regarding the structure and the content of Retrospectives.

About Sven Schnee

Sven started his journey as a developer around the year 2000. He experienced many projects and felt the pain of how traditional approaches to software development failed.
A few years ago he discovered Agile and Lean, and he is not going back.
He is an Agile Coach and Founder of Oikosofy. He wants to bring agile ways of working to a variety of customers from small companies to big enterprises. One of his key strengths is helping teams evolve on their path to self-organization.
You can connect with Sven Schnee on twitter, and link with Sven Schnee on LinkedIn.
You can read Sven Schnee’s blog The Product Owner Toolbox.

Get The Booklet!
How to deliver on time and eliminate scope creep By scoping projects around outcomes and impacts, not requirements!
Get the Product Owner Booklet!
Avoid scope creep! And learn to scope projects around impacts and outcomes, not requirements!
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Internal Conference
Checklist
Internal Conference
Checklist
Download a detailed How-To to help measure success for your team
Motivate your team with the right metrics, and the right way to visualize and track them. Marcus presents a detailed How-To document based on his experience at The Bungsu Hospital
Download a detailed How-To to help measure success for your team
Read about Visualization and TRANSFORM The way your team works
A moving story of how work at the Bungsu Hospital was transformed by a simple tool that you can use to help your team.
Read about Visualization and TRANSFORM The way your team works
NEW! FREE Product Owner Mini-Summit
Join us for this new Mini-Summit featuring seven pre-recorded sessions handpicked from our most popular past events.
NEW! FREE Product Owner Mini-Summit
Join us for this new Mini-Summit featuring seven pre-recorded sessions handpicked from our most popular past events.
Overcome Team Resistance and Gain Leadership Buy-In
Discover practical, real-world solutions from leading Agile practitioners. Download three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
Overcome Team Resistance and Gain Leadership Buy-In
Discover practical, real-world solutions from leading Agile practitioners. Access three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!