Jabelic Web Press

Reflections from Attending RSGT2025

Introduction

I recently attended Regional Scrum Gathering Tokyo (RSGT) 2025. I had been interested in this event since last year but couldn't attend as I was completing my master's program. January is a crucial time for most M2 students, including myself. Last year, the in-person ticket was 22,000 yen, which was somewhat affordable. I thought, "Next year for sure!" However, this year saw a staggering 300% price increase. To be honest, I was quite hesitant. Fortunately, my expense application was approved, allowing me to participate for the first time.

I'm a first-year software engineer. During my graduate studies, I learned about Agile methodologies, and currently, I'm primarily engaged in software development while also challenging myself to support my team's Agile development practices. Additionally, I belong to an in-house study group called "Make People Awesome Seminar," which focuses on management. Through this seminar, I wanted to gain more practical insights into Agile and Scrum.

For RSGT, I selected sessions based on "what I could bring back to my team." In particular, since I introduced Sprint Retrospectives to my team last year, I wanted to enhance this practice.

Before attending, I had the following questions:

  • How can we conduct more effective retrospectives?
  • How should we define and measure product value?
  • How can we enhance team autonomy?

While seeking answers to these questions through various sessions, I gained even more insights than anticipated. Below, I'll summarize my key takeaways by theme.

What is Value?

In product development, "value" is always at the center of discussions, but defining and measuring it concretely can be challenging. One particularly striking example was Amazon's Fire Phone.

The Fire Phone was reportedly something Jeff Bezos himself wanted. However, it eventually had to be discounted to 99 cents, resulting in a $1 billion write-down. Someone's comment in the Discord live channel was quite memorable: "The customer was Jeff Bezos." This case illustrates that even if a product is desired by the CEO, it won't create value if it doesn't match actual customer needs.

So, how should we define and measure value? Important points I learned throughout the conference include:

  1. 👎 Traditional misconceptions:
  • Value means delivering to specification within deadline/budget
  • MVP is a product with minimal features
  1. 👍 New perspectives:
  • What we deliver to customers is "impact" (not just outcomes)
  • MVP is a tool for validating ideas. The value is in verification, not in creating a minimal product.
  • Value can be measured using "AARRR (Pirate Metrics)":
    • Acquisition: How to acquire customers
    • Activation: Providing initial value
    • Retention: Continued usage
    • Referral: Word-of-mouth generation
    • Revenue: Business success

I found it particularly insightful that "customers complain when features are missing, but rarely provide feedback when they're satisfied." This is a challenge we face in our workplace as well, highlighting the need for mechanisms to more actively collect user feedback.

Sprint Retrospectives

Ryuzee's session on Sprint Retrospectives was particularly enlightening, as this was an area I was especially interested in.

First, there was a note about terminology. The Japanese term "furikaeri" (reflection) is too broad a concept, with meaning varying by context. "Furikaeri" can be translated as "recollection" or "remembering the past." Drawing from Aristotle's "Categories" where "naming is the beginning of knowledge," in the Scrum context, we should use the precise term "Sprint Retrospective." From my experience, misuse of terminology can be problematic. When people say "Retro is just reflection, right?", Sprint Retrospectives risk becoming mere "review meetings," which is not their purpose.

In terms of practice, I found the following points particularly important:

  1. Principles of improvement:
  • Focus on a small number of items
  • Limit improvements to those that can be inspected within the sprint cycle
  • Improvements should be SMART (Specific, Measurable, Achievable, Relevant, Time-bound) and concrete
  1. Key insights:
  • "Improvement ideas are just fantasies" "All plans are fantasies until put into practice"
  • Improvement means making work safer and easier
  • Also highlight what went well and why. Is it reproducible?
  • Be cautious of "improvements" that add more checklists. These can prevent "focus" on Sprint Goals.

Organizational and Management Perspectives

