Bagaimana Cara Post-mortem Setelah Mengalami Kegagalan Proses Software Development

Pada metode software development yang menggunakan project, post-mortem biasanya dilakukan di akhir project untuk tujuan evaluasi dan perbaikan agar kita bisa continuous improvement atau kaizen. Di agile dan product development, biasanya tidak ada titik “akhir” karena product development akan berjalan terus sampai product itu berakhir life-cyclenya. Namun demikian, bukan berarti di agile atau product development kita tidak bisa atau tidak perlu melakukan post mortem. Salah satu kesempatan kita bisa melakukan post-mortem adalah setelah terjadi suatu masalah atau kegagalan.

Kegagalan dalam agile development hendaknya bukan menjadi hal yang sangat ditakuti dan dihindari. Agile megajarkan untuk dapat beradaptasi, termasuk saat menemui kegagalan. Dalam inovasi, kegagalan adalah suatu kesempatan untuk memperbaiki. Dari kegagalan kita bisa belajar dan improve.

Di dalam proses development software, kadang terjadi kegagalan saat proses deployment aplikasi atau bahkan setelah go live. Selain perlu segera diperbaiki atau di-rollback, penting juga untuk mengevaluasi kegagalan tersebut. Dalam semangat agile, kita mengevaluasi kegagalan sebagi kesempatan pembelajaran, bukan untuk menyalahkan seseorang.

Saya pernah mengalami kegagalan saat migrasi database. Database sukses dimigrasi, namun saat aplikasi diakses, performanya sangat lambat. Akhirnya diputuskan untuk rollback ke kondisi sebelum migrasi. Saya pun meminta lead developer untuk melakukan post-mortem dan membaginya ke tim lain. Namun saat sesi post-mortem diadakan, yang terjadi adalah sesi seperti retrospective biasa dan yang diundang hanya satu squad saja. Padahal saya berharap sesi ini bisa menjadi kesempatan untuk improvement proses dan pembelajaran untuk tim lain agar tidak mengalaminya juga.

Sebenarnya seperti apa sih post-mortem yang baik? Mari kita bahas.

Mindset yang diperlukan saat post-mortem

Jangan saling menyalahkan

Tidak saling menyalahkan sangat penting untuk membuat semua orang bisa mengluarkan pendapat dengan tenang dan aman.

Open-minded, terbuka terhadap saran dan kritik, konstruktif

Dalam setiap event yang bertipe evaluasi atau retrospective, sangat penting untuk berada dalam mindset yang terbuka dan tidak defensif. Begitu pun dalam post-mortem. Hendaknya semua hadir dengan spirit untuk mencari perbaikan, improvement. Apabila ada saran, terimalah dengan baik, jangan langsung ditolak karena ego. Jangan lihat siapa yang berbicara, tapi apa yang dikatakan.

Partisipasi aktif

Post-mortem perlu dilakukan sebagai sebuah team. Artinya bukan hanya satu orang saja yang berbicara. Bukan hanya technical leadnya saja misalnya, tapi developer atau devops juga sebaiknya berbicara dan memberikan pendapat.

Persiapan post-mortem

Pilih Moderator

Seperti meeting lainnya, post-mortem akan jauh lebih efektif dan efisien apabila ada satu orang yang bertindak sebagai moderator dan mengatur jalannya diskusi. Biasanya yang menjadi moderator adalah orang yang menginisiasi dan mengundang meeting, biasanya orang yang memegang peranan sebagai Scrum Master atau Technical Lead.

Moderator juga hendaknya mencatat input improvement yang muncul selama meeting dan nantinya akan mendokumentasikan dan membagikannya.

Agenda

Adanya agenda cukup penting agar suatu meeting post-mortem tidak berputar lama di satu bagian saja. Kadang kala apabila tidak ada agenda, kita akan terlalu fokus membahas tentang masalah yang terjadi, akhirnya kita kekurangan waktu untuk membahas improvementnya.

Berikut contoh agenda yang bisa dilakukan:

