Sprint Retrospective dan AI: mengapa perbaikan tidak bisa didelegasikan ke model

Ini adalah artikel kelima dari seri tentang bagaimana AI mengubah rapat klasik tim pengembangan lintas fungsi. Di bagian sebelumnya saya membahas Backlog Refinement, Sprint Planning, Daily Scrum dan Sprint Review. Kesimpulan umum secara bertahap menjadi lebih tegas: AI baik dalam mengumpulkan bahan untuk percakapan, tetapi tidak boleh menggantikan percakapan itu sendiri. Dalam Sprint Retrospective batas ini sangat penting, karena di sini tim membahas bukan hanya tugas dan produk, tetapi juga kebiasaan mereka sendiri, interaksi, kualitas, dan kemampuan untuk berubah.

Sprint Retrospective tampak seperti kandidat yang sangat cocok untuk AI. Di akhir sprint sudah ada Jira, Git, pull request, CI/CD, insiden, chat, kalender, catatan Daily Scrum, keputusan dari Sprint Review, kadang juga survei singkat tim. Model dapat dengan cepat mengumpulkan: apa yang paling sering menghambat pekerjaan, di mana terjadi review bottleneck, tugas mana yang berpindah dari hari ke hari, di mana Definition of Done ternyata tidak jelas, keputusan apa yang berulang, topik apa yang muncul di retrospektif sebelumnya dan belum hilang.

Sekilas ini hampir otomatisasi yang sempurna. Tidak perlu mengingat kembali seluruh sprint. Tidak perlu berdebat apakah menunggu review adalah masalah nyata atau hanya perasaan seseorang. Tidak perlu memeriksa secara manual puluhan tiket dan cabang diskusi. AI dapat menyiapkan fakta, mengelompokkan pola, menawarkan root cause analysis, dan bahkan menghasilkan action item untuk sprint berikutnya.

Tetapi justru di sinilah risiko utamanya dimulai.

Sprint Retrospective tidak ada untuk menghasilkan daftar perbaikan yang rapi. Maknanya adalah agar tim melihat secara jujur bagaimana mereka bekerja, menyepakati apa yang perlu diubah, dan mengambil tanggung jawab atas perubahan itu. Jika AI mengubah retrospektif menjadi daftar rekomendasi, tim bisa mendapatkan dokumen yang indah tetapi kehilangan hal terpenting: psychological safety, pemahaman bersama tentang masalah, dan follow-through yang nyata.

“AI dapat menyoroti pola, tetapi perbaikan hanya dimulai ketika tim mengakui masalah dan mengubah perilakunya.”

Mengapa Sprint Retrospective diperlukan

Dalam Scrum Guide 2020 Sprint Retrospective dijelaskan dengan sangat praktis: tim merencanakan cara meningkatkan kualitas dan efektivitas. Untuk itu Scrum Team menginspeksi bagaimana sprint berjalan dari sudut pandang orang, interaksi, proses, alat, dan Definition of Done. Tim membahas apa yang berjalan baik, masalah apa yang muncul, dan bagaimana masalah tersebut telah atau belum diselesaikan. Kemudian tim menentukan perubahan yang paling bermanfaat, dan perbaikan yang paling signifikan harus ditangani secepat mungkin dan dapat masuk ke Sprint Backlog sprint berikutnya.

Artinya retrospektif bukanlah pelepasan emosi di akhir sprint. Dan bukan pula seremoni formal di mana tiga kolom harus diisi: apa yang baik, apa yang buruk, apa yang akan diperbaiki. Acara ini tentang adaptasi cara kerja. Dalam pengertian ini ia terkait langsung dengan logika umum Scrum: transparansi diperlukan untuk inspeksi, inspeksi diperlukan untuk adaptasi, dan inspeksi tanpa adaptasi menjadi kosong. Scrum Guide secara tegas menekankan: acara Scrum dirancang untuk memicu perubahan, bukan sekadar menghasilkan catatan.

