Memahami retrospective, membuat evaluasi retrospective

Pertemuan ini bertujuan membekali mahasiswa dengan pemahaman mendalam tentang retrospektif sebagai salah satu ritus penting dalam kerangka Scrum. Mahasiswa akan mempelajari definisi, tujuan, dan peran retrospektif dalam siklus pengembangan perangkat lunak agile, serta memahami bagaimana retrospektif membedakan dirinya dari tinjauan sprint (sprint review) melalui fokusnya pada perbaikan proses tim secara berkelanjutan.

Materi akan mengeksplorasi struktur dan tahapan pelaksanaan retrospektif yang efektif, meliputi lima fase utama: menentukan suasana (set the stage), mengumpulkan data, menghasilkan wawasan, memutuskan tindakan, dan menutup retrospektif. Pembahasan diperdalam dengan teknik-teknik fasilitasi seperti Start-Stop-Continue, Mad-Sad-Glad, Sailboat, dan 4L's (Liked, Learned, Lacked, Longed For) yang dapat diterapkan sesuai konteks dan kematangan tim. Mahasiswa juga akan mengkaji praktik terbaik dalam memfasilitasi sesi retrospektif yang inklusif, menangani dinamika tim yang kompleks, serta mengelola keamanan psikologis agar setiap anggota tim merasa aman untuk menyampaikan pandangan secara jujur.

Pada sesi praktik, mahasiswa akan melakukan simulasi evaluasi retrospektif menggunakan data sprint fiktif untuk mengidentifikasi area perbaikan, menyusun rencana aksi yang terukur dan spesifik, serta menetapkan metrik keberhasilan yang dapat dilacak pada sprint berikutnya. Luaran pembelajaran mencakup kemampuan merancang dan memfasilitasi retrospektif yang bermakna, mendokumentasikan hasil retrospektif, dan mengintegrasikan temuan ke dalam perencanaan sprint mendatang guna mendorong budaya perbaikan berkelanjutan (kaizen) dalam tim Scrum.

1. Konsep Dasar Sprint Retrospective

Sprint Retrospective adalah pertemuan formal dalam Scrum yang dilaksanakan setelah Sprint Review dan sebelum perencanaan Sprint berikutnya. Tujuan utamanya adalah menginspeksi bagaimana Sprint berjalan dalam hal individu, interaksi, proses, alat, dan Definition of Done. Tim Scrum bersama-sama mengidentifikasi hal-hal yang berjalan baik, potensi perbaikan, dan menyusun rencana aksi konkret untuk meningkatkan efektivitas tim pada Sprint selanjutnya. Durasi standar retrospective adalah maksimal tiga jam untuk Sprint satu bulan, atau proporsional lebih pendek untuk Sprint yang lebih singkat.

Retrospective bukan sekadar forum keluhan, melainkan mekanisme continuous improvement (kaizen) yang menjadi jantung Scrum. Scrum Master bertanggung jawab memfasilitasi sesi ini agar seluruh anggota tim Development, Product Owner, dan Scrum Master dapat berpartisipasi secara aktif dan psikologis aman. Hasil retrospective harus terdokumentasi dan ditindaklanjuti, umumnya dalam bentuk improvement backlog yang diintegrasikan ke dalam Sprint Backlog berikutnya agar perbaikan benar-benar terlaksana, bukan sekadar wacana.

2. Struktur dan Tahapan Retrospective

Retrospective yang efektif umumnya mengikuti kerangka lima tahap: Set the Stage untuk menciptakan suasana aman dan fokus, Gather Data untuk mengumpulkan fakta dan data objektif selama Sprint, Generate Insights untuk menganalisis pola dan akar masalah, Decide What to Do untuk memilih satu hingga tiga tindakan perbaikan prioritas, dan Close the Retrospective untuk merangkum serta mengapresiasi partisipasi tim. Setiap tahap menggunakan teknik fasilitasi yang bervariasi tergantung konteks dan kematangan tim, seperti Start-Stop-Continue, 4Ls (Liked-Learned-Lacked-Longed For), atau Sailboat.

Sebagai contoh nyata, sebuah tim pengembang aplikasi mobile banking menggunakan teknik 4Ls pada retrospective mereka. Pada tahap Liked, tim mengapresiasi keberhasilan otomatisasi pipeline CI/CD yang mempercepat deployment dari dua jam menjadi lima belas menit. Pada tahap Learned, mereka menyadari bahwa estimasi story point untuk fitur integrasi API pihak ketiga selalu meleset karena kurangnya spike teknis. Tahap Lacked mengungkap tidak adanya dokumentasi API internal, dan Longed For menghasilkan keinginan untuk menerapkan pair programming pada modul kritis. Dari empat temuan ini, tim memprioritaskan dua tindakan: membuat spike teknis sebelum estimasi fitur integrasi, dan menyusun dokumentasi API menggunakan Swagger.

3. Teknik Pengumpulan Data dan Metrik Retrospective

Pengumpulan data objektif merupakan fondasi retrospective yang kredibel. Tim perlu mengumpulkan metrik seperti velocity, burndown chart, cycle time, jumlah bug yang ditemukan, escape defects (cacat yang lolos ke produksi), dan happiness index. Data kuantitatif ini dipadukan dengan data kualitatif dari observasi anggota tim untuk membentuk gambaran komprehensif. Teknik Timeline Retrospective sering digunakan dengan menggambar garis waktu Sprint dan menempelkan sticky notes berisi peristiwa penting, emosi, dan keputusan kunci di sepanjang garis tersebut.

