👋Introduction

Hello, my name is Sasaki and I am an aspiring retrospective master. I work as a Project Manager at KINTO Technologies.
In my previous job, I was a project manager and worked on agile development (Scrum and Kanban) in a team.
I really like retrospectives. In my previous job, I used retrospectives to organize minimal design documents, promote CI, and even remove tension between new and senior employees. They were very helpful for both development and mental care.

Introduction

It's been a year since I joined the company, during which I've released several projects and facilitated retrospectives as a Project Manager.
Unlike Scrum team's retrospectives conducted in the iterative development cycle, project retrospectives are for development and release processes that have definite start and end points and involve different members every time. Regarding this type of retrospectives, I found that setting its timing, perspective, and objectives is more challenging in comparison with sprint-based retrospectives.
In addition, we had to be careful about operational aspects such as how to draw out honest opinions when we had not yet built relationships with team members, what tools to use in a retrospective that would fit the participating members, what framework to use, and whether to hold the retrospective in person.
In this article, I'd like to discuss the approach I adopted for "project retrospectives" as a part of cross-team initiatives, the reasons behind it, as well as the specific retrospective procedures and the outcomes achieved.🙌

Table of Contents

1. Project Retrospective
2. Retrospective Structure
3. Project Retrospective Design
4. Retrospective Practice

Project Retrospective

Projects at KINTO Technologies

KINTO Technologies offers a variety of products for end users and the back office, including products that handle the front-line customer experience, products for dealerships that order cars, and products that support customer centers.
In cases where multiple products need to be released in cooperation, such as updates to contract plans or the addition of supported brands, or when there are numerous stakeholders involved, development at KINTO Technologies proceeds in units of projects.

Project Progress

Each product is developed daily in a different style for each team, such as Scrum.
As a project, major processes and milestones are planned, and after requirements analysis and definition are finalized, the design and development process is carried out in an agile manner.
The project will proceed using what is commonly known as a hybrid development method (waterfall + scrum).
Although products are iteratively developed in daily cycles, the overall development process follows a waterfall model to ensure quality and meet deadlines at each milestone.
Source: What is hybrid development? Explanation of the difference from "agile type" and its promotion system

About This Project

Until now, when canceling KINTO ONE's cancellation fee free plan during the contract period, cancellation had to be done by phone. To improve customer usability, we will make it possible to apply for this service via the web.
Apart from this, in our back-office products, we worked on a year-long project to semi-automate and improve the mid-term cancellation process, which was manually operated.
As the number of online cancellations increases, the process automation becomes essential to handle a large number of cancellation requests efficiently, along with the update. The development of these two elements will be released as a single project.
The project requires four months, involving a total of about 20 team members, including team leaders and planning team members (from KINTO).

https://corp.kinto-jp.com/news/service_20240219/

‍🧙‍♂️ Retrospective Structure

To make the retrospective more effective, I would like to refer to the method recommended in my favorite book, "Agile Retrospectives." We'll proceed with the retrospective divided into the following five sections:
1. Set the Stage
Make it easier for people to express their opinions by breaking the ice and reading out the ground rules
2. Collect Data
Review the source information from the retrospective and post sticky notes on the whiteboard.
3. Generate Insights
Verbalize your ideas through exercises such as brainstorming.
4. Decide What to Do (Determination of action items)
Participants use dot voting to decide which actions should be prioritized.
5. Close the Retrospective
Summarize action items, express thanks, and conclude the retrospective.

Brief summary

To briefly summarize, we create a comfortable environment for open discussion, encourage participants to share their thoughts on the whiteboard, and then identify actions and improvements for the issues raised. These will be followed on the day of the event.
This structure is mainly used for creating the agenda, but this book also includes detailed tips, such as setting retrospective time according to the development period. We will refer to this book at key points as we design the retrospective.
If you're interested, I recommend reading Agile Retrospectives!
Agile Retrospectives (Amazon)

🏗️ Retrospective Design

The content of retrospectives should vary depending on the nature of the project, the participants, and other contextual factors. I’ll try to walk you through the design process of my retrospective step by step.

1. Confirm assumptions and constraints
2. Goals setting
3. Design and review of the process

1. Assumptions and Constraints

First, I organize the assumptions and constraints for the retrospective. Since various teams are participating in this project, I outline the key points to prevent any delays in progress.

• Differences in retrospective culture among teams
  • Some teams conduct retrospectives regularly, while others don’t
  • Some people have experience with KPT but are unfamiliar with other methods.
• Differences in tool proficiency
  • Some teams are not familiar with using whiteboards
  • Some people don't know Miro
  • Some people need additional permissions to access tools, such as Confluence
• Differences in participant locations
  • Tokyo, Nagoya, Osaka
• Others
  • This project is a fixed-term, cross-team initiative and will conclude upon completion.