Sebagai acuan tambahan, Scrum Guide Expanded v2026.1berguna, tetapi tepatnya sebagai sumber pendamping berbasis Scrum Guide 2020, bukan sebagai versi kanonik baru Scrum Guide. Untuk artikel ini ia penting karena dua hal. Pertama, ia menyatakan bahwa refleksi lebih efektif dalam lingkungan yang aman secara psikologis. Kedua, di bagian tentang AI ia menggambarkan model sebagai supervised decision-making partner: AI dapat memperkuat transparansi, inspeksi, dan adaptasi, tetapi tidak menggantikan tanggung jawab manusia dan tidak menghapus kontrol empiris atas proses.

Karena itu saya akan menggambarkan tujuan Sprint Retrospective melalui lima fungsi:

• melihat pola kerja tim yang nyata, bukan hanya opini yang paling lantang;
• membahas interaksi, proses, alat, dan Definition of Done tanpa takut hukuman;
• memisahkan fakta dari interpretasi dan dugaan;
• memilih sejumlah kecil perbaikan yang benar-benar siap dicoba oleh tim;
• memindahkan perbaikan tersebut ke sprint berikutnya sehingga memiliki owner, kriteria verifikasi, dan tempat dalam pekerjaan.

Ini adalah kerangka untuk membahas AI. Jika alat membantu tim menjalankan fungsi-fungsi ini dengan lebih baik, ia bermanfaat. Jika ia hanya membuat daftar action item yang lebih indah, ia mungkin nyaman, tetapi belum tentu membuat tim lebih efektif.

Apa yang biasanya salah

Masalah retrospektif jarang terletak pada ketidakmampuan tim menyebutkan masalah. Biasanya masalahnya lain. Tim kembali membahas hal yang sama. Action item berpindah dari sprint ke sprint. Orang berbicara hati-hati karena tidak ingin terlihat bersalah. Topik paling menyakitkan dihindari. Scrum Master mengeluarkan format, tetapi tidak mengeluarkan perubahan. Pada akhirnya semua setuju dengan sesuatu seperti "mari kita berkomunikasi lebih baik", dan itu larut sudah pada minggu berikutnya.

Penelitian Lehtinen, Itkonen, dan Lassenius dalam Empirical Software Engineering menyoroti sisi retrospektif ini dengan baik. Para penulis mempelajari 37 retrospektif tingkat tim selama hampir tiga tahun dan menunjukkan beberapa hal penting: diskusi sering menyentuh topik yang dekat dan dapat dikelola tim, tetapi dapat menderita participant bias; tanpa hard evidence diskusi tidak selalu mencerminkan realitas; beberapa topik berulang lama karena entah secara alami kembali, atau tim tidak dapat menyelesaikannya pada level mereka sendiri karena kompleksitas atau kurangnya kendali.

Ini adalah kerangka yang sangat berguna untuk AI. Model memang dapat membantu membawa hard evidence ke tempat yang sebelumnya hanya ada perasaan. Misalnya, tim berkata: "review memperlambat sprint". AI dapat mengangkat fakta: berapa banyak PR yang menunggu lebih dari sehari, mana yang macet, komentar apa yang berulang, di mana ada pengerjaan ulang setelah merge. Ini lebih berguna daripada berdebat berdasarkan ingatan.

Tetapi kerangka yang sama memiliki sisi sebaliknya. Jika tim tidak ingin membicarakan penyebab yang tidak nyaman, AI tidak akan membuatnya lebih jujur. Jika masalah berada di luar zona pengaruh tim, model dapat merumuskan action item dengan indah yang tetap tidak akan dijalankan siapa pun. Jika orang tidak mempercayai konteksnya, mereka akan berdebat bukan lagi tentang proses, melainkan tentang apakah AI menggambarkan pekerjaan mereka dengan benar.

Di mana AI benar-benar membantu

AI dalam Sprint Retrospective memiliki zona manfaat yang kuat, jika tidak mencoba menyerahkan perbaikan itu sendiri kepadanya. Saya akan menggunakannya sebelum retro dan setelah retro, bukan sebagai pengganti retro.

