Di Scrum, mengapa peran Pemilik Produk dan ScrumMaster tidak digabungkan?

19

Dalam proyek yang lebih tradisional yang saya kerjakan, manajer proyek (dan, pada proyek yang lebih besar, mungkin ada rekanan / wakil / asisten manajer proyek jika satu orang tidak tersedia) adalah orang yang bertanggung jawab untuk berkomunikasi dengan pelanggan, menerima proyek pembaruan kesehatan dan status, menentukan penjadwalan dan penganggaran, mengelola proses, memastikan tim memiliki apa yang mereka butuhkan untuk menyelesaikan tugas, dan sebagainya.

Di Scrum, bagaimanapun, tanggung jawab ini dibagi antara Pemilik Produk dan ScrumMaster. Pemilik Produk adalah suara pelanggan. Mereka berinteraksi langsung dengan pelanggan, membuat cerita pengguna, mengatur dan memprioritaskan simpanan produk, dan masalah lain yang dihadapi pengguna / pelanggan. ScrumMaster menangani proses, mengawasi pertemuan (termasuk estimasi dan perencanaan), menghilangkan hambatan, dan memantau kesehatan keseluruhan proyek, membuat penyesuaian yang diperlukan.

Saya telah membaca di berbagai sumber, termasuk Wikipedia , bahwa peran ScrumMaster dan Pemilik Produk harus dipegang oleh dua orang yang berbeda. Saya tidak hanya membaca, tetapi bekerja pada proyek gaya "tradisional" yang sukses di mana kegiatan keduanya ditangani oleh satu orang. Bahkan, lebih masuk akal bagi satu hingga tiga orang untuk bertanggung jawab dalam menangani proyek (termasuk sumber daya manusia / kepegawaian) dan tugas tingkat proses, karena mereka sering berjalan seiring. Perubahan proses berdampak pada penjadwalan, penganggaran, kualitas, dan sasaran tingkat proyek lainnya, dan perubahan proyek berdampak pada proses.

Mengapa Scrum menyerukan untuk mengisolasi kegiatan ini menjadi dua peran? Apa keuntungan yang sebenarnya disediakan oleh ini? Adakah yang pernah berada di proyek Scrum yang sukses di mana Pemilik Produk dan ScrumMaster adalah individu yang sama?

— Thomas Owens
sumber

Juga, saya bersumpah pertanyaan ini sudah ditanyakan, tetapi saya tidak dapat menemukannya dan saya tidak membintanginya sebagai favorit. Banyak pertanyaan tentang definisi peran di sini, tapi saya tidak melihat PO / SM yang saya yakin saya baca.

— Thomas Owens

Apakah Anda memikirkan pertanyaan ini ?

— Adam Lear

@Anna Itu terlihat familier, tetapi sebenarnya itu bukan duplikat. Saya kira pertanyaan spesifik ini mungkin belum pernah ditanyakan sebelumnya.

— Thomas Owens

Bagaimana dengan yang ini ? :)

— Adam Lear

1

Saya sarankan membaca Succeeding with Agile di mana hal ini dibahas lebih terinci.

— Ladislav Mrnka

17

Mereka dapat (dan seringkali) digabungkan dan dilakukan oleh satu orang (tidak ada aturan yang menentang hal ini (scrum-nya)).

TETAPI Anda perlu menyeimbangkan tanggung jawab perbedaan dengan hati-hati karena kedua peran tersebut memiliki saingan dan agenda (dan dibutuhkan orang khusus untuk dapat melakukan keduanya secara bersamaan). Saya telah melihat banyak yang mencoba tetapi sedikit yang melakukannya dalam jangka waktu yang lama (ini adalah posisi yang membuat stres).

Untuk menjadi SM Anda memang membutuhkan lebih banyak pengetahuan teknis daripada PO (karena Anda akan membantu mengatur tim pengembangan). Dibutuhkan pengetahuan terperinci tentang produk untuk dapat menarik sesuatu dari tumpukan produk ke tumpukan musim semi (kadang-kadang Anda tidak bisa menarik item 'n' atas karena ini mungkin kontraproduktif).
PO membutuhkan lebih banyak pemahaman tentang pengguna akhir persamaan daripada mereka SM. Ini tidak perlu sebagai teknis tetapi tidak membutuhkan pengetahuan tentang bagaimana produk akan digunakan di dunia nyata dan arah yang diinginkan pelanggan untuk mengambil produk.

Jika Anda dapat menemukan seseorang yang dapat melakukan kedua peran maka saya tidak melihat alasan untuk mencegah hal ini.

