Apakah ide yang baik untuk menunjuk salah satu anggota tim scrum atau master scrum sebagai Pemilik Produk?

Akhir-akhir ini kami memiliki proyek, di mana klien sedang sibuk tur. Seperti tim scrum biasa dibentuk, manajemen memutuskan untuk menunjuk analis kami sebagai pemilik Produk karena Klien tidak akan dapat berpartisipasi secara aktif. Analis adalah orang yang bekerja erat dengan klien untuk analisis kebutuhan dan penyusunan spesifikasi.

Klien tidak punya waktu untuk meninjau dua rilis pertama. Semuanya berjalan lancar sampai, klien melihat rilis ketiga; dia tidak puas dengan beberapa fungsi, dan itu diperkenalkan oleh Make shift Product Owner (analis kami).

Kami disuruh menunggu sampai tim desain menyelesaikan mock-up semua halaman dan klien memeriksa masing-masing dan menyetujui untuk terus bekerja. Tim scrum ada di sana, tetapi tidak ada sprint - kami selesai bekerja hampir seperti metode air terjun klasik.

Apakah ide yang baik untuk menunjuk anggota tim scrum atau master sebagai pemilik produk? Apakah kita perlu mengikuti scrum dengan tidak adanya partisipasi klien / pemilik produk?

Hanya beberapa minggu yang lalu Mike Cohn menulis tentang menggabungkan scrum master dan peran pemilik produk di blognya. Saya tidak berpikir saya bisa mengatakannya lebih baik daripada dia, tetapi ringkasan pendek dari posnya adalah ini:

• itu ide yang buruk
• SM dan PO melakukan jenis tugas yang sangat berbeda ("tugas bintang" dan "tugas wali" dalam kata-kata Cohn)
• orang yang menggabungkan kedua peran tersebut sepertinya tidak cocok untuk semua tugas yang terlibat dalam kedua peran tersebut
• tim mungkin dirugikan oleh gabungan SM / PO yang mengabaikan tugas-tugas yang tidak mereka kuasai.

Saya pikir tidak ada yang salah dengan mengambil anggota tim scrum dan memindahkannya ke Pemilik Produk. Tetapi Anda harus menyadari bahwa itu seperti promosi atau transfer internal; itu menciptakan lubang di tim dan lubang perlu diisi. Mungkin tim bisa "mengatur sendiri" untuk mengisi lubang; mungkin perlu mempekerjakan karyawan baru untuk mengisi posisi yang kosong.

Proses Anda tampaknya baik bagi saya. Anda tidak mendeskripsikannya secara terperinci, tetapi setidaknya, perannya dihormati (ini penting).

Namun, dengan beberapa detail yang saya miliki, saya dapat melihat beberapa masalah di tingkat pemilik produk.

Ia harus memastikan bahwa pelanggan diberi tahu dengan baik tentang perkembangannya. Sepertinya dia melakukan "air terjun" secara eksternal dengan pelanggan dan "scrum" secara internal dengan Anda.

Hasil : air terjun menang karena pelanggan adalah raja. Bahkan jika dalam kasus ini, pelanggan memiliki tanggung jawab ...

Tim Anda saat ini (termasuk Master Scrum), harus fokus pada pengiriman sprint backlog. Namun pemilik produk (analis) harus memastikan bahwa apa yang ada dalam jaminannya mencerminkan apa yang diinginkan pelanggan. Ia juga harus memastikan bahwa komunikasinya baik dan bahwa pelanggan ikut serta.

Solusi yang mungkin : kirim pemilik produk Anda (analis) ke kursus Pemilik Produk Scrum , atau buat dia membaca (dan memahami) buku ini: Agile Product Management with Scrum .

Scrum bekerja paling baik dengan klien nyata di tempat. Ada beberapa tantangan nyata dalam berurusan dengan klien yang tidak terbiasa dengan desain produk iteratif.

• Sindrom lembaran kosong
• Sindrom klien yang ketakutan

Tahap desain dengan lembaran kosong cenderung membuat pie di langit sangat cepat, dan biasanya masuk sangat dalam pada masalah beberapa sisi dan tidak cukup dalam pada fungsi inti yang dibutuhkan. Anda benar-benar membutuhkan tukang jerami untuk dipilih klien agar rapat desain berjalan dengan sukses. Dengan berfokus hanya pada satu aspek pada satu waktu, Anda membantu klien Anda mempelajari desain berulang.

