Apa yang terjadi, ketika seorang yang baru pertama kali memimpin proyek pengerjaan software development yang menganut metodologi scrum dan harus menjalankan peran sebagai fasilitator di salah satu ritual scrum yang bernama sprint retrospective?
Jujur, pasti bingung apa yang musti dipersiapkan dan bagaimana caranya supaya ritual bisa dikemas dengan baik. Mari coba kita bahas aspek penting supaya bisa menjalankan Sprint Retrospective yang efisien.
Apa sih Sprint Retrospective?
Supaya lebih afdal, saya coba ambil referensi sprint retrospective menurut Scrum Guide [1]:
“opportunity for the Scrum team to inspect itself and create a plan for improvements to be enacted during the next sprint.”,
Menurut tafsir saya, yaitu ritual refleksi tentang apa yang sudah terjadi dan apa yang bisa dijadikan pembelajaran. Tugas fasilitator yang penting adalah, menciptakan lingkungan dimana anggota tim merasa nyaman untuk menyampaikan pendapat jujur mereka, hal-hal baik apa saja yang berjalan dengan baik dan point yang bisa ditingkatkan lagi. Harapan saya adalah terjadinya kultur diskursus yang sehat antar anggota tim.
Ritual ini menjadi siklus yang memiliki potensi untuk memulai gebrakan kultur, dimana semangat perbaikan menjadi hal yang lumrah dari tim tersebut.
Siapa saja yang Diundang?
Jawaban singkatnya adalah, semua entitas atau pemangku kepentingan yang terlibat langsung pada pengerjaan suatu sprint. Berikut adalah contohnya:
- Sprint team: Contohnya, developers; designers dan juga engineers.
- Sprint facilitator: Contohnya, Scrum master; product owner dan project manager
- Pengamat/ahli: Contohnya, Agile coach; business owner dan key stakeholder.
Yang perlu diingat oleh fasilitator, ketika menyiapkan list siapa saja yang diundang, yaitu memastikan visi sprint retrospective untuk memupuk budaya kepercayaan satu sama lain, inovasi dan kerjasama tim. Caranya bisa dengan mengkomunikasikan visi ini pada setiap undangan sprint retrospective kepada semua stakeholders, dengan harapan stakeholder yang diundang akan memiliki kesamaan tujuan dan diskusi terjalin secara konstruktif.
Metodologi
Pada affinity map terdapat kategori yang sudah didefinisikan dan peserta bisa menulis feedback berdasarkan kategori.
Ada banyak metode yang bisa dipakai ketika menjalankan sprint retrospective. Sejauh ini secara praktek, saya baru mencoba metode affinity mapping. Yaitu suatu metode dimana fasilitator mempersiapkan sebuah board yang berisi kategori yang sudah ditentukan (pre-defined). Untuk alat yang bisa dipakai juga banyak, hanya saja pada waktu itu, saya menggunakan alat bernamai miro[2].
Kesalahan saya sebagai pemula adalah kategorisasi yang tidak jelas dimana di bagi berdasarkan high priority dan low priority yang rentan terhadap bias individu, karena prioritas dan sudut pandang individu dalam melihat suatu permasalahan pasti berbeda-beda. Sehingga menyebabkan banyak waktu yang terbuang untuk mendifinisikan mana priority yang high mana yang low. Bukan ke esensi dari feedback yang sudah di bagikan oleh anggota team yang ikut sprint retrospective.
Lebih baik jika kategori di buat lebih jelas dan spesifik seperti:
- Requirement issues, Hal yang berkaitan dengan requirement.
- Scrum ceremony issues, Hal yang berkaitan dengan ritual scrum yang dijalankan.
- Team / culture issues, Hal yang berkaitan dengan tim dan kultur tim selama sprint.
Sehingga memudahkan bagi peserta untuk langsung menulis feedback dan secara cepat mengelompokkannya ke tiap-tiap kategori yang sudah tersedia, lalu menentukan action item apa yang bisa di ambil.
Sprint Retrospective: Hari-H
Pertama-tama, berilah kesempatan buat setiap orang buat ngomong dan dengerin satu sama lain. Di acara sprint retrospective, semua anggota tim harus diikutsertakan dan diberi kesempatan untuk berbicara tentang apa yang mereka pikirkan. Jangan ada yang merasa diabaikan atau tidak dihargai.
Selanjutnya, fokus ke masalah, bukan ke orangnya. Jangan saling menyalahkan atau ngomel-ngomel ke orang lain ya. Yang perlu dilakukan adalah fokus ke masalah yang dihadapi dan cari solusinya bareng-bareng. Ingat, kita semua ada di tim yang sama dan tujuannya adalah untuk menyelesaikan masalah, bukan untuk saling menyalahkan.
Yang terakhir, gunakan bahasa yang sopan dan menghargai. Meskipun kita lagi kesel atau suasana hati lagi tidak bagus, jangan sampai pakai kata-kata yang kasar. Kita harus tetap menghargai perasaan orang lain.
Lesson learned
Sebagai pemula, saya merasakan hal yang jamak, ketika akan memulai sesuatu dimana saya belum familiar, yaitu sering mempertanyakan kapasitas diri sendiri, apakah mampu untuk menjalankannya. Pada kasus, ketika saya harus menjadi fasilitator sprint retrospective, suara dalam kepala saya berkecamuk, “apa iya bisa?” “gimana ya nanti pas sesi retros nya kalo malah pada menyalahkan satu sama lain?”. Ketakutan yang berubah menjadi overthinking ini akhirnya bisa saya atasi dengan melakukan persiapan, riset metode yang umum digunakan dan berkonsultasi ke orang yang sudah pernah menjalankan.
Semoga dengan pembelajaran dari kasus saya, para fasilitator pemula lebih memiliki keberanian untuk mengambil tanggung jawab dan mencoba untuk terus memperbaiki kemampuan fasilitatornya menjadi lebih efektif dan efesien.
Referensi
- Schwaber, K., & Sutherland, J. (2020). The Scrum Guide™. Scrum.org. Diambil dari link https://www.scrum.org/resources/scrum-guide
- Miro©. (2023). Miro Board. Miro Enterprise. Miro.com.
Loading...