💭 What I Thought

Differences in retrospective culture

Looking at the meeting schedules, there were clear cultural differences between teams that conducted sprint retrospectives and those that did not. Everyone seems to know about KPT, as they have conducted KPT in previous projects.

Tool selection

Since multiple teams participated, there were differences in the level of familiarity with the tools depending on the team. It can be uncomfortable to join a meeting without a good understanding of the tool, so I always try to ensure everyone can participate positively without getting let down by tool usage

Meeting time settings

I don't know about the entire company, but I feel that the meeting times are shorter compared to my previous job. Long meetings are about 30 minutes and many people feel that any meeting lasting over an hour is too lengthy.
Some teams may have members who aren't fully proactive about project retrospectives and participate more out of obligation (believing that their contributions within their respective teams are enough). Taking this into consideration, I want to set the time as short as possible so that it is less likely to cause confusion.

Location (Onsite/Offsite)

Since some people are based in different locations, it is also important to decide whether to hold the meeting in person or online. If holding the meeting in person, it is important to ensure that online members do not feel left out. When I asked the question on the company's agile channel, everyone shared the methods they have used in the past and the points to be careful about (hybrid meetings, using Jamboards, etc. Thank you everyone!)

Psychological safety

Psychological anxiety is another factor to consider. Since communication isn't well established across members from different teams, it can be difficult to draw out their true feelings. Our goal was to create an environment that fosters as much psychological safety as possible.
Now, how do we proceed?

2. Goals setting

I'll set the goals I'd like to achieve in this retrospective as the Project Manager and facilitator.

💭 What I Thought

I hoped this retrospective would drive improvements beyond organizational boundaries and enable cross-functional enhancements to the service itself. However, as I'm still in the early stages of building trust with the participants, it's challenging to expand the scope of the retrospective at this point.
With that in mind, I decided to focus this retrospective on sharing project results and resolving issues within my control (project management). Regarding the cross-sectional issues and problems that came up during the discussion, I would like to keep them as a common understanding for future improvements.
I also want to help everyone get comfortable with interactive retrospectives at an organizational level, so I definitely plan to use the whiteboard.

The main mission

• Review and share project outcomes
• Identify improvement tasks as project management

The sub-mission

• Gain a common understanding between planning and development on the larger issues
• Introduce interactive retrospectives using whiteboards

3. Design and review of the process

To achieve our goals while keeping the aforementioned constraints in mind, I'll consider how to proceed with the day's retrospective.

1. Set the stage

Psychological safety

Since many members will participate in the retrospective, we will proceed according to a set flow to some extent. In order to explain these and ensure psychological safety in the space, we will declare the ground rules at the beginning. Since we want to convey them little by little, we will also casually put them on the whiteboard in a visible place.

Time settings

According to Agile Retrospective guidelines, a release retrospective can last from one to nearly four days. However, as mentioned, even an hour feels too long for many participants, so I'd like to condense it to around 45 minutes.

2.3 Determine the time required
How much time should we spend on a retrospective? It depends.
-omitted-
For a team doing a one-week iteration, an hour of retrospective is sufficient.
For a team doing a 30 day iteration, half a day is enough.
Shorter time will give lax results.
(Release and project retrospectives take at least one day. In some cases, they may take four days.) Quote: Agile Retrospectives, Chapter 2.

2. Collect data

Differences in retrospective culture / Tool selection

Since KPT is a popular method at KINTO Technologies and we frequently use Confluence as a primary tool in our work, we'll utilize Confluence whiteboards, which eliminates preparation hassles like setting up accounts.
The following two exercises are used to collect data. Some of you may not be familiar with Timeline. Here is a detailed description of each.

• Timeline
• KPT

Timeline

When you go into retrospectives without preparation, the focus often ends up on the most recent and memorable events.
A timeline is an exercise to help you remember what happened in the past.
by arranging key facts and feelings in chronological order over a specific period.

Quote: What is a Timeline?
https://anablava.medium.com/a-timeline-retrospective-easy-guide-6385fce0affd

This time, instead of having the full timeline described, I'll casually leave a timeline written by the Project Manager in advance. Participants can then add sticky notes with any additional thoughts they have. We won't be using dot voting, either.
I borrowed this idea of a pre-prepared timeline from Kin-chan of the Agile channel.
Since this is a release retrospective, I'd ideally like to gather deeper emotional insights, but since we have a limited time of 45 minutes, I'll keep it simple.

KPT

Many people have done this before and even if some of you have never done it before, it is easy to understand, so we will use KPT for this retrospective.
I think many people have come across this at some point, such as during orientation in their student days or group training at a company. It is a framework for raising Keep, Problem, and Try, and looking for ways to improve each topic. The acronym is KPT (pronounced Kept / Key-pi-ti). I call it Kept.