Tetapi di sini penting untuk tidak menjanjikan terlalu banyak. DORA State of AI-assisted Software Development 2025 menggambarkan AI sebagai penguat kekuatan dan kelemahan yang sudah ada dalam sistem organisasi. Untuk retrospektif ini hampir merupakan rumusan yang ideal: jika tim sudah mampu mendiskusikan proses secara jujur dan membawa perbaikan hingga menjadi tindakan, AI akan membuat masukannya lebih kaya. Jika retro sudah lama menjadi ritual aman tanpa follow-through, AI hanya akan membuat ritual itu lebih cepat dan lebih rapi.

Sebelum pertemuan AI dapat menyiapkan masukan untuk inspeksi:

• mengumpulkan impediments berulang dari Daily Scrum, tiket, pull request, dan incident notes;
• menemukan tempat di mana work item lama menunggu review, data pengujian, keputusan Pemilik Produk, atau dependensi eksternal;
• membandingkan rencana dengan Sprint Planning, keputusan aktual selama sprint, dan hasil yang dibahas pada Sprint Review;
• menyoroti ketidaksesuaian antara Definition of Done dan cara tim sebenarnya menutup tugas;
• mengumpulkan action item lama dan menunjukkan mana yang telah dilakukan, dilupakan, atau berulang;
• merumuskan pertanyaan kandidat untuk percakapan: apa yang merupakan fakta, apa yang merupakan interpretasi, dan apa yang memerlukan verifikasi.

Setelah pertemuan AI dapat membantu dengan follow-through: mencatat action item yang dipilih dengan rapi, menambahkan owner, kriteria verifikasi, keterkaitan dengan Sprint Backlog, dan pengingat untuk retrospektif berikutnya. Ini sangat berharga karena titik lemah banyak retro bukan pada diskusi, melainkan pada kenyataan bahwa perbaikan tidak bertahan hingga sprint berikutnya.

Tetapi dalam semua skenario ini AI tetap menjadi lapisan persiapan dan pendukung. Ia tidak boleh memutuskan masalah mana yang utama. Ia tidak boleh menunjuk pihak yang bersalah. Ia tidak boleh menentukan root cause sebagai fakta. Dan ia jelas tidak boleh secara otomatis menulis "rencana perbaikan tim" tanpa verifikasi langsung.

Mengapa AI tidak boleh memimpin retrospektif untuk tim

Versi paling berbahaya dari AI-assisted Retrospective terlihat matang. Model mengumpulkan semua data, menganalisis suasana tim, menemukan "tiga penyebab utama masalah", mengusulkan action item, dan mengirim ringkasan ke Slack atau Confluence. Semua orang membaca, mengangguk, memberi reaksi, dan retro menjadi lebih singkat. Kadang tim bahkan mulai berpikir: jika AI sudah menganalisis semuanya, mengapa menghabiskan satu jam untuk berbicara?

Masalahnya adalah retrospektif bernilai bukan hanya karena kesimpulannya. Ia bernilai karena proses pemahaman bersama. Penting bagi tim bukan sekadar mendapatkan pernyataan "review memakan terlalu banyak waktu". Tim perlu menyepakati mengapa itu terjadi, apa yang bersedia diubah, kompromi apa yang diterima, dan siapa yang mengambil tindakan. Kadang dalam percakapan ini muncul hal yang tidak terlihat dari data: ketakutan berdebat dengan developer yang kuat, kejengkelan karena konteks produk yang tidak jelas, kelelahan karena tugas mendesak yang terus-menerus, ketidaksetujuan diam-diam terhadap Definition of Done saat ini.

Karya klasik Amy Edmondson tentang psychological safety dan learning behavior penting di sini bukan sebagai rujukan yang sedang tren, melainkan sebagai pedoman praktis. Jika orang tidak merasa dapat membicarakan masalah tanpa risiko interpersonal, retrospektif berubah menjadi perumusan yang aman. AI dalam situasi seperti ini dapat membuat protokol lebih lancar, tetapi tidak membuat tim lebih jujur.

