Scrum: Bagaimana jika Pemilik Produk memiliki tugas?

Saya baru saja mulai bekerja dengan tim yang telah mengambil beberapa aspek Scrum (dua minggu timeboxing) tetapi tidak yang lain (tim saat ini tidak menyetujui semua perkiraan atau jumlah poin dalam sprint, tapi saya akan mengubah ini segera.) Pemilik produk juga merupakan sumber daya teknis (ilmuwan) dengan beberapa latar belakang pengembangan.

Apakah pantas untuk memiliki tugas-tugas pemilik produk (yang sebagian besar melibatkan penelitian) dicampur dengan tugas-tugas tim (beberapa di antaranya adalah penelitian dan beberapa pengembangan).

Para ahli di Scrum sangat tegas dalam menyatakan bahwa Pemilik Produk dan Master Scrum harus dua orang yang berbeda. Namun, tidak ada aturan seperti itu yang mengecualikan salah satu dari Tim Pengembangan. Catatan dalam Panduan Scrum :

Ukuran Tim Pengembangan

Ukuran Tim Pengembangan Optimal cukup kecil untuk tetap gesit dan cukup besar untuk menyelesaikan pekerjaan yang signifikan. Kurang dari tiga anggota Tim Pengembangan mengurangi interaksi dan menghasilkan keuntungan produktivitas yang lebih kecil. Tim Pengembangan yang lebih kecil mungkin menghadapi kendala keterampilan selama Sprint, menyebabkan Tim Pengembangan tidak dapat memberikan Peningkatan yang berpotensi dirilis. Memiliki lebih dari sembilan anggota memerlukan koordinasi terlalu banyak. Tim Pengembangan Besar menghasilkan terlalu banyak kerumitan untuk dikelola oleh proses empiris. Peran Pemilik Produk dan Master Scrum tidak termasuk dalam penghitungan ini kecuali mereka juga menjalankan pekerjaan Sprint Backlog.

Akibat dari baris terakhir itu adalah bahwa, jika Pemilik Produk sedang mengeksekusi pekerjaan Sprint Backlog, ia dihitung sebagai anggota Tim Pengembangan.

Yang mengatakan, lakukan apa pun yang bekerja untuk menyelesaikan pekerjaan Anda dengan baik.

Pemilik Produk bertanggung jawab untuk memaksimalkan nilai produk dan pengembalian investasi. Ini mungkin tampak sederhana tetapi biasanya peran penuh waktu dan sangat menuntut - bisa dibilang yang paling sulit di Scrum. Ini melibatkan banyak pekerjaan strategis tingkat tinggi serta tugas-tugas tingkat rendah, mulai dari menganalisis peluang pasar dan berkonsultasi dengan para pemangku kepentingan dan pengguna produk untuk membuat keputusan yang tepat, hingga menjaga peta jalan produk dan jaminan simpanan yang selalu dipoles, menghadiri perencanaan dan mengulas kegiatan, menjadikan dirinya tersedia bagi tim untuk menjawab pertanyaan mereka, dll.

Jika PO bertanggung jawab atas tugas-tugas lain selain itu, saya hanya akan melihatnya sebagai marginal dalam kebanyakan kasus. Jadi jawaban saya adalah ya, buat tugas untuk PO jika Anda benar-benar harus dan jika mereka berkontribusi langsung untuk menghasilkan peningkatan perangkat lunak sprint, tapi saya tidak melihat itu sering terjadi dalam proyek Scrum rata-rata Anda.

Scrum adalah yang pertama dan terutama tentang komunikasi, dan melakukan pekerjaan yang relevan dan tepat waktu. Apa pun untuk mencapai tujuan itu boleh saja jika itu yang membuat tim Anda menjadi yang paling produktif.

Namun, sulit untuk melakukannya dengan baik. Saya dalam posisi itu sekarang dan saya merasa sulit untuk mencurahkan jumlah waktu yang tepat sebagai pemilik produk sementara masih menyisakan waktu untuk pengembangan. Namun, pengaturan bekerja dengan baik untuk tim khusus ini pada saat ini. Kami akan meninjau kembali keputusan bagi saya untuk melakukan tugas ganda ketika kinerja kami turun, tetapi sampai saat itu kami akan terus bekerja dengan cara ini.

Jadi, cobalah. Lakukan retrospektif agar Anda dapat terus meningkatkan proses Anda. Jangan biarkan menempel sebelumnya pada beberapa metodologi menghalangi produktivitas tim Anda.