Tips membuat Sprint Retrospective menjadi lebih Produktif dan Tidak Membosankan
Alkisah ada sekelompok software developer yang sangat gemar coding, dan setelah sebuah sprint selesai, mereka biasanya bersemangat untuk melakukan sprint retrospective, biasa disingkat sprint retro.
Format sprint retro yang mereka gunakan adalah format standar dan umum dipakai, yaitu:
1. Apa yang harus tetap dilakukan
2. Apa yang harus berhenti dilakukan
3. Apa yang harus mulai dilakukan
Karena ada beberapa versi format standar, kadang formatnya seperti ini:
1. Apa yang berjalan baik saat sprint
2. Apa yang tidak berjalan baik saat sprint
3. Apa perbaikan yang bisa dilakukan
Dari feedback yang didapat dari suatu sprint retro, mereka bisa menggunakannya untuk berusaha menghindari kesalahan yang sama, dan potensi kesalahan di masa mendatang.
Tidak ada yang salah dengan format ini, dan format ini sepertinya adalah format yang paling banyak digunakan saat sprint retro. Hanya saja, pada suatu hari kelompok software developer tersebut mulai merasa bosan dengan format sprint retro yang biasa dijalankan, dan menemukan di beberapa sprint retro terakhir, feedback yang diperoleh terlalu monoton, kosa kata yang sama diulang berkali-kali, dan seperti kurang ide.
Sehingga kemudian, mereka berdiskusi dan memutuskan untuk mencari apakah ada format sprint retro lain di dunia ini. Maka petualangan dimulai…
Beberapa anggota tim, terutama yang sering menjadi Product Owner, ditugaskan untuk pergi berkelana mengunjungi perusahaan lain, berbicara dengan teman, fellow developer, group developer, atau membaca buku, untuk mencari format lain yang berbeda untuk dicoba dan mungkin bisa mereka gunakan.
Setelah sekian purnama berlalu, mereka semua kemudian kembali berkumpul di sebuah warung kopi untuk saling menceritakan petualangan mereka dan apa yang mereka dapat, tentunya tetap mengikuti protokol kesehatan.
Setelah beberapa gelas kopi dan rangkaian cerita, mereka menemukan ada beberapa format lain yang ingin mereka coba di kesempatan sprint retro berikutnya. Si pembawa format baru akan memimpin sprint retro dengan format yang dia bawa, dan akan dilihat bagaimana hasilnya. Kemudian format yang lain akan dicoba pada kesempatan sprint retro berikutnya sampai mereka menemukan format baru yang mereka suka.
Beberapa format yang mereka coba adalah:
- The Three Little Pigs
Dengan format ini, pemimpin sprint retro akan menggambar 3 buah rumah yaitu, rumah dari sedotan / jerami (kurang ok), rumah dari kayu (ok aja), dan rumah dari bata (mantap abis), di papan tulis atau sejenisnya. Kemudian masing-masing peserta menuliskan aspek apa saja mengenai technology stack yang harus diperhatikan dan dimasukkan ke rumah sedotan atau rumah kayu, atau rumah bata. Hal ini akan menolong tim dalam menemukan apa yang mereka rasa benar-benar bagus mengenai technology stack di rumah bata, dan apa yang mereka rasa tidak yakin di rumah sedotan / jerami. Hasilnya, tim akan mengetahui aspek apa saja dari technology stack yang sangat perlu mereka kerjakan, dan kalau perlu dengan investasi waktu yang lebih banyak, dibanding mengerjakan suatu aspek yang bisa dibiarkan dulu karena sudah baik.
2. Hot Air Balloon
Dengan format ini, pemimpin sprint retro akan menggambar sebuah balon udara panas pada papan tulis atau sejenisnya, dan ada gambar cuaca cerah di salah satu sisi untuk apa yang ingin dicapai, kemudian ada gambar cuaca buruk di sisi yang lain untuk apa yang berusaha dihindari. Kemudian di bagian bawah balon udara panas digambar kantong pasir untuk menuliskan apa-apa saja yang memberatkan tim dan menahan kemajuan development. Mereka harus memikirkan technology stack, atau mungkin memikirkan team performance, atau mungkin memikirkan apa yang benar-benar ingin dicapai pada sprint sebelumnya. Pada sisi cuaca cerah, tim berpikir mengenai apa yang mereka ingin capai, seperti test coverage yang lebih baik, atau mungkin QA process yang lebih baik. Pada sisi cuaca buruk, tim berpikir mengenai apa yang mereka berusaha hindari, seperti design yang belum siap, atau requirement yang belum lengkap. Di bagian kantong pasir, mereka harus berpikir mengenai apa yang menjadikan proses development berjalan kurang cepat atau apa yang menahan (blocker), mungkin biaya server yang ternyata belum dibayar, atau mungkin ada developer yang kurang sehat, atau ada user story yang kurang. Ini akan membuat mereka keluar dari format biasa, dan mereka mulai bisa memikirkan hal-hal yang lebih luas (big picture).
3. Story Oscars
Format lain yang dicoba kelihatan sedikit berbeda, tetapi mungkin bisa menjadi salah satu favorit, namanya Story Oscars. Setiap anggota tim secara bergantian menominasikan user story, dan memberikan alasan kenapa pantas mendapatkan piala Oscars dengan berbagai kategori seperti User Story Terbaik, User Story Paling Menjengkelkan, User Story Paling Sulit, dan berbagai kategori lainnya, sehingga mereka tidak perlu memikirkan apa yang berjalan baik dan apa yang tidak berjalan baik lagi, tetapi lebih fokus pada apa yang dihasilkan dari sebuah user story, dan proses pengerjaannya. Dengan adanya feedback dari tim, format ini bisa membantu Produk Owner membuat user story yang berkualitas tinggi, supaya kinerja tim bisa lebih baik dan lebih produktif.
4. Confident vs Apprehensive Quadrant
Dengan format ini, tim menggambar sebuah kuadran dengan sumbu Y positif adalah confident (percaya diri) dan sumbu Y negatif adalah apprehensive (khawatir), kemudian pada masing-masing ujung sumbu X adalah technology dan people, bebas mana yang di kanan dan yang di kiri. Format ini meminta masing-masing anggota tim untuk menaruh apa saja yang mereka tahu dan rasakan dalam kuadran tersebut, misal ada yang berkata “saya percaya diri dengan suatu library yang ada”, atau ada yang berkata “saya khawatir dengan unit testing”, atau mengenai aspek teknologi lainnya. Di sisi people, mungkin ada yang mengatakan “saya percaya diri dengan kemampuan Product Owner dalam membuat user story”, atau “saya sebenarnya agak khawatir dengan stakeholder external yang tidak memberikan requirement yang cukup sebelumnya”, dan lain-lain. Berbeda dengan format yang biasa mereka lakukan, format ini membuat tim harus berpikir lebih detil mengenai aspek teknologi dan orang, yang mana sebetulnya sebuah produk perangkat lunak / software dibuat dari orang dan teknologi.
Setelah mereka mencoba semua format, maka kemudian mereka duduk bareng untuk berdiskusi mengenai mana format yang cocok. Mereka kini melakukan retro terhadap berbagai format sprint retro yang sudah dicoba, dan berusaha untuk memilih mana yang cocok, mana yang disukai, mana yang berjalan baik, walaupun kadang harus melalui voting.
Ternyata mereka tidak memilih hanya satu format, tetapi beberapa format yang akan dijalankan, termasuk format yang biasa berjalan, dengan urutan tertentu supaya semua aspek bisa dikomunikasikan, bisa didapat feedback-nya, dan tidak membuat bosan. Contohnya, mereka berencana menggunakan format Balon Udara Panas / Hot Air Balloon satu kali per-quarter untuk mendapat feedback dari hal-hal yang lebih luas (big picture) secara berkala.
Jadi ini bukan hanya mengenai mengubah format sprint retro dari suatu format ke format lain karena bosan saja, tetapi ini adalah cara untuk mencari berbagai informasi mengenai apa yang tim butuhkan dengan format sprint retro yang cocok.
Lebih jauh lagi, penggunaan beberapa format sprint retro yang berbeda bisa membuat anggota tim mendapatkan wadah untuk menyalurkan ide atau pendapatnya, dan bisa membantu para developer yang baru bergabung untuk memahami berbagai aspek dari produk yang mereka buat. Maka dari informasi-informasi itu, akan dapat dimengerti apa yang membuat tim bisa menjadi lebih kompak dan lebih produktif.
Semoga informasi ini bisa menginspirasi rekan-rekan untuk mencapai sprint retro yang sukses. Ditunggu komentarnya…
Terima kasih
Referensi:
1. https://www.funretrospectives.com/three-little-pigs/
2. https://metroretro.io/templates/the-hot-air-balloon-retrospective
3. https://retromat.org/
Hyperjump is an open-source-first company providing engineering excellence service. We aim to build and commercialise open-source tools to help companies streamline, simplify, and secure the most important aspects of its modern DevOps practices.