Lebih jauh, AI dapat memperburuk kejujuran jika tim memandangnya sebagai pemantauan. Jika model membaca Slack, Jira, komentar PR, dan kalender, lalu menulis "Aleksey lambat merespons review" atau "QA sering menunda kesiapan data", itu bukan lagi dukungan retrospektif. Itu performance management dengan kedok perbaikan proses. Dalam lingkungan seperti itu, orang mulai mengoptimalkan aktivitas yang terlihat, berdebat dengan model, dan melindungi reputasi alih-alih membahas proses yang sebenarnya.

Itulah sebabnya sumber seperti NIST Generative AI Profile, OWASP Top 10 for LLM Applications 2025, EDPB Opinion 28/2024 dan materi ICO tentang monitoring at work relevan di sini. Bukan sebagai bagian hukum artikel, melainkan sebagai pengingat: data retrospektif mudah menjadi sensitif. Data itu menyangkut orang, perilaku, konflik, kesalahan, keterlambatan, korespondensi, dan kadang titik lemah manajemen.

Batas praktisnya sederhana: AI dalam retro harus menganalisis work and system, not people. Yaitu pekerjaan yang macet, ekspektasi yang berulang, aturan yang tidak jelas, celah dalam Definition of Done, handoff yang buruk, titik proses yang kelebihan beban. Bukan "siapa yang bekerja buruk", melainkan "apa dalam sistem yang membuat kita kembali ke hasil yang sama".

“AI-input yang baik untuk retro melihat pekerjaan yang macet dan pola yang berulang. AI-input yang buruk mengubah orang menjadi baris laporan.”

Mari lanjutkan kasus: B2B LMS dan email-reminder

Ambil kasus yang sama dari artikel sebelumnya: platform B2B LMS, kursus wajib, email-reminder kepada karyawan yang belum menyelesaikan kursus wajib sebelum tenggat. Pada Sprint Planning tim memilih Sprint Goal yang sempit: sistem mengirim satu reminder yang benar kepada karyawan aktif dengan kursus wajib yang belum selesai sebelum tenggat dan menyimpan riwayat pengiriman yang dapat diverifikasi. Pada Daily Scrum tim memantau risiko deduplikasi, zona waktu, dan data uji. Pada Sprint Review tim membahas apa artinya ini bagi produk dan Product Backlog.

Kini tibalah Sprint Retrospective. Tanpa AI percakapan bisa cepat beralih ke perasaan yang biasa. Backend berkata: "kami terhambat oleh klarifikasi eligibility". QA berkata: "data uji datang terlambat". Frontend berkata: "API berubah di tengah sprint". Product owner berkata: "kami tidak menduga begitu banyak pertanyaan tentang expired". Scrum master mencatat: "perbaiki komunikasi", "siapkan data lebih awal", "kurangi perubahan requirement". Kelihatannya retro sudah dilakukan.

AI dapat membuat input lebih konkret. Ia mengangkat riwayat sprint dan menunjukkan:

• empat PR menunggu review lebih dari sehari, dan semuanya terkait retry logic dan idempotency;
• interpretasi eligibility untuk pengguna yang dinonaktifkan berubah tiga kali;
• data QA muncul tiga hari lebih lambat dari yang tim harapkan pada planning;
• Definition of Done tidak mewajibkan riwayat pengiriman yang dapat diverifikasi untuk skenario negatif;
• action item lama "kurangi ukuran PR" tidak dijalankan dan terulang sebagai masalah;
• sebagian diskusi di Slack bukan tentang implementasi, melainkan tentang tidak adanya keputusan bersama soal expired.

Ini input yang baik. Tetapi ini belum retrospektif.

