Beberapa jenis pengakuan kelompok atas upaya anggota tim dapat menjadi motivator yang berharga, tetapi dalam hal ini sepertinya itu salah diterapkan. Anda menyatakan bahwa MVP dipilih dengan suara, tetapi ada banyak sebutan tentang jumlah bug yang diperbaiki per sprint. Sepertinya waktu Anda memiliki definisi lucu tentang MVP - Saya akan berasumsi bahwa orang yang pantas mendapat gelar "paling berharga" adalah orang yang menambahkan nilai paling besar ke perangkat lunak dalam sprint itu. Jika seorang anggota tim memilih bug yang dapat diperbaiki dengan cepat, menghancurkannya secepat mungkin, dan menyebabkan bug regresi dan masalah lain di belakang mereka, maka mereka tidak menambah nilai, mereka menciptakan lebih banyak pekerjaan untuk siapa pun yang memiliki untuk mengikuti mereka mengidentifikasi dan memperbaiki masalah tersebut.
Saran saya adalah untuk mencoba memulai diskusi yang tepat pada saat tim Anda memiliki salah satu suara ini. Jangan hanya membuatnya menjadi pertunjukan tangan; bicarakan dulu. Jika seseorang tampaknya mendapatkan suara berdasarkan banyaknya "perbaikan" yang telah mereka buat, tunjukkan (secara bijaksana) di mana perbaikan itu menyebabkan regresi, dan sarankan agar orang yang memperbaiki regresi tersebut harus dinominasikan untuk membersihkan orang lain. kekacauan. Jika seseorang menghabiskan seluruh sprint untuk menyelesaikan satu masalah buruk, tunjukkan hal itu kepada tim, dengan menyoroti fakta bahwa meskipun hitungan perbaikan orang ini adalah satu, mereka sendirian memecahkan masalah besar dengan perangkat lunak Anda - masalah yang sangat jahat sehingga tidak ada orang lain yang mau menyentuhnya.
Memilih perbaikan yang mudah dan melakukannya dengan terburu-buru atau sembarangan tidak berharga, jadi pengembang yang hanya melakukan itu mungkin tidak boleh memenuhi syarat sebagai kandidat MVP. Saat memilih MVP baru, lupakan semua tentang tim dan orang-orang di dalamnya, dan lihat perangkat lunaknya. Pilih satu perubahan terpenting dalam perangkat lunak itu sejak terakhir kali. Maksud saya lajang di sini; "tidak sebanyak bug kecil" bukanlah perubahan besar. Apakah bug yang sangat mencolok telah diperbaiki? Apakah fitur baru yang hebat telah ditambahkan? Setelah Anda mengidentifikasi apa perubahan besar ini, tanyakan siapa yang bertanggung jawab untuk itu. Salah satu dari mereka mungkin adalah MVP Anda yang sebenarnya. Jika "tidak sebanyak bug kecil" adalah satu - satunya perbedaan, maka dan hanyamaka bug menghitung ukuran yang valid dari MVP - dan bahkan kemudian, saya akan melihat rasio bug yang diperbaiki terhadap bug yang disebabkan regresi. Setiap bug yang menyebabkan seseorang mengurangi setidaknya 1 dari jumlah mereka. Bahkan, saya akan mengatakan lebih dari 1, karena perbaikan yang buruk akan menyebabkan bug yang tidak diketahui yang kemudian harus Anda temukan, yang lebih buruk daripada bug yang diketahui yang sudah ditemukan. Bug yang dikenal membutuhkan upaya pengembang untuk memperbaikinya; bug yang tidak diketahui membutuhkan upaya QA untuk menemukan, dan upaya pengembang untuk memperbaikinya, dan kemudian ada risiko bahwa QA akan melewatkannya.
Secara teori, jika pengembang menyadari bahwa jalan menuju hadiah adalah memperbaiki lebih sedikit, masalah yang lebih besar, mereka akan mencari yang sulit, yang kompleks, cacat pemblokiran. Ini akan mengharuskan mereka untuk bersatu kadang-kadang, baik karena tidak ada masalah gemuk untuk berkeliling, atau karena masalahnya cukup rumit untuk membutuhkan lebih banyak mata . Mungkin menyarankan bahwa dalam kasus-kasus seperti ini, penghargaan dapat dibagikan jika tidak segera jelas mana dari sekumpulan orang yang bekerja lebih banyak untuk memperbaiki bug - dan ingat, pekerjaan selesai! = Baris kode yang ditulis. Pengembang mungkin akan tahu itu, tetapi Anda mengatakan manajemen terlibat, dan manajemen tidak selalu memahami hal itu.
Dan hei, jika semuanya gagal, lupakan program MVP. Bicaralah dengan sesama pengembang Anda di luar scrum, dan tunjukkan dampak negatif yang diberikan penghargaan MVP pada perangkat lunak. Lihat apakah Anda dapat membuat mereka mengabaikannya, atau tidak membuatnya menjadi masalah besar. Tinggalkan piala di laci, belanjakan hadiah uang tunai di atas segelas minuman untuk tim sepulang kerja, gunakan makan siang gratis untuk mendapatkan sesuatu yang dapat Anda bagikan, seperti seikat cupcake. Agile adalah sistem tim; menyoroti risiko kinerja individu yang mengadu tim satu sama lain. Bersatu Anda berdiri, membagi Anda mengirimkan perangkat lunak yang dipenuhi bug, setelah batas waktu, lebih dari anggaran.