Klien yang ketakutan (seperti yang Anda miliki dengan pengalaman Anda) tidak menyadari bahwa proyek gesit mengantisipasi sejumlah pengerjaan ulang (terkontrol) tertentu sebagai bagian dari proses. Yang sulit mereka pahami adalah saat pengembangan produk bergerak maju, akan ada lebih sedikit momen "Ya Tuhan". Lebih penting lagi, bagian yang paling sulit dihadapi klien adalah saat "Oh my god" tidak memerlukan banyak uang untuk diperbaiki karena waktu yang singkat antara siklus peninjauan / perencanaan.

Mengelola harapan klien sangat sulit. Ini adalah keseimbangan yang baik dari pendidikan pelanggan, menenangkan, dan bahkan belajar mengatakan "tidak". Klien tidak selalu datang setiap minggu atau dua minggu. Terkadang mereka hanya bisa datang sebulan sekali. Tidak apa-apa. Selama Anda menunjukkan kepada mereka apa yang Anda lakukan untuk mengatasi masalah mereka pada bulan sebelumnya, lalu fokus pada pekerjaan bulan ini, itu akan sangat membantu membuat proyek berjalan lebih lancar. Intinya adalah, dalam ketidakhadiran pelanggan Anda memiliki seseorang yang dapat membuat rekomendasi yang masuk akal untuk beberapa pertanyaan. Perlu seseorang yang akrab dengan tujuan yang ingin dicapai oleh klien.

Idealnya pemilik produk memiliki beberapa tingkat otoritas dan pengetahuan tentang proyek tersebut. Hal yang sama ini bisa terjadi jika klien menugaskan karyawan tingkat rendah yang kemudian dikuasai secara berlebihan pada fase selanjutnya yang mengharuskan Anda untuk memulai kembali dari awal.

Terima kasih atas kiriman Anda. Saya menyadari ini sudah tua, tetapi saya pikir Anda telah mengangkat kasus yang hebat dan inilah $ 0,02 saya:

Masalah 1: menunjuk analis sebagai PO dalam kasus Anda secara serius membuat hubungan pendek scrum. Mengapa? Karena hanya PO yang dapat membuat penilaian nilai, penilaian ROI, penentuan prioritas dan pilihan yang menentukan yang mengalir dari bisnis, bukan dari teknologi, bahkan dari keakraban dengan produk. Saya yakin sr Anda. Analis melakukan pekerjaan yang luar biasa meniru PO, tetapi akhirnya harus menebak keinginan, nilai, pilihan yang akan datang dari PO Anda. ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/ . Kecuali jika analis Anda diberikan POA dari klien (tidak mungkin), mereka tidak akan berada dalam posisi untuk menerima atau menolak apa pun di ulasan sprint.

Mungkinkah pendekatan ini berhasil? Ya tetapi harus ada transfer tanggung jawab total saat klien Anda keluar. Bos klien Anda perlu menyetujui pengganti, dan bahwa tidak ada keputusan yang masuk akal yang akan dibatalkan. Kemungkinan besar terdengar? Lebih besar kemungkinan Anda akan mendapatkan PO sementara dari organisasi klien Anda (yang tentunya bukan tanpa kelemahannya!) Tetapi jika sr Anda. analis bekerja dengan PO sementara, setiap keputusan yang salah akan datang dari bisnis, sehingga menjaga peran tim Anda bersih.

Masalah 2: "klien tidak punya waktu untuk meninjau". Masalah besar (dan yang saya temui baru-baru ini juga). PO harus ada untuk menerima produk. Tidak ada orang lain yang bisa 'menandatangani cek'. Tidak adanya PO berarti ketidakpuasan terjadi kemudian, berpotensi lebih banyak pengerjaan ulang, dan hilangnya kepercayaan. Lebih mendasar lagi saya merasakan klien tidak aktif terlibat dalam proyek Anda: tidak ada waktu untuk standup harian, tidak ada waktu untuk menjawab pertanyaan, dll.

Masalah 3: "kami disuruh menunggu sampai tim desain selesai mock-up". Dan sekarang sepenuhnya scrum. Orang-orang yang melakukan mock-up harus menjadi bagian dari tim lintas fungsi Anda. Saya tidak tahu apakah ini disebabkan oleh kurangnya pemahaman manajemen tentang scrum atau reaksi kejutan terhadap rilis ketiga Anda.

Pertanyaan: Di mana master scrum Anda dalam semua ini? SM biasanya akan mengenali bahaya konflik peran dan kurangnya partisipasi, baik hambatan / bahaya yang harus diatasi.