Retrospektif dimulai ketika tim membahas apa dari ini yang benar-benar akan diubah. Misalnya, tim dapat memutuskan: bukan "berkomunikasi lebih awal", melainkan "pada planning secara eksplisit mencatat status eligibility yang diperdebatkan dan keputusan product owner-nya". Bukan "QA menyiapkan data lebih cepat", melainkan "dalam Sprint Backlog ditambahkan work item terpisah untuk data uji sebelum implementasi skenario kritis dimulai". Bukan "membuat lebih sedikit PR", melainkan "untuk perubahan pada notification architecture PR harus muat dalam satu skenario review dan memiliki owner untuk review sebelum pekerjaan dimulai". Bukan "perbaiki DoD", melainkan "Definition of Done kini mencakup riwayat pengiriman yang dapat diverifikasi untuk skenario negatif reminder".

Inilah action items. Konkret, dapat diverifikasi, dan terkait dengan sprint berikutnya. AI membantu melihat pola. Tim memilih perubahan.

Anti-patterns

Berikut beberapa anti-pattern yang akan saya pantau secara khusus saat menerapkan AI dalam Sprint Retrospective.

1. Ringkasan AI menggantikan percakapan langsung

Jika tim hanya membaca ringkasan yang dihasilkan dan menyetujuinya, retro kehilangan hal utama. Pertanyaan yang baik bukan "apakah AI menggambarkan sprint dengan tepat?", melainkan "apa dari ini yang siap kita ubah dalam cara kerja kita?".

2. Sentiment analysis berubah menjadi kebenaran tentang tim

Analisis sentimen bisa menjadi sinyal lemah yang berguna, tetapi ia tidak mengetahui konteks. Sarkasme, kelelahan, konflik lokal, lelucon, diam, dan perumusan yang hati-hati sulit diubah menjadi metrik. Suasana hati tim tidak boleh direduksi menjadi grafik.

3. AI mencari pihak yang bersalah alih-alih pola sistemik

Segera setelah model mulai memberi peringkat pada orang berdasarkan kecepatan, aktivitas, atau jumlah "blocker yang dibuat", retrospektif berubah menjadi pemantauan. Ini merusak psychological safety dan menurunkan kualitas informasi yang bersedia dibawa orang.

4. Root cause diterima tanpa verifikasi

Model dapat dengan yakin menulis: "penyebab utama keterlambatan adalah persyaratan yang tidak jelas". Tetapi itu mungkin hanya bagian yang terlihat. Penyebab sebenarnya bisa berupa architectural debt, konflik prioritas, tidak adanya data pengujian, atau ketakutan untuk mengeskalasi masalah. Root cause dari AI adalah hipotesis, bukan fakta.

5. Action item menjadi terlalu umum

"Tingkatkan komunikasi", "review lebih cepat", "persiapan lebih baik" hampir tidak pernah mengubah perilaku. Action item yang baik harus menjawab pertanyaan: siapa yang melakukannya, apa tepatnya yang diubah, di mana itu terlihat di sprint berikutnya, dan bagaimana tim akan memverifikasi efeknya.

6. Perbaikan tidak masuk ke Sprint Backlog

Scrum Guide mengizinkan perbaikan paling signifikan masuk ke Sprint Backlog sprint berikutnya. Jika tim memilih perbaikan tetapi tidak mengalokasikan perhatian, owner, dan tempat dalam pekerjaan untuknya, itu bukan improvement. Itu hanya harapan.

Bagaimana peran berubah

AI tidak membatalkan zona tanggung jawab di dalam Scrum Team, tetapi mengubah persiapan untuk percakapan. Nilai untuk memulihkan sejarah sprint secara manual berkurang. Nilai untuk interpretasi yang jujur, memilih eksperimen kecil, dan membawa perbaikan hingga hasil menjadi lebih besar.

