Time to Improve Retrospective
Our team has agreed on this statement a year ago. In this article, I want to share how we improved our Retrospective and how it helped our team to be better. You will read about useful Retrospective techniques and real-life examples from the Scrum of our team.
Why Retrospective so important?
Because Retrospective is the best time and place to improve your team. Indeed, the retrospective is not about the number of Story Points completed, KPI reached, or bugs are fixed. It is about healthy team collaboration.
One of the most important indicators of team quality is the team’s capacity for self-reflection. Reflection, not an easy thing, it requires the participation and enthusiasm of each team member. When a Retrospective composed of the right components — the team can collect rich feedback from each member and make valuable decisions. In the long term, Retrospective helps the team to adapt, change and growth.
Black mirror
The template of our “previous” Retrospective was copied from the shared folder and used for a long time without any single change. Mostly, slides contained some charts of some numerical results.
The green column is close enough to the blue column. All good, comrade. Keep calm and work hard to make a green column higher. What about the percentages?
Thanks, God, it seems like a green column green enough.
Another one slide is a screenshot of the Remaining Time Estimate chart from JIRA. To be true, I never saw an ideal burn-down chart, more chances to see GitHub unicorn. It is could be a bad sign, but still not a big problem if you are satisfied with the Sprint results.
And finally, the last slide has really matched the idea of Retrospective: Good and bad things that were happened during the Sprint. Time to discuss topics prepared by the facilitator or suggested by someone, for example:
Productive discussion started only at the end of the meeting.
Such a concept of Retrospective bored us. 99% of the presentation was based on every day JIRA slides. We realized, that our Retrospective became just a formal meeting and we need to do something as soon as possible.
Facilitator
Our Retrospective was very depending on the Facilitator. In our case, our Manager always did a Facilitator role and always prepare slides, collect the data and presenting.
When such a dedicated role of “Retrospective presenter” always on the same person, other teammates lose initiative very fast. In such a way, only one person feels the responsibility for the success of Retrospective, but not others.
Not everyone in the team tries to give feedback and without feedback, we don’t know what to improve. — Akrawit Suwansuntisuk
Retro-sickness
We looked into the black mirror and start thinking about how to change your poor Retrospective. Let’s recap the symptoms of Retro-sickness:
- In bad Retrospective DATA on the first place, not PEOPLE
- In bad Retrospective, success depends on ONE PERSON
- Bad Retrospective can go without PEOPLE
As you can see, the keyword — is people. From my point of view, Retrospective should be only focused on people and their collaboration. This meeting provides for people, it is driven by people and aims to help a group of people to become a successful team.
What Would Brian Boitano Do? (c)
Now it is time to talk about solutions. For sure, there is no silver bullet, but I believe that changes that helped us, can also be productive for any other team.
Rotation of Facilitator
To solve “In bad Retrospective, success depends on ONE PERSON”
How to get rid of a “dictator”? Revolution?! Not in Software Development, my friend. Make love, not war. We made a collective agreement to rotate the Facilitator role. If you faced the same “dictator” problem on any process — try rotation.
Rotation is also a perfect tool to get rid of the mystical fog from Retrospective preparations: how to collect the data, aggregate and build the slides. Be aware, Retrospective is not a spontaneous meeting and needs preparation.
Everyone now tries to do the best, while stood in Facilitator’s shoes. This process brought us good results in many directions: leadership skills growth, sharing of knowledge and wrap responsibility.
Agenda
To solve “Bad Retrospective can go without PEOPLE”
Another change was a new Agenda. We revisit how we do Retrospective in terms of how to start, what to do in the middle and how to finalize results. We played with Bootstrap Retrospective Agenda that might be looks like this:
- Opening — focus the team
- Collecting the data — overview data sources
- Going deep — discuss specific data in details
- Decision-making — find solutions
- Closing — feedback on Retrospective
This is our customized Retrospective Agenda with concrete activities on each step:
- Opening — Safety Check, E-S-V-P
- Collecting Sprint data — Happiness Radar, Visualization Board, Sprint Charts
- Going deep — Good and Bad
- Decision-making — Action Items
- Collecting Business data — PO Milestones and KPI
You can see a huge difference with our previous Agenda, that was too much simplified and not effective:
- Collecting Sprint data — Sprint Charts
- Going deep — Good and Bad
Retrospective Techniques
To solve “In bad Retrospective DATA on the first place, not PEOPLE”
This part contains practical methods, that helped us to improve our Retrospective.
I would like to recommend a great web resource (if you don’t know about it yet), where you can find tons of Retrospective techniques to try in your team: funretrospectives.com
We tried a lot of them. Something was failed, something we still use nowadays, something gave us nothing, something was really useful. Choose techniques that fit your team. Do not afraid to try and fail, we all need time and learn to find tools best for us. Do not expect that all of them will works for you, better to experiment and be ready to customize it for your needs.
Safety Check
If you interested to focus your team for Retrospective — ask a simple question before it starts. For example, Safety Check activity helps to prepare all the team. Each member share what he/she feels before the Retro. It could be good input to start on.
We used this activity for a while. After we introduced Happiness Radar (see below), we found Safety Check less effective, so we stopped using it.
Explorer Shopper Vacationer Prisoner
explorer-shopper-vacationer-prisoner
The idea of this activity is to focus teammates for Retrospective. Fill a small survey before the meeting and observe results in the Opening. “ESVP” provides us hints about the atmosphere of the meeting, how your teammates ready to make Retrospective successful.
We combine it together with a Safety Check. Even after we lost interest in a few months, I can recommend it to you. It is a fun thing to play: introduce new roles, use popular movies or comics heroes to express different personal emotions. Roles must not be positive and negative, they should be neutral and different by emotion it keeps. Just gives it a try.
Happiness Radar
This guy is our team heavyweight champion if I can say like that. And yes, I can. Happiness Radar not only covers “Opening” needs to focus the team but also plays the role of a very good data source for the “Collecting the data” part of Retrospective.
Especially good is that data is really personalized and can include many aspects of the team’s and individual value. Add columns that important for your team and go ahead! You can immediately start a discussion and going deep into details using Happiness Radar results.
This is the draft Happiness Radar we found and started with it.
Down below you can see a modified Happiness Radar over time, that finally satisfied our team needs. Happiness Radar replaced both Safety Check and ESVP as the best survey-based activity. I highly recommend you try it.
Simple but powerful. For example, if some person was not satisfied with personal learning and growth (Technology bar) for several Sprints — time to find a challenge for this developer. Let he/she spend more time, even with a loss of fast performance, but will change daily routine to something new to learn and willing to contribute.
Team Collaboration: If an internal code review of PR often delayed and slows down time to market, mention this issue and solve this miscommunication.
Cross-Team Collaboration: If you are impressed by the response from some team “A” (it was so fast and effective) — let’s learn from them and find a way to provide the same fast and effective service for teams, who ask for help from us.
There are many more use-cases that gave us data to discuss and improve our team. This is why, eventually, we stopped on this activity as on a perfect tool for our Retrospective and still using it.
Happiness radar — good for an opening session because we know the main topics that we should focus on and talk about. — Akrawit Suwansuntisuk
Visualization Board
This is a very engaging way to collect data during a Sprint. It is based on an idea to draw a picture that would be in use as a metaphor for team collaboration. There are many variations of it: Speed Car or Speed Boat, Hot-air Balloon, Open the Box and so on.
I found a charming and very simple picture of the ship and we used it. It was a long period, more than half of the year, I guess. This ship helped us, for example, to speed up our daily StandUp meetings. So I can say that this tool is also very useful.
Team’s ship metaphor: team on board and moving to the paradise islands while an anchor of problems pulling us down to sea bottom.
How does Visualization Board work?
Draw the ship or car or whatever you want on the whiteboard. Write down things that slow down your team, things your team dream about and things your team doing to reach those goals. These statements and actions can be related to each other, or it could be totally separated things placed on one board, up to you. Track it over time, once per Sprint on Retrospective you can add new ideas, keep things that still in use, remove obsolete or failed statements. Do not set too many actions, ship have limited capacity! Solve things by small portions.
What we learned of how to use this board: do not mess up the board with KPI of performance numbers or any other overall team expectations. If you want to do StandUp in 10 minutes — this is a good goal to be set here. If you said that you want to have 12 Story Points per Sprint, well, this goal not suited to be placed on the board. The board should contain only concrete activities and do not store “forever” long non-deterministic goals. Put only short terms goals and ideas to improve your Scrum experience and team collaboration, that team will try to achieve in one or two Sprints.
As an example of good and bad activities, I put V (good) and X (bad) on my image. We learned a lot with this tool, having one hand-drawn version on the whiteboard and “digital” version of the same things in a Retrospective slide.
Action Items
Another one thing worth to mention is Action Items. At the end of the Retrospective (part of the Decision-making step), we plan for small personalized action for very specific tasks. Such tasks must have an exact executor and expected to be finished in the next sprint (time-limited).
Action Items bring us the idea that not all work is planned as Stories in Sprint. Something can be delivered as personal input. For example, here our list of Action Items from one of the Retrospectives.
Sometimes there is nothing in the Action Items list, it is possible, why not.
Do it!
Basically, the general idea is to experiment and find out what is working well for your team. Control the status with some visual tracker and improves the process to get better results. If something not works — stop it, replace it, modify it.
After many experiments and many approaches, we keep doing Retrospective stuff, that fits the nature of our team. — Akrawit Suwansuntisuk
Take A Look Around
In this part, I collected a few other improvements that also important to mention.
Different one Burn-down
There is no point to look at the logged time if nothing delivered. This is why we replace the Remaining Time Estimate chart with the Story Points Burn-down chart. It is also simply generated by JIRA chart but shows a much more important output.
Operational
If peace of your team was never disturbed by the users of the product, possibly, no one uses your product. And then you never faced with operational tasks, such as very urgent, hyper important issues, that you immediately should solve. I am kidding, but anyway you got my point. Sometimes unplanned sh*t happened and you spent your time on something “else” instead of something planned, and as a result, commitments are failed or at least delayed.
To control and manage these obstacles of Sprint goals we found a small place to discuss this thing in our Retrospective.
Business overview
The last but not least thing we did was to look around. Many teams working together with us in the Department, so, we decide to talk to others and learn their experience.
Several times we sent one representative of our team to join the “other team” Retrospective to learn what they do and how. This experience was really helpful because we include in our Retrospective such a thing as the “Business overview”.
Let Product Owner take a speech on every Retrospective with results, progress, and plans of the current timeline from the Business perspective.
Observe the whole Roadmap of a Quarter is really important to understand where we now and how fast the team moves on. How much we achieved compare to our commitments? Do our expectations were correct? Are our plans still the same? You better to know the answer to all of these questions. This is why I highly recommend to include in your Retrospective status review of current Milestones.
Don’t do it!
Retrospective — is not only what to do, but also what not to do. For example, some teams do a Demo of product — we don’t. Good manner to do “Closing” ceremony of Retrospective — we don’t. Some teams do something else — we don’t. You got my point. There are tons of other possible stuff to do on Retrospective. Choose things that fit your team.
Enjoy Retrospective
Rigid is a contra word to Agile. Scrum is based on team agility or flexibility as you know. This is why the selection of the right tools and modification of processes is a continuous way of improvement.
I can’t say that we are finished with our Retrospective. Sure, we like it. It is much better than the Retrospective that we had before, but we probably never finish our way of learning.
I hope you enjoy this article and find interesting ideas for your team. Let me summarize this article with the next message: be ready to look into the black mirror, be honest tell the truth every Retrospective, be curious to search for new tools and be brave to experiment with them. I can’t guarantee you the first place at the finish line, but I can guarantee that the race becomes joyful.