Contoh implementasi konkret: tim DevOps sebuah startup e-commerce menggunakan query database untuk mengekstrak metrik objektif sebelum retrospective. Mereka menganalisis tren lead time dari commit ke production dan menemukan bottleneck pada proses code review.

SELECT
    DATE_TRUNC('week', deployment_date) AS week,
    AVG(EXTRACT(EPOCH FROM (deployment_date - commit_date)) / 3600) AS avg_lead_time_hours,
    COUNT(*) AS total_deployments,
    COUNT(CASE WHEN has_rollback = true THEN 1 END) AS rollback_count
FROM deployments
WHERE sprint_id = 'SPRINT-23'
GROUP BY DATE_TRUNC('week', deployment_date)
ORDER BY week;

Query di atas membantu tim mengidentifikasi bahwa rata-rata lead time meningkat dari 8 jam menjadi 22 jam pada minggu ketiga Sprint, yang kemudian ditelusuri ke penumpukan pull request akibat dua senior developer cuti bersamaan. Temuan berbasis data ini menghasilkan keputusan untuk menerapkan kebijakan code owner rotation dan menurunkan ambang batas required reviewers saat kapasitas tim rendah.

4. Teknik Fasilitasi dan Mengatasi Tantangan

Scrum Master menghadapi berbagai tantangan dalam memfasilitasi retrospective, termasuk dominasi suara tertentu, apatisme tim, retrospective yang berulang tanpa perubahan nyata, dan ketidakmampuan mengungkap akar masalah. Teknik Five Whys membantu menggali akar masalah dengan mengajukan "mengapa" secara berjenjang hingga ditemukan penyebab fundamental. Teknik Fishbone Diagram (Ishikawa) berguna untuk memetakan faktor-faktor penyebab ke dalam kategori seperti People, Process, Technology, Environment.

Misalnya, tim yang mengalami penurunan velocity selama tiga Sprint berturut-turut menggunakan Five Whys:

• Mengapa 1: Velocity turun karena story tidak selesai → story terlalu besar
• Mengapa 2: Story terlalu besar karena kompleksitas tinggi → dependensi tidak teridentifikasi saat refinement
• Mengapa 3: Dependensi tidak teridentifikasi → arsitektur terlalu tightly coupled
• Mengapa 4: Arsitektur tightly coupled → tidak ada standar desain modular
• Mengapa 5: Tidak ada standar → tidak ada architecture review dalam Definition of Ready

Akar masalahnya adalah tidak adanya architecture review sebelum Sprint. Solusi yang disepakati adalah menambahkan architecture checklist ke dalam Definition of Ready dan mengalokasikan waktu architecture spike pada setiap awal Sprint untuk modul baru.

5. Membuat Action Plan dan Mengukur Dampak

Retrospective yang sukses harus menghasilkan SMART action items (Specific, Measurable, Achievable, Relevant, Time-bound) yang terintegrasi ke dalam Sprint Backlog. Setiap tindakan perbaikan memiliki penanggung jawab, batas waktu, dan kriteria keberhasilan yang terukur. Tim harus membatasi jumlah action items maksimal tiga item per Sprint untuk menjaga fokus dan memastikan eksekusi. Pola umum kegagalan retrospective adalah menghasilkan terlalu banyak ide perbaikan tanpa eksekusi, sehingga tim mengalami retrospective fatigue.

Contoh praktik baik: tim pengembang sistem HRIS menggunakan improvement burndown sederhana yang melacak penyelesaian action items dari retrospective sebelumnya. Setiap action item diberi bobot satu poin dan dimasukkan ke dalam Sprint. Pada awal retrospective berikutnya, Scrum Master membuka dashboard yang menunjukkan tingkat penyelesaian action items — misalnya dari enam action items di Sprint sebelumnya, empat terselesaikan penuh, satu parsial, dan satu tidak tersentuh. Data ini menjadi bahan refleksi awal untuk mendiagnosis mengapa item yang tidak terselesaikan gagal dieksekusi, apakah karena tidak realistis, kurangnya dukungan, atau kehilangan prioritas di tengah Sprint.

6. Pola Anti-Pattern dan Praktik Terbaik Retrospective

Beberapa anti-pattern umum dalam retrospective meliputi: Blame Game di mana tim saling menyalahkan alih-alih mencari perbaikan sistem, Venting Session tanpa tindakan konkret, Same Old Problems di mana masalah yang sama muncul setiap Sprint tanpa kemajuan, Scrum Master Monologue di mana fasilitator mendominasi diskusi, dan Sunshine Retrospective yang hanya membahas hal positif dan menghindari konflik. Setiap anti-pattern ini merusak kepercayaan tim dan menghilangkan nilai retrospective sebagai alat perbaikan berkelanjutan.

Praktik terbaik untuk menghindari anti-pattern tersebut meliputi: rotasi fasilitator agar perspektif segar masuk, penggunaan anonymous feedback tools seperti Miro atau FunRetro untuk topik sensitif, menyimpan retrospective log kumulatif lintas Sprint untuk mendeteksi pola berulang, dan yang paling penting — memastikan setiap retrospective menghasilkan setidaknya satu perubahan nyata yang dirasakan tim dalam waktu Sprint berikutnya. Tim yang matang juga menerapkan Prime Directive: setiap anggota tim telah melakukan yang terbaik mengingat situasi, pengetahuan, dan sumber daya yang tersedia saat itu, sehingga fokus diskusi adalah pada perbaikan proses, bukan menyalahkan individu.