Peran	Risiko pada skenario AI yang buruk	Penggunaan AI yang matang
Developer	Berdebat dengan penilaian AI atas aktivitas mereka dan mempertahankan reputasi alih-alih membahas proses.	Menggunakan fakta dan pola sebagai input, tetapi mereka sendiri memilih apa yang harus diubah dalam praktik engineering, review, DoD, dan handoff.
Product Owner	Membaca retro AI sebagai laporan kinerja tim dan menekan kecepatan.	Membantu menghilangkan ambiguitas produk, memperjelas keputusan yang menghambat tim, dan mendukung perbaikan di Sprint Backlog berikutnya.
Scrum Master	Menyerahkan fasilitasi kepada model dan mendapatkan notulen yang rapi alih-alih percakapan yang jujur.	Menggunakan input AI untuk persiapan, tetapi melindungi psychological safety, fokus pada sistem, dan follow-through action item yang dipilih.
Quality Engineer / QA Engineer	Mendapat peran "sumber keterlambatan" jika model secara dangkal mengaitkan masalah dengan pengujian.	Membantu menerjemahkan sinyal kualitas menjadi perubahan pada Definition of Done, kepemilikan test-data, dan observabilitas.
UX/UI Designer	Tersisih dari retro karena AI terutama menganalisis kode, PR, dan tugas pengembangan.	Menyoroti interaksi, keputusan, dan konteks pengguna yang memengaruhi kualitas kerja tim dan produk.
Engineering Lead / Tech Lead	Menggunakan retro AI sebagai dashboard kontrol atas engineer.	Membantu membedakan bottleneck engineering sistemik dari aktivitas individu dan memilih perbaikan teknis yang benar-benar muat di sprint berikutnya.

Filter praktis untuk AI-assisted Retrospective

Saya tidak akan memulai dengan ide "biarkan AI memimpin retro". Saya akan memulai dengan pertanyaan yang lebih sempit: input apa yang akan membantu tim memeriksa cara kerja secara lebih jujur dan memilih satu-dua perbaikan yang benar-benar akan mereka lakukan?

Input AI untuk Sprint Retrospective berguna jika membantu menjawab pertanyaan:

• masalah mana yang berulang dan mana yang hanya sekali;
• fakta mana yang mendukung tema dan mana yang merupakan opini atau penilaian emosional;
• apa yang berada dalam zona pengaruh tim dan apa yang memerlukan bantuan Supporters, manajemen, atau tim lain;
• action item lama mana yang tidak diselesaikan dan mengapa;
• satu proses, alat, working agreement, atau Definition of Done mana yang layak diubah di sprint berikutnya;
• bagaimana tim akan memverifikasi bahwa perubahan itu berhasil.

Dan sebaliknya: jika input AI terutama menjawab pertanyaan "siapa yang menjadi bottleneck", itu sinyal berbahaya. Retrospektif harus membantu tim memperbaiki sistem kerja, bukan menghasilkan peringkat tersembunyi para peserta.

Data dan batasan

Sprint Retrospective sangat sensitif terhadap data karena AI mudah mulai mengumpulkan hal-hal yang dianggap orang sebagai pribadi: pesan di chat, kecepatan respons, nada komentar, waktu reaksi terhadap PR, partisipasi dalam rapat, kesalahan berulang, konflik dalam diskusi. Semakin luas akses, semakin meyakinkan analisisnya. Tetapi semakin tinggi risiko kebocoran konteks sensitif, ketergantungan berlebihan pada output model, dan perubahan retro menjadi employee monitoring.

Secara praktis saya akan menetapkan beberapa aturan sebelum menerapkan AI dalam retro:

• gunakan set sumber minimal yang diperlukan untuk pertanyaan retro;
• jangan menganalisis pesan pribadi tanpa kesepakatan dan kebutuhan yang jelas;
• jangan membuat peringkat personal, score, dan kesimpulan tentang performance management;
• tunjukkan kepada tim data apa yang digunakan dan apa yang dikecualikan;
• pisahkan fakta dari interpretasi yang dihasilkan;
• verifikasi kesimpulan penting pada sumber aslinya;
• hapus atau batasi penyimpanan ringkasan AI jika mengandung konteks tim yang sensitif.

