Skip to main content

Retrospective with Sailboat

Have you ever got bored with the Retrospective meeting? I have, sometime. Most of the times, this meeting just goes traditionally by answering three questions: "What good things have we done? What bad things have we done? And, what actions should we improve?" Ever and ever again! My team found a way to make it a little bit more exciting. The idea is that each member - not only our Scrum Master - will become a host. If a meeting is hosted by a memeber, the next meeting will be hold by another one.


Yeah, I used "Sailboat" pattern in my turn. So, I just want to share with you guys how it was.

I started the meeting by telling a short story that I hoped everyone in my team could recall the meaning behind of Retrospective meetings:

There is a group of people trying pick up trash in a park. At the first look, the park seem not to have a lot of trash because they are spread out all over the place. However, these people continuously found trash when they started. They kept picking them up until the whole park is clean.

What exactly I did mean from this story is "just keep improving". In my opition, Retrospective is the time for us to look back what "trash" are found and try to eliminate them continuously.

Next, I drew a picture about sailing boat as a metaphor for the team. (The following is my own painting; it took me nearly one hour to complete. Haha!)

All parts of this picture are numberd from 1 to 5 with my explaination below:

[1]. Sailing boat: the team
[5]. Happy island: Sprint goal (or team's goal in general)
[2]. Wind: motivator - what moves the boat forward
[3]. Anchor: impediment - what slows the boat down
[4]. Rock: pitfall - what dangerous things are able to stop the boat

Whole members thought about it in 5 minutes, then I picked a member randomly to talk about her/his own opinions. Next, this member again selected randomly another one.

Thanks to this visualized method, I saw the meeting went more exciting with a lot of issues were discussed easily.

Comments

Popular posts from this blog

Monday vhandit #1

This is the first post in a series of articles called "Monday vhandit". You can go to the original post by clicking on each head title. Character encodings: essential concepts This article points out why Unicode matters and differentiates among concepts: character sets, coded character set (unit is code points), and character encoding. Explained from First Principles: the Internet The very structural and well-explained article contains almost concepts of the Internet. I really appreciated the author's effort put on that post. Dev Community - DevDojo I just joined this community. DevDojo is really a developer-oriented platform. It is very nice, easy, fast, and sufficient to write (Markdown supported) and search for a post. The best of it, you also have a personal blog for your posts at "<your_username>.devdojo.com". My username is vnnvanhuong Everything you need to know about HTTP security headers A good collection of HTTP security-related headers. Moreover...

Projects Ownership

Developers should be informed transparently about the next things that they are going to do since it impacts their mentality as well as their accountabilities. A view of Vung Tau beach First thing first, the Product Owner plays a very important role in understanding the business of the projects clearly and planning the User Stories for Development Teams. For Development Teams, we have two roles related to a project including Owner and Maintainer. The following are the definition and responsibilities for each role: Project Owner The Owner is normally assigned to the team that created the project at the beginning. It is known as the long-term project of the team. Therefore, the members of the Owner have almost knowledge of the projects including the history (i.e decisions made), business logic, and technologies used.  - Maintain a good system design (code) of the projects. Therefore, they are mandatory to review code (pull requests) from other teams. - Maintain the related documents ...

Monday vhandit #2

  Introduction to OpenLDAP directory service "A directory is a specialized database specially designed for searching and browsing, in addition to supporting basic lookup and update functions" A directory service can be local, providing a restricted context; or global, providing service to a much broader context. Curlie is a good example of a directory service. LDAP (Lightweight Directory Access Protocol) is a protocol for accessing directory services , specifically X.500-based directory services. OpenLDAP is an open-source implementation of LDAP. Writing system software: code comments I have read Clean Code (by Uncle Bob) and I thought that I should void comments since the code it explains its implementation itself. That is right but not always true. In this post, the author categorized the comments into 9 types. Only "trivial comments" and "backup comments" are the ones that should be avoided. I myself agree with "writing good comments is harder tha...

My 2017 Review

Passion for System Design After finishing a one year project, my longest stable team (lasted for 3 years) was separated into two smaller teams. Sadly, but that was a good chance for me to become a key member in my new team. My preferred skills were about system architectures; therefore most of the tasks of building the application structures were handled by me. In order to enhance my design system skills, I have spent much my time for reading books closely after work. These following books help me a lot. - Object-Oriented Thought Process | Matt Weisfeld - Head First Design Pattern  | Elisabeth Freeman and Kathy Sierra - Java 8 in Action: Lambdas, Streams, and Functional-style Programming | Alan Mycroft and Mario Fusco Junior Technical Architect I was requested to join a technical architect team (aka Team. Alpha) where I actually had gained experiences almost on interviewing candidates for my company (lol). Besides, I noticed myself must improve the skills of convinci...