• Keep: What I have done and what I want to continue
• Problem: Issues, problems, and things you want to improve
• Try: What you want to challenge

Points to note about KPT

KPT is the most major method of retrospective, but since it begins with identifying "problems," it can easily lead to frustration or make it challenging to express minor uncertainties. In addition, personal opinions are sometimes treated as problems.
When I facilitate KPT, I try to be more objective and careful with my language than usual.
*This is completely personal preference, but it might be helpful to use KPT after a demonstration or presentation of results! (Because issues related to product functionality are more likely to be raised by the development team members themselves.)

4. Generate insights

Ideas will be generated in the Try of KPT.
Since many of the participants are busy, it is acceptable for them to write their ideas in advance.
However, doing so may weaken the connection between KP and Try, so dedicated time will be set aside on the day of the retrospective to review and dive deeper into the Try content.

5. Decide what to do (determination of action items)

In the Scrum team retrospective, we get commitments through dot voting, but this time, we have a limited time (45 minutes), so we will facilitate and select action items. Organizational issues outside the project scope may also be included on the agenda.
While accepting the major issues at hand, we will prepare ourselves mentally to make concrete improvements to project management.

🎯Practicing retrospectives

After going through the above design, I will summarize the actual retrospective I conducted.
*It's a small detail, but I'll also share key considerations for those looking to introduce a new retrospective.

1. Guidance and follow-up for the retrospective meeting (Preparation)

• Request for collection of project results
• Notification on whiteboard usage and opt-out option
  *If possible, speak to them individually at your seat or speak up at the end of the meeting.
• Provide pre-use whiteboards for those who are busy and prefer to write their input in advance.

2. Setting the scene

• Briefly review the ground rules to create a comfortable atmosphere for open discussion.

• Gently remind everyone like, "Let's keep it positive—no criticizing!"

Ground rules
This is a safe space to share feedback.
- Avoid language that may offend others
- Share everything you are willing to share
- Focus on improvement, not blame
- Feel free to copy or add to someone else's sticky note

3. Collect data

Each team presented specific results as a project. It seems that the number of man-hours has been significantly reduced because cancellations that were previously accepted by phone can now be applied for online!

A. Timeline notes

We asked participants to voluntarily write down on the timeline any feelings or thoughts they had at the time. It was clear from their impressions that they had difficulties even after the release. This kind of feedback is difficult to capture with the "Keep, Problem, Try" (KPT) so I'm glad we were able to obtain it.

B. "Keep, Problem, Try" notes

Some participants prepared their notes in advance, while others shared during the session, resulting in a diverse range of opinions. Since many of the participants were busy, we decided it is acceptable to write only "Try" and asked them to include "Try" as a set with "Keep" and "Problem."

*Since there is a lot of work-related content, text has been blurred.

4. Generate insights

After a brief reading of all the sticky notes, we ask participants for their impressions of the KPT so far. As they talk about their impressions, a discussion will arise, so while facilitating, I will collect any new ideas that could lead to trying them and stick them on sticky notes.

5. Determine action items

We will turn what can be improved through PjM management and the tries that can be tackled in the next project into actions.

*The following is an excerpt of content that can be shared during the course of work.

6. Close the retrospective

Let's summarize the above, express thanks, and dismiss.

Outcome of this Retrospective

The following results were obtained through the retrospective.

Outcome as a project

• Regarding the effectiveness of the project, all involved parties were able to see concrete figures showing the reduction in labor hours.
  • Participants were able to celebrate the project release together.
• Improvement actions were generated for project issues.
• We were able to gain a common understanding of issues across organizations (e.g., how to handle design materials).

Other outcomes

• It took quite some courage to suggest using a whiteboard, but it was readily accepted.
• The timeline showed the difficulties encountered after the release, and reaffirmed the importance of stable operation after the release.
  From the above, I was able to achieve the goals I had planned as a facilitator. 🎉

The main mission

• Review and share the project outcomes: Achieved
• Identify improvement tasks as project management: Achieved

The sub-mission

• Achieving common understanding between planning and development regarding large-scale issues: Achieved
• Introduce interactive retrospective using whiteboards: Achieved

For the Future

When I tried it, everyone was quick to accept the whiteboard and timeline.
I was also able to introduce the timeline, so I'd like to incorporate the 4Ls and similar techniques after some time.
Regarding time constraints, I may have been too hesitant and could have extended it.
Or, if we have retrospectives at project milestones as well as at release, we might be able to time them nicely, even with a 45-minute limit. We can also make improvements at the right time when problems arise!

Thoughts

In this article, I've summarized my thoughts and methods for conducting project retrospectives.
I hope this can help anyone facing similar challenges with project retrospectives!
Retrospectives are like the poster child of agile, embodying iterative inspection and adaptation.
Hope you all enjoy your retrospectives!