Among sessions on organization and management, I found "Survival Guide for New Managers" and "Organizational Culture for Agile Teams to Continue Changing" particularly impressive.

In Mr. Harada's session for new managers, there was an interesting perspective on being a "convenient and user-friendly manager":

  1. Essential role of managers:
  • Managers are "spare resources"
  • They exist to prepare for unexpected situations
  • They handle exceptions (but if exceptions become the norm, systemize them)
  1. Practical tips:
  • "I could do it faster/better myself" is an illusion
  • Practice Management by Walking Around (MBWA)
  • Build relationships where BAD news can be shared early
  • Saying "I'm sorry" is also an important part of the job

I found the point about "never scolding the boy who cried wolf" particularly striking. No one, not just managers, should scold people for mistakes.

Meanwhile, in Mr. Odanaka's session on organizational culture, experiences from actual product development teams were shared:

  1. Team launch strategies:
  • Utilizing Inception Deck
  • Clarifying what we "don't know"
  • Running hypothesis-verification loops
  1. Learnings from practice:
  • Daily incremental refinement is effective
  • Development speed is an important value
  • Quick response to customer feedback builds trust

Open Space Technology

The Open Space Technology (OST) session I attended on the third day was the conference's closing session. There were about 2-3 workshops at the same time, with OST being the only session without a participant limit.

The basic principle of OST is to maximize participants' autonomy and self-organization. The principles are:

  1. "Whoever comes are the right people"
  2. "Whatever happens is the only thing that could have"
  3. "Whenever it starts is the right time"
  4. "When it's over, it's over"

I interpreted the first principle as "titles don't matter," and the second as "it's okay if the discussion deviates from what was planned." Having such principles agreed upon in advance makes it easier to join discussions spontaneously.

The "Law of Two Feet" governing participant behavior states:

  • Participants can choose which sessions to attend (including choosing not to participate)
  • If you feel you can't contribute or aren't interested in the discussion, you're free to move elsewhere

While I initially felt guilty about this rule, in practice, it actually energizes discussions.

This format seems applicable to daily Scrum practices:

  • Encouraging participation in Daily Scrums
  • Activating discussions in Sprint Planning
  • Generating improvement ideas in Sprint Retrospectives

The OST experience provided a good opportunity to think about team self-organization: minimize formal rules while maximizing participant autonomy. This seems to embody the essence of building an agile organization.

Personal Insights

To be honest, I felt a slight dissatisfaction throughout the conference:

  1. Lack of technical deep dives:
  • Practical examples of pair programming
  • Specific ways to address technical debt
  • Optimization methods for delivery pipelines
  1. Lack of quantitative approaches:
  • Analysis of communication patterns

However, this discomfort itself might have been an important learning. Perhaps I had a perspective biased toward technical aspects, or perhaps it indicates a demand for addressing these issues.

Looking Ahead

Based on what I learned at the conference, I'm considering the following actions:

  1. Improving Sprint Retrospectives:
  • Narrowing improvement items to 1-2
  • Enforcing SMART (or with clear completion conditions) improvement items (only picking up improvements that can be written SMART)
  • Creating mechanisms to transform "fantasies" into "verifications"
  1. Efforts to visualize value:
  • Considering introduction of AARRR metrics
  • Strengthening user feedback collection
  • Utilizing impact mapping
  1. Improving communication:
  • Promoting "waigaya" (open and lively discussion)
  • Creating an atmosphere where BAD news can be easily shared
  • Creating opportunities for inter-team collaboration

Conclusion

My first RSGT included both expected learnings and unexpected insights. Particularly impressive was Mr. Honma's Closing Talk on the "true cause of Japan's lost 30 years":

  • Excessive planning
  • Excessive analysis
  • Excessive compliance

These three days emphasized the importance of balance: retaining only what is truly necessary while prioritizing "waigaya" and "open discussion," yet reliably delivering value.

If I have the opportunity to participate again, I hope to engage in deeper discussions based on the insights gained this time.