Retro yang Menghasilkan Perubahan, Bukan Cuma Sesi Curhat 90 Menit

Hampir semua tim Agile menjalankan retro. Sedikit yang bisa menunjukkan apa yang berubah karena retro itu. Bedanya bukan di format — Sailboat, Starfish, Mad/Sad/Glad, 4Ls, semuanya bisa jalan. Bedanya di apa yang terjadi setelah menit ke-90.

Masalah utamanya: retro jadi katarsis

Pola yang sering terjadi:

1. Tim tulis sticky note 10 menit
2. Dot voting
3. Diskusi 40 menit soal "deploy sering gagal"
4. Facilitator bilang "oke, kita perbaiki ya"
5. Semua bubar, tidak ada yang berubah
6. Sprint berikutnya: sticky note yang sama, ditulis ulang

Tiga sprint kemudian tim berhenti percaya pada retro. Yang tersisa cuma ritual. Ini bukan masalah motivasi — ini masalah tidak ada mekanisme yang memaksa tindak lanjut.

Anti-pattern yang paling sering

"Tingkatkan komunikasi." Action item paling populer sepanjang sejarah. Tidak terukur, tidak bisa diverifikasi, tidak ada pemiliknya. Kalau action item tidak bisa dijawab dengan "selesai / belum selesai" minggu depan, itu bukan action item — itu harapan.

Action item 8 buah. Tim merasa produktif karena menghasilkan banyak komitmen. Realitanya nol yang dikerjakan karena tidak ada yang masuk backlog. Satu perubahan yang benar-benar terjadi > sepuluh ide bagus yang mati di dokumen.

Retro tanpa data. Semua berdasarkan perasaan dan yang paling baru diingat (recency bias). Insiden hari Rabu mendominasi, padahal masalah strukturalnya adalah PR yang menganggur 3 hari.

Facilitator = manager. Orang jadi diplomatis. Keluhan yang sebenarnya tidak pernah keluar.

Tidak ada review action item lama. Ini pembunuh kepercayaan paling cepat. Kalau action item sprint lalu tidak pernah dibahas lagi, tim belajar bahwa retro tidak ada konsekuensinya.

Format yang saya sarankan (dan kenapa)

Start / Stop / Continue untuk tim baru — paling mudah dipahami, langsung mengarah ke perilaku.

4Ls (Liked, Learned, Lacked, Longed for) kalau tim mulai bosan dan jawabannya repetitif. Kolom "Learned" memaksa ada sisi positif, "Longed for" memunculkan hal yang tidak pernah disebut di format lain.

Lean Coffee kalau tim besar atau topiknya tidak terprediksi — agenda dibangun di tempat dengan dot voting, timebox per topik.

Starfish (Keep doing, More of, Less of, Stop, Start) kalau masalahnya bukan biner. "Less of" sering lebih jujur daripada "Stop" — orang enggan bilang berhenti total.

Tapi format cuma 20% hasil. Sisanya struktur sesi.

Struktur yang bekerja

1. Buka dengan review action item lama (10 menit). Sebelum bahas apa pun: action item sprint lalu selesai atau tidak? Kalau tidak, kenapa? Ini yang membuat retro punya gigi. Kalau ini dilewati, semua di bawahnya jadi teater.

2. Silent writing dulu, 5 menit, tanpa bicara. Ini bukan detail sepele. Kalau langsung diskusi, orang paling vokal (biasanya paling senior) menentukan arah, dan yang junior ikut arus. Tulis dulu, baru tempel, baru vote. Suara jadi lebih merata.

3. Bawa angka. Sebelum sesi, siapkan 3-4 metrik ringan: jumlah insiden, median waktu PR di-review, jumlah hari carry-over, bug yang lolos ke production. Fungsinya bukan menghakimi — fungsinya memindahkan diskusi dari "kayaknya kita makin lambat" ke "cycle time naik dari 4 ke 7 hari, di mana macetnya?"

4. Pilih maksimal 2, idealnya 1. Setelah voting, jangan ambil semua yang populer. Ambil satu yang paling berdampak dan paling bisa dikerjakan dalam satu sprint. Sisanya masuk daftar parkir untuk sprint berikutnya.

5. Ubah jadi tiket, bukan catatan. Action item harus jadi work item nyata di tracker, dengan pemilik dan tanggal. Kalau tidak masuk tracker, dia tidak ada.

6. Tutup dengan kalimat eksplisit. "Yang berubah sprint ini: X. Pemiliknya Y. Kita cek di retro berikutnya." Satu kalimat. Ini yang diingat orang.

Anatomi action item yang benar

Bandingkan:

Pola: satu perilaku konkret + satu pemilik + satu tanggal cek. Kalau tidak bisa diisi ketiganya, berarti masalahnya belum dipahami — kembali ke root cause.

Root cause, bukan gejala

"Deploy sering gagal" adalah gejala. Tanya "kenapa" lima kali:

• Deploy gagal → karena config beda antara staging dan production
• Kenapa beda? → karena config production diedit manual
• Kenapa manual? → karena tidak ada secret management
• Kenapa tidak ada? → karena belum pernah jadi prioritas

Action item yang benar bukan "hati-hati saat deploy" — tapi "pasang secret manager, migrasi config production". Beda antara mengelus gejala dan mencabut akar.

Hati-hati: five whys gampang berubah jadi sesi menyalahkan orang. Berhenti di proses, bukan di nama.

Retro remote

Yang berubah: silent writing jadi wajib (bukan opsional), dan vote pakai dot voting di board (FigJam/Miro) alih-alih angkat tangan — angkat tangan di video call tidak terbaca.

Yang tidak berubah: timebox dan review action item lama. Justru lebih penting, karena retrospeksi remote lebih gampang jadi sesi pasif di mana semua orang diam sambil buka tab lain.

Cara mengukur apakah retro-nya bekerja

Satu metrik saja: action item completion rate. Dari action item yang dibuat 3 sprint terakhir, berapa persen selesai? Di bawah 50% berarti retro-nya sedang jadi teater. Jangan tambah format baru — perbaiki dulu tindak lanjutnya.

Metrik kedua kalau mau: apakah masalah yang sama muncul lagi di sticky note? Kalau "deploy gagal" muncul 4 sprint berturut-turut, retro-nya gagal, bukan timnya.

Satu hal yang bisa langsung dipakai

Buka retro berikutnya dengan dua hal ini, sebelum apa pun:

1. 10 menit pertama: review action item lama. Selesai atau tidak, satu per satu. Kalau tidak selesai, tanya kenapa — jangan dihukum, tapi harus ada penjelasan.
2. Action item wajib format: [perilaku konkret] — pemilik: [nama] — cek: [tanggal]. Kalau tidak bisa diisi lengkap, jangan diterima sebagai action item.

Dan satu aturan tambahan yang sering dilupakan: maksimal satu action item per sprint. Terdengar terlalu sedikit. Justru itu intinya — satu yang benar-benar terjadi mengalahkan delapan yang jadi catatan mati.

Takeaway

Retro yang bagus bukan yang menghasilkan banyak ide. Retro yang bagus adalah yang sprint berikutnya bisa kamu tunjuk satu hal dan bilang: "itu berubah karena retro."

Kalau tidak ada satu pun yang bisa ditunjuk, formatnya bukan masalah. Tindak lanjutnya yang belum ada.