Ringkasan singkat
Retrospektif tanpa menyalahkan menganggap orang membuat keputusan yang masuk akal dengan informasi yang mereka punya. Rapat mencari kondisi yang membuat kesalahan menjadi mungkin: peringatan yang hilang, runbook yang membingungkan, jendela deploy, tinjauan yang tidak bisa melihat risikonya. Anda tetap menamai apa yang terjadi. Anda tidak menamai seorang pelaku sebagai perbaikannya.
Definisi itu mencakup dua rapat yang sering dicampur orang. Retro sprint bisa tanpa menyalahkan tentang cara tim bekerja. Retro insiden tanpa menyalahkan tentang satu kegagalan, dan butuh linimasa.
Apa arti “tanpa menyalahkan”, dan apa yang bukan artinya
Ini tidak berarti tidak ada yang bertanggung jawab. Seseorang tetap memiliki perubahan berikutnya pada peringatan, runbook, atau peluncuran. Artinya tindakannya adalah perubahan sistem. “Jordan harus lebih hati-hati” adalah menyalahkan. “Deploy produksi membutuhkan orang kedua pada hari Jumat setelah pukul 16:00, dimiliki oleh pimpinan piket, ditinjau dalam dua minggu” adalah tindakan tanpa menyalahkan.
Ini juga tidak berarti rapat yang lunak tanpa fakta. Retro tanpa menyalahkan yang tidak punya linimasa menjadi lingkaran perasaan, dan pemadaman yang sama kembali.
Prime Directive Norm Kerth adalah garis awal yang biasa: dengan informasi yang mereka punya, orang melakukan yang terbaik yang mereka bisa. Ucapkan di awal jika ruangannya tegang. Lalu beralih ke linimasa. Kalimat itu bukan seluruh rapat.
Tanpa menyalahkan dalam retro sprint biasa
Anda tidak butuh pemadaman. Pakai bahasa tanpa menyalahkan ketika kartu mulai menamai orang:
- Ganti “Alex merusak build” dengan “build tetap merah sehari karena pemeriksaan yang gagal tidak diwajibkan pada pull request.”
- Ganti “produk terus mengubah cakupan” dengan “tiga cerita mengubah kriteria penerimaan setelah pengembangan dimulai.”
Lalu voting dan pilih sebuah perubahan sistem. Sisa agendanya adalah retrospektif sprint yang biasa: kartu senyap, sebuah voting, satu sampai tiga tindakan.
Cara menjalankan retrospektif insiden tanpa menyalahkan
Jalankan ini dalam beberapa hari setelah insiden, bukan pada retro sprint berikutnya. Undang orang yang ada di respons, plus satu fasilitator yang bisa menghentikan penyalahan. Batasi 45–60 menit untuk satu insiden.
1. Tulis linimasa sebelum rapat (15 menit, asinkron)
Daftar bersama, yang tertua lebih dulu:
- kapan sinyal pertama menyala, atau kapan pelanggan menulis
- kapan seseorang melihatnya
- apa yang mereka yakini sedang terjadi
- apa yang mereka ubah
- kapan dampaknya berhenti
Minta setiap orang menambahkan langkah yang mereka ambil. Lakukan secara tertulis supaya rapat bukan lomba ingatan. Kartu anonim membantu untuk baris “apa yang saya yakini” jika orang mengharapkan hukuman.
2. Buka aturannya (2 menit)
Katakan: kita tidak akan menunjuk seseorang sebagai penyebab. Kita akan pergi dengan perubahan pada deteksi, keputusan, atau pemulihan. Jika sebuah nama muncul, tulis kondisi di sekitar orang itu.
3. Telusuri linimasa (15 menit)
Bacalah berurutan. Tanya hanya: apa yang kita ketahui pada menit ini, dan apa yang perkakas tunjukkan? Perbaiki waktunya. Jangan lompat ke “apa yang seharusnya kita lakukan” dulu.
4. Temukan kondisi yang berkontribusi (15 menit)
Kelompokkan catatan ke tiga kolom:
- Deteksi: peringatan hilang, peringatan berisik, dasbor yang tidak dibuka siapa pun
- Keputusan: runbook salah, pemilik tidak jelas, dua orang membuat perubahan yang berlawanan
- Pemulihan: rollback lambat, flag fitur macet, pesan pelanggan terlambat
Kolom-kolom ini menahan percakapan pada sistem. Kartu yang hanya menyebut sebuah nama tidak mendapat suara.
5. Pilih satu sampai tiga perbaikan (10 menit)
Setiap perbaikan menamai kondisi, perubahan, seorang pemilik, dan sebuah tanggal. Utamakan satu perbaikan deteksi. Insiden yang tidak memanggil siapa pun akan terjadi lagi, sehati-hati apa pun insinyurnya.
Kirim linimasa dan tindakan ke tim. Jangan simpan dokumen di tempat yang hanya fasilitator yang bisa menemukannya. Tinjau tindakan pada retro sprint berikutnya, pada lima menit pertama.
Bahasa yang bisa Anda perbaiki di ruangan
| Menyalahkan | Tanpa menyalahkan |
|---|---|
| Siapa yang merilis ini? | Pemeriksaan mana yang tidak berjalan sebelum rilis? |
| Mereka seharusnya tahu | Apa yang dasbor tunjukkan pada menit itu? |
| Kesalahan manusia | Langkah mana yang tidak ada tinjauan kedua, dan mengapa itu normal? |
Pertanyaan yang sering diajukan
Apa itu retrospektif tanpa menyalahkan?
Ini retrospektif yang memperlakukan kegagalan sebagai sifat sistem. Orang menggambarkan apa yang mereka ketahui pada saat itu. Tindakan mengubah peringatan, runbook, tinjauan, atau aturan peluncuran. Nama seseorang bukan tindakan korektifnya.
Bagaimana cara menjalankan retrospektif insiden tanpa menyalahkan?
Tulis linimasa sebelum rapat, larang “siapa yang menyebabkan ini” sebagai hasilnya, urutkan catatan ke deteksi, keputusan, dan pemulihan, lalu pergi dengan satu sampai tiga perubahan sistem yang punya pemilik. Pisahkan dari retro sprint.
Apakah postmortem tanpa menyalahkan hal yang sama?
Ya untuk tujuan ini. Postmortem, tinjauan insiden, dan retrospektif insiden adalah rapat yang sama ketika memakai linimasa dan menolak penyalahan sebagai perbaikannya. Retrospektif sprint adalah rapat yang berbeda tentang seluruh sprint.
Mulai papan gratis dan letakkan Deteksi, Keputusan, dan Pemulihan pada kolom. Peserta bisa bergabung dari tautan tanpa akun.
