Hello. This is Idel from Rakuten Osaka Branch. Please allow me to share my experience about Retrospective.
A few years ago, I change my career path from Software Engineer to Project Manager and have since tried different framework, methodology or ways to improve the way I handle projects and interact with the team. That story is out of scope for this article and will be shared in the next R-Hack. For now I want to focus more on “Retrospective“.
Retrospective is a meeting held after a product ships to discuss what happened during the development with a goal of improving things in the future based on those learnings and conversations.
Is Retrospective Important?
A team needs to find ways to always improve , without it the team will become stagnant.
Discover the best practices your team have and make sure to continue it.
It can also be a chance to say appreciation to each member.
Focus on the positive side and find ways to improved.
Never resort to name-calling or blaming or you will loose the real meaning of retrospective.
Each team is also different. If you work with a diverse team, make sure to set a baseline so that you don’t step or accidentally insult other member’s cultural background.
We have a basic idea on what is Retrospective and it's importance let me elaborate my experience with my colleagues.
How did you get introduce to it?
For more or less than 15 years, I was developing mainly middleware and it was very waterfall. My team was never agile or use the scrum framework. The only time I conversed with my colleague at work was during specification discussion or any Q&A sessions. When I joined my team at Rakuten, it was the first time I heard about agile, scrum, huddle or retrospective. I have no experience with all of these, so I have to learn fast to understand it better.
How was your first Retrospective Experience?
I had no idea what was going on. I was told to write something I observed on a sticky note. Then there was a discussion about it and it was group together , someone took a picture and made a page in confluence and that was it. I did not hear anything afterwards.
The event itself was okayish. Majority of the members were quiet and barely spoke anything. There are some who monopolizes the conversation. It was not a productive 30 minutes and at that moment I feel that retrospective was just a waste of time.
You said “A Waste of Time”, When or How did your view change?
The team went to different organization changes as well as process improvement which gave a chance to learn different ways of team management, and no I’m not a manager :D. I also had the chance to join different team who are doing retrospective.
The latter was probably the biggest factor. Seeing how other teams communicate, sharing their views and idea of team improvement and actually checking the actions if it was executed properly and what was the impact to the team.
Of course it was not all peachy, I joined some team whose retrospective turned into a ranting and blaming sessions without any productive output.
It all depends on how the team views this event and of course proper facilitation.
Is there a style that you recommend?
It should be based on what the team is comfortable with. There are different style that I have tried over the years which I listed below (Not in specific order) Spotify’s Squad Health Check – a colleague introduced me to this model which I really like since it helps the team visualize, discuss and assess the current situation and have a focused action plan. Before the Covid-19 Pandemic, I dowloaded the cards, printed it and laminated it for the team. It took several tries but we got used to it and was able to focus on what we really want to improve and set realistic action plans. The team agreed to use this style once or twice a month to get a clearer idea on the results.
Unfortunately because of Covid-19, we could no longer do the face to face version. One colleague got very creative and created a game version in Kahoot (?). As for me, I wanted a simpler version with Japanese translation so I created a survey style using Microsoft . Please check the end of this post for the Japanese version.
Moving Motivators – Others might say this is best for 1-on-1 with Managers and I agree But doing this as a team was actually fun. We did it every month and found out our motivation changes depending on the team situation and maybe personal mood. The team kept a monthly record in one location to see the changes easily. We also shared to our managers to give them an idea what motivates each member in the team.
It was interesting to see that my first two motivators stayed the same all throughout the year.
Last but not the least KPT method (Keep Problem Try) Historically speaking, this method was made by Toyota for continuous improvement. It’s still very useful and simple enough. It’s a good style for a new team who is new to doing retrospective. BUT as you continue with doing retrospective it can get a little monotonous, so it is good to combine this with Squad health check or any other style.
There are different style of doing retrospective, the team can give it a try and the best fit for everyone and with the Covid-19, it gets a little more difficult to do retrospective but fear not there are ways and I’m sure many teams out there have already used different online tools to continue the team improvement. Miro , Ideaboardz are just some of the online tools that can be helpful.
**Do you share the result to Management?
Definitely. There are actions plans that the team cannot do on its own or requires management support and its up to the leader of the group to make sure it get to right person. But make sure that the members will not be criticized or targeted by the management. Each opinion from each member should not impact their evaluation or performance review.
Trust is the key, both ways. Management to the team and team to the management. Establishing this trust among the team is a challenge and that is why retrospective is good stepping stone in building this trust. By creating a safety space where people can share their idea.
*All information here are based on my experience and my personal opinion only. There are lots of books on Agile , Scrum or working with a diverse team. Some of you out there might not agree with me and that’s fine. *
We are Hiring !!
Thank you very much for reading. In Rakuten Commerce Incubation Department, we are currently hiring someone who can create and nurture new value as one team to help drive the business growth.
(Appendix) Japanese Version for Spotify Squad Health Check
Delivering Value ・価値を提供する
青 誇りを持って良いものを届けています。ステークホルダーも満足しています。 * 黄 : ままです 赤: 残念なものを届けています。恥ずかしいです。ステークホルダーにも嫌われています。
Easy to Release ・ リリースが簡単
- 青 : リリースはシンプルで安全で簡単で、ほぼ自動化されています。
- 黄 : 悪くない
- 赤 : リリースはリスクが高くて、大変で、手動でやることがたくさんあって、すごく時間がかかります。
- 青 : チームと一緒に仕事をするのはとても楽しいです。
- 赤： つまらない。。。。
Health of Codebase・コードベースの状態
- 青: コードの品質に自信があります。きれいで、読みやすくて、テストのカバレッジも高いです。
- 黄： リファクタリングした方が良い
- 赤: コードはすごく汚くて、技術的負債はもう全然手に負えません。
Pawn or Players・駒なのかプレーヤーなのか
- 赤： 私たちはチェスの駒のようなただの傀儡です。何を作るか、どのように作るかに意見を出すことはありません。