Ini bukan birokrasi. Ini adalah syarat untuk percakapan yang jujur. Jika orang tidak memahami apa yang sebenarnya dibaca model dan bagaimana outputnya digunakan kemudian, mereka akan berbicara lebih hati-hati. Dan retrospektif yang hati-hati hampir selalu menghasilkan perbaikan yang aman tetapi lemah.

Jadi apa yang sebenarnya berubah

AI memang dapat membuat Sprint Retrospective lebih bermanfaat. AI dapat menurunkan biaya persiapan, membawa fakta ke dalam percakapan, menunjukkan pola yang berulang, mengingatkan tentang action item yang belum selesai, menyoroti ketidaksesuaian dengan Definition of Done, dan membantu mengubah "perlu ditingkatkan" yang kabur menjadi eksperimen sprint berikutnya yang konkret.

Tetapi ini hanya berhasil jika tim memahami batasannya: AI menyiapkan materi untuk inspeksi, bukan melakukan adaptasi atas nama tim. AI membantu melihat data, tetapi tidak menciptakan rasa aman psikologis. AI dapat menyarankan root cause, tetapi tidak tahu apa yang orang takutkan untuk bicarakan. AI dapat menulis action item, tetapi tidak mengambil peran owner dan tidak mengubah perilaku pada sprint berikutnya.

Karena itu, tesis utamanya saya rumuskan begini: AI harus menurunkan biaya pemulihan fakta, agar tim memiliki lebih banyak perhatian untuk percakapan jujur dan memilih satu perbaikan kecil. Jika yang terjadi sebaliknya dan Sprint Retrospective berubah menjadi daftar rekomendasi yang dihasilkan otomatis, tim kehilangan justru hal yang menjadi alasan acara ini ada: pembelajaran bersama, tanggung jawab atas perubahan, dan kemampuan meningkatkan kualitas kerja.

Tim yang matang tidak bertanya: "bisakah kita menyerahkan retrospective kepada AI?". Mereka bertanya dengan cara lain: "bagian persiapan mana yang bisa diambil alih AI agar retrospective kita menjadi lebih jujur, lebih konkret, dan lebih baik sampai ke tindakan?". Pertanyaan ini kurang menarik. Namun justru pertanyaan inilah yang lebih dekat dengan continuous improvement yang sesungguhnya.

Sumber dan acuan

• Scrum Guide 2020 — Sprint Retrospective, kualitas dan efektivitas, orang / interaksi / proses / alat / Definition of Done, perbaikan yang paling bermanfaat dan kaitannya dengan Sprint Backlog.
• Scrum Guide Expanded v2026.1 — sumber pendamping berbasis Scrum Guide 2020: psychological safety, meaningful continuous improvement follow-through, dan AI sebagai supervised decision-making partner.
• Scrum.org: Introduction to the Sprint Retrospective — penjelasan praktis Sprint Retrospective sebagai acara untuk inspection and adaptation praktik kerja tim.
• Lehtinen, Itkonen & Lassenius: Recurring opinions or productive improvements — studi empiris atas 37 retrospektif selama hampir tiga tahun: participant bias, hard evidence, recurring topics, dan corrective actions.
• Amy Edmondson: Psychological Safety and Learning Behavior in Work Teams — sumber klasik tentang psychological safety sebagai syarat team learning.
• NIST Generative AI Profile — confabulation, data privacy, human-AI configuration, overreliance, information integrity, dan risiko lain dari generative AI.
• OWASP Top 10 for LLM Applications 2025 — sensitive information disclosure, excessive agency, misinformation, dan risiko operasional aplikasi LLM.
• DORA State of AI-assisted Software Development 2025 — AI sebagai penguat kekuatan dan kelemahan yang sudah ada dalam sistem organisasi.
• EDPB Opinion 28/2024 dan ICO monitoring at work guidance impact assessment — acuan tentang data pribadi, transparansi, proporsionalitas, dan batas workplace monitoring.