Masalah dapat muncul ketika PO ditarik oleh pelanggan dalam satu arah yang menyebabkan perselisihan yang signifikan bagi pengembang (karena mereka perlu membangun beberapa infrastruktur lain terlebih dahulu). Pekerjaan SM bukan untuk mengikuti keinginan pelanggan tetapi untuk melindungi pengembang dari keinginan mereka. Melakukan ini secara objektif itu sulit.

— Martin York
sumber

1

Ya, seperti yang saya lihat, konflik kepentinganlah yang menyebabkan masalah. Pemilik produk ingin sebanyak mungkin dilakukan, master scrum perlu mengelola harapan pemilik produk.

1

Deskripsi SM Anda salah. Anda menggambarkan sesuatu seperti pemimpin tim, bukan SM.

— Ladislav Mrnka

1

Saya sangat tidak setuju dengan itu. PO dan SM adalah dua pekerjaan yang sangat berbeda. borisgloger.com/2009/12/07/...

@Pierre Tautan itu diposting dalam jawaban. Seperti yang saya katakan dalam jawaban atas jawaban itu, semua kecuali 3 memiliki argumen berlawanan yang dapat saya kemukakan di sini dan saat ini, dan 3 sangat umum sehingga berlaku untuk setiap posisi pekerjaan yang pernah ada.

— Thomas Owens

3

Pastikan juga untuk memeriksa posting ini yang membahas secara khusus tentang ini: blog.mountaingoatsoftware.com/… . Jika mencampurkan peran itu bekerja untuk Anda, saya berjanji kepada Anda saya akan mengirimkan Anda sekotak cokelat Belgia.

4

Saya bukan ahli, tetapi saya pikir Scrum Master harus menjadi penasihat / fasilitator tim. Suara pelanggan harus memiliki kepentingan pelanggan di hati. Scrum Master harusnya semua tentang membantu tim mendapatkan apa yang mereka butuhkan agar sprint berhasil.

— Amy Anuszewski
sumber

1

Juga, ingatlah paling sering daripada tidak, Anda tidak bekerja pada 1 pelanggan pada suatu waktu. Pemilik Produk mungkin mengelola beberapa pelanggan dan dapat berkonsentrasi pada bagian bisnis itu, dan ScrumMasters dapat berkonsentrasi pada pengembangan proyek.

Seperti yang dikatakan banyak orang, kedua peran itu memiliki minat yang berbeda, tetapi tujuan yang sama dan keterampilan yang berbeda untuk mendapatkannya.

— AJC
sumber

Itu mungkin benar. Setiap tempat saya pernah bekerja, staf "tingkat proyek" (setara dengan PO dan SM) dikhususkan untuk satu proyek, jadi ini adalah satu-satunya kerangka referensi yang saya miliki. Tim pengembangan mungkin ditugaskan untuk beberapa proyek, tetapi biasanya bahkan seorang pengembang ditugaskan untuk satu proyek penuh waktu dan peran pendukung pada satu atau dua lainnya.

— Thomas Owens

0

Jika orang yang sama mewakili tim pengembang dan pengguna / pelanggan, satu-satunya jalan yang Anda miliki dalam perselisihan adalah dengan melihat kontrak. Meskipun pada akhirnya mungkin akan terjadi ini, Anda lebih baik jika perwakilan dari kedua belah pihak dengan kekuatan yang sama dapat membuat kesepakatan.

— JeffO
sumber

Jika PO bukan dari organisasi pelanggan (yang, menurut pemahaman saya, sering kali demikian), maka Anda masih harus melihat kontrak jika ada perselisihan antara organisasi yang sedang berkembang (termasuk PO) dan pelanggan.

— Thomas Owens

1

Itu benar, tetapi memiliki seorang klien yang mengadvokasi staf mungkin dapat menangani perselisihan sebelum hal itu kembali ke pelanggan. Jika mereka berdua tidak setuju dengan pelanggan, itu masalah lain.

— JeffO

0

Orang-orang dalam peran Pemilik Produk dan Master Scrum mungkin memiliki keinginan, tujuan, persyaratan, dan kendala yang saling bertentangan, lebih dari 2 programmer acak. Manusia mungkin atau mungkin tidak dapat sama-sama menghargai tujuan yang bertentangan dengan baik, dan mungkin lebih cenderung membuat kesalahan dalam penilaian ketika dihadapkan dengan tujuan yang bertentangan. Dua orang dengan fokus atau bias yang sedikit berbeda mungkin lebih kecil kemungkinannya untuk bersama-sama membuat kesalahan yang sama atau tingkat kesalahan penilaian yang sama.

Dua orang juga dapat memberikan lebih banyak jam kerja total untuk berfokus pada setiap aspek yang berbeda dari masalah / proyek (misalnya tujuan dari 2 peran yang berbeda).

— hotpaw2
sumber