Sprint Anti-Pattern: Demo Teater, Backlog Kuburan, Retro Tanpa Aksi
Sprint ceremony lengkap bukan tanda tim sehat. Kadang cuma teater. Tiga anti-pattern paling sering muncul di lapangan, semuanya kelihatan rapi di dashboard.
1. Demo teater
Sprint Review jadi panggung, bukan tempat belajar. Gejalanya:
- Demo disiapkan H-1, flow-nya di-script. Data dummy, klik urutan pasti.
- Yang demo cuma yang "aman". Fitur setengah jadi disembunyikan.
- Stakeholder cuma bilang "bagus" lalu pulang. Nol pertanyaan, nol feedback.
- Tim presentasi slide 20 halaman, bukan produk jalan.
Akibatnya: satu-satunya momen sinkron dengan user/pemilik produk dibuang. Bug ketemu di production, bukan di review.
Yang beneran: demo harus pakai data nyata kalau bisa, termasuk yang jelek. Sertakan yang belum selesai dan bilang "ini belum jalan, kami butuh masukan soal pendekatan". Demo yang memalukan itu sehat. Demo yang selalu mulus itu curiga.
2. Backlog kuburan
Backlog berisi 400 item, 80% gak pernah disentuh setahun. Item paling atas udah 6 bulan umurnya, requirement-nya udah berubah total tapi tiket masih di sana.
Ciri lain: - Prioritas ditentukan "yang paling atas dulu" tanpa alasan. - Ada tiket "improve performance" tanpa angka target, menggantung 2 tahun. - Semua orang takut hapus tiket — "nanti butuh". - Refinement cuma baca tiket, gak memotong yang mati.
Backlog bukan arsip keinginan. Backlog itu daftar kerja yang diyakini layak dikerjakan dalam waktu dekat. Sisanya sampah.
Aturan praktis: kalau item gak masuk sprint dalam 3 bulan terakhir dan gak ada tanggal target jelas, hapus atau taruh di tempat lain (misal label icebox). Kalau memang penting, orang akan mengangkatnya lagi. Kalau gak diangkat, berarti gak penting — dan itu informasi berharga.
3. Retro tanpa aksi
Retro tiap 2 minggu, semua bilang "komunikasi kurang", "estimasi meleset". Bulan depan kalimat sama, peserta sama, kursi sama. Gak ada yang berubah.
Penyebab umum: - Action item ditulis sebagai perasaan ("lebih komunikatif"), bukan aksi yang bisa dicek. - Action item 7 buah, gak ada yang punya nama. - Action item gak pernah masuk backlog sprint berikutnya, jadi kalah sama fitur. - Retro jadi sesi curhat, bukan sesi keputusan.
Perbaikan paling murah: maksimal 2 action item per sprint, masing-masing punya satu nama dan satu tanggal cek. Bawa hasilnya ke retro berikutnya di 5 menit pertama. Kalau action item sebelumnya gak jalan, bahas itu dulu sebelum nambah yang baru.
Contoh action yang bisa dicek: - Buruk: "Perbaiki handover antar tim." - Bagus: "Mulai Senin, tiap PR > 400 baris dipecah sebelum review. Dicek Rina di retro berikutnya."
Checklist cepat — audit sprint kamu minggu ini
- [ ] Demo terakhir: ada pertanyaan/feedback nyata dari luar tim? Kalau nol, ada masalah.
- [ ] Berapa umur tiket tertua di backlog? Di atas 6 bulan tanpa target = kandidat hapus.
- [ ] Retro terakhir menghasilkan berapa action item, dan berapa yang benar-benar jalan?
- [ ] Ada nama + tanggal di tiap action item?
- [ ] Ceremony mana yang kalau dihapus, gak ada yang berubah? Itu kandidat dihapus.
Satu hal yang bisa langsung dipakai
Buka backlog sekarang, urutkan berdasarkan tanggal dibuat, lihat 20 tiket tertua. Hapus atau tandai icebox yang udah gak relevan. 15 menit, dan refinement berikutnya jadi jauh lebih cepat karena yang dibahas cuma yang hidup.
Takeaway
Sprint yang sehat kelihatan agak berantakan: demo ada yang gagal, backlog pendek dan sering dipangkas, retro cuma punya 2 action item tapi dua-duanya jalan. Sprint yang kelihatan rapi biasanya cuma rapi di slide.