Tulisan ini masih berkaitan dengan tulisan saya sebelumnya, agar teman-teman lebih paham konteksnya saya sarankan membaca dulu tulisan ini.
Topiknya masih sama tentang EBM, khususnya performa tim. Latar belakang ceritanya kurang lebih seperti ini.
Halo pak, sudah kurang lebih satu tahun ini perusahaan kami pakai Scrum. Kami juga sudah pernah ikut training in-house Scrum, dan sekarang kami pun punya Scrum Master. Namun, management kami merasa development kami malah jadi lebih lama, bukan lebih cepat. Sering kali akhirnya tim development disalahkan.
Tidak sekali saya mendengar hal seperti itu, intinya, “kenapa pake scrum malah timnya jadi jelek?”. Penilaian “jadi jelek” ini muncul karena ada efek “developmentnya lama”. Sehingga muncul asumsi liar: Scrum membuat development jadi lama. Tim development pake Scrum. Ya, Scrum bikin lama, jelek.
Penilaian seperti itu terlalu sempit, sebaiknya untuk menilai sesuatu membutuhkan lebih dari satu variabel. Kita tidak bisa menilai sebuah mobil jelek karena variabel: mobil tersebut dibuat di Tiongkok. Kurang objektif. Begitupun menilai tim Scrum. Ada banyak variabel yang bisa dijadikan sumber data untuk menilai apakah tim tersebut jelek atau tidak.
Tidak semerta mengatakan karena pake Scrum timnya jadi jelek. Scrum bisa membuat tim menjadi jelek, juga menjadi bagus. Scrum hanyalah alat bantu, yang menggunakan yang menentukan.
Datanya mana?
Untuk menjawab pertanyaan di atas tadi, kita patut mempertanyakan data apa yang menunjukan timnya jelek. Jika dijawab, “ya itu, developmentnya jadi lama”, silahkan kembali bertanya, “data apa yang bisa menunjukan developmentnya lama?”.
Pengertian dan asumsi orang dengan kata ‘lama’ bermacam-macam, oleh karena itu perlu dikuatkan dengan data yang menunjukan jam, hari, minggu atau bulan untuk mendukung asumsi tersebut.
Dalam tulisan sebelumnya, data tim kami menunjukan: Ada 91% kemungkinan 8 backlog akan selesai dalam 10 hari. Hal tersebut karena kami punya data berikut:
Apakah bisa dikatakan itu lama? Tergantung definisi ‘lama’ setiap organisasi atau individu.
Variabel pendukung
Mari kita anggap itu adalah ‘lama’, dan pertanyaan yang tepat adalah: “apa yang membuat lama?” Bukan, “kenapa bisa lama?”. Yang dibutuhkan adalah variabel apa yang membuat lama, bukan justifikasi. Berikut data-data yang bisa dijadikan variabel pendukung.
Backlog Distribution, data ini bisa dipakai untuk menunjukan kemampuan tim Scrum (termasuk Product Owner) dalam mewujudkan backlog menjadi increment.
Dari pie chart diatas dapat disimpulkan:
54% backlog selesai berupa Feature
16% backlog selesai berupa Architecture
14.7% backlog selesai berupa Non-functional
14.7% backlog selesai berupa Adhoc Request
0.6% backlog selesai berupa Defect
Pertanyaannya, apakah tim ini bisa dikatakan tim jelek sehingga development menjadi lama? Bisa ya, bisa tidak, tergantung definisi jelek dan lama.
Jika cukup jeli, anda bisa melihat ada kaitannya antara sprint backlog distribution ini dan velocity ditulisan saya sebelumnya. Oh ya, disisi lain dari dua chart diatas anda juga bisa menarik data lainnya seperti melihat Innovation Rate Ratio.
Data lain yang bisa menguatkan adalah berikut.
Mari kita simpulkan
Fakta dari data empiris sebagai berikut:
Deliver 8 backlog setiap 2 minggu dengan probabilitas 91%, dan
Ada 14.7% backlog Adhoc Request, dan
Ada 14.5% backlog Non-functional
Mengakibatkan 0.6% defect selama development, dan
Mampu mencapai 7.1% code coverage lebih baik dari baseline, dan
Mengakibatkan 1.3% technical debt atau setara 248 menit (sekitar 4.1 jam)
Dari fakta tersebut, jika kita mencari apa yang membuat lama ada banyak sekali kemungkinan, asumsinya antara lain:
Mungkin karena terlalu banyak backlog Adhoc dan Non-functional
Mungkin karena baseline code coverage 70% terlalu tinggi
Mungkin karena kemampuan teknis tim developmentnya kurang bagus, sehingga hanya mampu deliver 8 backlog setiap 2 minggu
dan kemungkinan-kemungkinan lainnya berdasarkan data empiris yang ada.
Bagaimana supaya bisa jadi cepat, pak?
Secara teknis mudah, kurangi backlog adhoc dan non-functional, dan/atau, kurangi baseline code covarage, dan yang lainnya. Namun, tentunya ada plus minus yang akan berdampak secara kualitas ke increment yang dihasilkan.
Bagaimana supaya cepat tanpa mengurani kualitas increment, pak?
Ada hal lain selain variabel teknis yang bisa mempengaruhi kualitas tim, coba tanyakan Scrum Master dan diskusi mencari tahu variabel non-teknis apa saja yang bisa menghambat kinerja tim.
Kemungkinan solusi diatas masih berupa asumsi, agar tahu asumsi tersebut benar atau tidak, ya perlu dicoba dilakukan lalu diukur. Mencari variabel yang paling dominan baik teknis dan non teknis yang berpengaruh.
Selama ini asumsi saya dari pernyataan “sejak pake scrum, development jadi lama” yang kerap muncul karena hanya melihat waktu delivery dan output saja. Karena jika saya tanya, apakah ada data atau ukuran yang menunjukan hal tersebut, jawabannya selalu sama, berputar-putar dan akhirnya tetap tidak ada data, atau kurang akurat.
Sebelum pake scrum, tim saya bisa deliver 20 backlog dalam 2 minggu, pak!
Bagus, lalu bagaimana dengan defect-nya? Bagaimana dengan code quality-nya? Apalah artinya deliver banyak backlog namun ternyata buggy, code coverage tidak tercapai, technical debt tinggi.
Atau apakah dengan output sebesar itu tim mendapatkan satisfaction? Lembur atau tidak? Hal-hal seperti itu perlu masuk sebagai variabel pendukung.
Kembali ke penilaian jelek dan lama, jika kita mempunyai data sebelumnya yang bisa dijadikan perbandingan dengan data diatas, tentunya akan lebih baik diskusinya.
Dari perbadingan menggunakan data empiris, diharapkan bisa lebih tepat melihat variabel apa yang membuat lama, (kalau masih keukeuh yang dinilai adalah ‘jadi lama’).
Bayangkan (bayangkan saja dulu), mempunyai data yang menunjukan kondisi sebelum dan setelah implementasi Scrum. Tanpa membandingkan praktek mana yang lebih baik, akan lebih bijak bagi organisasi melihat variabel apa berdampak naik atau turun. Apa plus minus penerapan praktek baru, apa yang harus ditingkatkan, apa yang perlu segera ‘dikubur’.
Tidak bosan saya pakai kutipan, “A fool with a tool is still a fool”. Scrum hanyalah tool, yang menggunakannya yang menentukan.
Hal yang ingin saya utarakan ditulisan ini adalah empirisme.
Scrum implements an empirical process where progress is based on observations of reality.
Jika menilai implementasi Scrum jelek atau bagus tapi tanpa ada data pendukung, argumen tersebut tidak berdasar.
Data empiris Scrum bisa dilihat dari Dashboard EBM, data EBM sangat memungkinkan diolah lagi sedemikian rupa untuk menilai, lebih tepatnya membantu organisasi untuk mampu beradaptasi dan berinovasi, karena data-data tersebut tranparan.
Membiasakan untuk menilai dan diskusi berdasarkan data akan lebih valuable dibanding berdasarkan asumsi saja, setidaknya menurut saya.
The world is getting smarter every day, everyone can talk bullshit nowadays. Ask them, what your sources?