1. Pembukaan (5 menit) – Di bagian ini hendaknya moderator meeting menjelaskan kembali tujuan dari post-mortem serta bagaimana interaksi yang diharapkan. Dengan melakukan ini, semua peserta akan memiliki mindset dan ekspektasi yang serupa.
2. Recap kejadian (15 menit) – Salah satu anggota tim dapat menceritakan tentang kronologis kegiatan, masalah apa yang terjadi, lalu apa yang telah dilakukan untuk recovery.
3. Pertanyaan (15 menit) – Para peserta bisa mengajukan pertanyaan untuk memperjelas hal-hal detail untuk membantu analisa kejadian.
4. 3 question (20 menit) – Para peserta bersama-sama mengisi 3 pertanyaan retrospective yaitu apa yang berjalan baik, apa yang berjalan kurang baik, apa yang bisa dilakukan berbeda (improvement)
5. Kesimpulan dan penutup (5 menit) – Baca ulang improvement plan yang akan dilakukan dan dapatkan komitmen tim untuk melaksanakannya.

Materi yang akan dibahas

Agar acara post-mortem berjalan efektif dan efisien, sebaiknya materi yang akan dibahas telah dipersiapkan terlebih dahulu, materi ini bisa berupa:

• Kronologis kejadian
• Screenshot-screenshot
• Bukti-bukti lain (email, chat, dll)

Akan lebih baik apabila materi ini dapat dirangkum kedalam format presentasi agar pembahasan lebih terstruktur dan tidak ada yang lupa.

Menjalankan meeting post-mortem

Kapan meeting post-mortem dilakukan

Sebaiknya post-mortem dilakukan segera setelah terjadinya masalah. Hal ini agar semua peserta di dalamnya masih memiliki memory yang fresh sehingga bisa lebih jelas saat membedah dan mencari improvementnya.

Sebaiknya jangan saat sprint retrospective, namun membuat meeting khusus. Apalagi bila ingin mengundang tim lain juga.

Yang dibahas di meeting post-mortem

Di dalam meeting post-mortem, masalah yang terjadi kan dibahas. Agar pembahasan menjadi lebih terstruktur, sebaiknya dimulai dengan pembahasan tentang masalah yang terjadi, kronologisnya, dampaknya, dan recovery yang dilakukan. Hal ini penting agar semua peserta memiliki konteks yang sama tentang hal yang akan dibahas.

Pembahasan masalah inilah yang membedakan post-mortem dengan retrospective biasa.

Setelah itu bisa dilanjutkan dengan tiga pertanyaan yang biasa ditanyakan saat retrospective yaitu:

1. Apa yang berjalan dengan baik dan perlu kita lanjutkan?
2. Apa yang berjalan kurang baik dan perlu kita hentikan atau perbaiki?
3. Apa yang bisa dilakukan berbeda lain kali?

Saya biasanya mengisi dan membahas pertanyan tersebut satu-persatu, tidak sekaligus ketiganya. Di pertanyaan pertama kita membuat mood yang baik dan positif agar tim termotivasi. Setelah pertanyaan pertama selesai dibahas, baru lanjut ke pertanyaan kedua, untuk pertanyaan kedua, sebisa mungkin dibuat anonymous atau jangan diberi nama, agar bebas mengeluarkan pendapat. Setelah pertanyaan kedua dibahas, kita bisa tahu hal yang perlu kita perbaiki dan kita bahas di pertanyaan ketiga.

Hasil post-mortem

Improvement action

Tujuan utama post-mortem adalah untuk pembelajaran agar hal yang sama tidak terulang. Agar improvement itu menjadi nyata, hendaknya dirumuskan point-point yang akan dilakukan agar tidak terjadi kesalahan lagi. Misalnya pada kegagalan deployment, improvement actionnya berupa:

• Sebelum deployment perlu dibuat deployment list
• Sebelum deployment perlu dibuat full backup seluruh aplikasi dan database
• Setelah deployment dilakukan testing untuk memastikan fungsi utama bekerja dengan baik

Dokumentasikan dan bagikan

Idealnya setelah post-mortem selesai, dibuat semacam dokumen yang dapat dilihat oleh orang lain di masa depan. Dokumen ini akan mencatat secara rinci tentang apa yang terjadi, kenapa terjadi, bagaimana recovery, dan pencegahannya di kemudian hari. Yang juga penting adalah dokumen ini perlu diletakkan di tempat yang bisa diakses oleh banyak orang, maksudnya bukan sekedar buat dokumen lalu disimpan di hardisk pribadi, namun hendaknya di share di repository, wiki perusahaan, atau tool semacam Confluence. Dengan mencatatnya, apabila di masa depan akan ada kegiatan yang sama, tim bisa dengan mudah melihat list improvementnya.