Apakah manajer proyek bermanfaat dalam Scrum?

Ada tiga peran yang didefinisikan dalam Scrum: Tim, Pemilik Produk, dan Master Scrum. Tidak ada manajer proyek, sebaliknya pekerjaan manajer proyek tersebar di tiga peran .

Contohnya:

• The Scrum Master: Bertanggung jawab atas proses tersebut. Menghapus hambatan.
• Pemilik Produk: Mengelola dan memprioritaskan daftar pekerjaan yang harus dilakukan untuk memaksimalkan ROI. Merupakan semua pihak yang berkepentingan (pelanggan, pemangku kepentingan).
• Tim: Mengelola pekerjaannya sendiri dengan memperkirakan dan mendistribusikannya di antara mereka sendiri. Bertanggung jawab untuk memenuhi komitmen mereka sendiri.

Jadi di Scrum, tidak ada lagi orang yang bertanggung jawab atas keberhasilan proyek. Tidak ada struktur perintah-dan-kontrol di tempat. Itu tampaknya membingungkan banyak orang, khususnya yang tidak terbiasa dengan metode tangkas, dan tentu saja, PM.

Saya benar-benar tertarik dengan ini dan apa pengalaman Anda, karena saya pikir ini adalah salah satu hal yang dapat membuat atau merusak implementasi Scrum.

Apakah Anda setuju dengan Scrum bahwa manajer proyek tidak diperlukan? Apakah Anda pikir peran seperti itu masih diperlukan? Mengapa?

Mungkin Anda harus menyajikan hal-hal seperti ini:

Manajer proyek tidak menghilang di Scrum . Dia masih di sana. Ada tiga dari mereka sekarang!

• The Scrum Master : dia mengelola proses dan menyelesaikan rintangan. Itu adalah tanggung jawab manajer proyek sebelumnya.

• Pemilik Produk : ia mengelola jaminan. Itu adalah tanggung jawab manajer proyek sebelumnya ketika dia memperkirakan semuanya di Microsoft Project.

• Tim : mengatur sendiri produksinya. Siapa dan bagaimana cerita pengguna tertentu dikonversi menjadi peningkatan produk yang berpotensi dirilis. Itu adalah tanggung jawab manajer proyek ketika dia menugaskan tugas.

Bagi saya ini berasal dari kurangnya pemahaman tentang apa yang dilakukan Manajer Proyek dan sifat agak umum dari judul PM. Saya bukan ahli tentang SCRUM tetapi saya selalu melihat Master SCRUM menggantikan manajer pengembangan / pemimpin tim daripada Manajer Proyek.

Manajer Proyek (sebagaimana didefinisikan oleh metodologi seperti PRINCE2 - yang cukup kompatibel dengan metodologi Agile) benar-benar tidak ada hubungannya dengan proses pengembangan, mereka menjaga proyek dari perspektif pengiriman yang lebih luas yang mencakup lebih dari sekedar IT membangun. Ada banyak hal yang berada di dalam peran Manajer Proyek yang tidak tercakup di tempat lain dalam Scrum (mengelola dan memantau kasus bisnis, mengelola pemangku kepentingan bisnis, elemen-elemen proyek di luar pembangunan TI seperti pengerjaan ulang proses bisnis, dukungan, pelatihan dan sebagainya).

Jika PM Anda adalah orang yang menjaga pengembang dan tidak melakukan lebih dari itu (misalnya pada proyek yang sebagian besar hanya IT di mana ruang lingkup didefinisikan dengan cukup baik) maka mungkin ia tidak akan dibutuhkan pada proyek SCRUM.

Tetapi sebelum seseorang mengatakan Anda tidak memerlukan PM untuk SCRUM, saya ingin penjelasan yang cukup jelas tentang bagaimana elemen-elemen non-IT proyek sedang dibahas dan khususnya siapa yang mengelola kasus bisnis (karena pengguna menginginkannya) dan itu menjadi sesuatu yang harus dilakukan adalah hal yang berbeda).

Mungkin PM akhirnya lebih banyak duduk di sisi bisnis proyek - Pemilik Produk mungkin mengambil lebih banyak peran PM daripada Master Scrum tetapi saya pikir tidak mungkin dia akan pergi sepenuhnya.

Ada beberapa hal yang bisa dilakukan oleh Manajer Proyek yang mungkin tidak dapat dilakukan oleh Master Scrum atau Pemilik Produk.

• Manajer Proyek biasanya memiliki pengalaman yang luas dalam menjalankan proyek (kejutan!).
• Mereka sadar akan perangkap umum, dan dapat menemukannya serta membantu menghadangnya sebelum terjadi.
• Mereka biasanya negosiator berpengalaman, dan dapat mendukung anggota tim lainnya dalam diskusi seputar tenggat waktu, ruang lingkup, dan persyaratan yang saling bertentangan (sangat penting jika PO cukup baru dalam perannya).
• Mereka dapat mengatur uang. Mereka memiliki kekuatan untuk merekrut dan memecat, dan dapat membantu jika seseorang dalam tim tidak mampu melakukan peran mereka (melalui mengatur pelatihan, konseling, dll).
• Mereka dapat membantu memastikan bahwa proyek cocok secara efektif ke dalam program kerja yang lebih besar.
• Mereka bisa mengeluarkan barang dari tim.
• Mereka dapat membantu memandu kebijakan perusahaan agar efektif bersama Scrum (misalnya, jika penguji masih diukur dengan jumlah bug yang ditemukan).
• Mereka dapat mengelola pemerintahan.
• Mereka bisa memindahkan furnitur.
• Kosakata mereka adalah milik perusahaan yang lebih besar, dan mereka dapat mendiskusikan proyek - dan pendekatan Scrum - dalam hal risiko, dampak, ROI, opsi dan diferensiasi.
• Mereka dapat menjelaskan kepada dewan mengapa transparansi mendadak dan berita kegagalan yang sesekali, datang melalui lautan laporan hijau, baik dan berguna untuk diketahui.
• PM yang baik dapat membantu Anda merasa aman, terdengar keren, dan tampak hebat.

Scrum tidak mengamanatkan memiliki PM. Tetapi Anda mungkin ingin memilikinya.

Di salah satu proyek yang saya kerjakan, ketika berubah menjadi Scrum, manajer proyek kami sebelumnya mengambil peran sebagai Pemilik Produk dan Master Scrum. Itu semacam bekerja selama 6 bulan yang saya habiskan bersama tim itu, meskipun itu tidak ideal (untuk saya). Dia adalah tipe pria yang ingin menjaga hal-hal di bawah kendali ketat, tetapi melakukannya dengan cukup baik (yaitu membiarkan tim melakukan tugasnya dan membuat keputusan saat yang tepat).

Latar belakang dari hal ini adalah bahwa perusahaan berada dalam situasi keuangan yang mengerikan, walaupun kami (tim) baru mengetahuinya beberapa waktu kemudian. Jadi ada alasan untuk menjaga semuanya di bawah kontrol ketat, untuk memastikan bahwa hanya barang-barang yang benar-benar diperlukan sedang dibangun, dan versi pertama dari produk dikirimkan tepat waktu.

Saya akan bersikap adil dan mengatakan bahwa dalam pandangan saya apa yang berhasil bagi saya adalah master Scrum yang bertindak sebagai manajer Proyek juga. Menjadi master Scrum bukan pekerjaan penuh waktu - begitu tim matang, master scrum bahkan tidak perlu menghadiri stand up harian.
Ada semakin banyak lowongan yang saya lihat untuk seorang Project Manager / Scrum Master di mana perusahaan tidak ingin membedakan peran ini - melainkan memiliki orang yang sama menangani kedua peran - yaitu: seorang manajer proyek Agile.

Manajer proyek: peran dalam organisasi atau perusahaan tradisional.

Scrum master: peran dalam tim pengembangan perangkat lunak menggunakan metodologi Scrum.

Berbicara tentang manajer proyek vs master scrum benar-benar berbicara tentang apel dan jeruk karena perannya memiliki konteks yang berbeda. Saya belum pernah mendengar tentang organisasi yang memiliki "Scrum master" sebagai gelar resmi atau nilai gaji. Dan manajer proyek pada proyek apa pun, Scrum atau lainnya, seringkali agak dihapus dari kegiatan pengembangan perangkat lunak sehari-hari.

Apa yang dilakukan oleh manajer proyek dan seberapa banyak perannya tumpang tindih dengan peran master Scrum atau pemilik proyek sangat tergantung pada ukuran dan sifat proyek, tetapi tentu saja ada tugas yang biasanya dikaitkan dengan manajer proyek yang tidak secara khusus bagian dari master Scrum atau peran pemilik proyek. Pada proyek kecil dimungkinkan untuk memperluas tugas master Scrum atau peran pemilik proyek untuk memasukkan tugas-tugas tersebut (perekrutan, pemecatan, pembelian, manajemen kontrak, berinteraksi dengan eksekutif tingkat tinggi, dll.). Pada proyek yang lebih besar, pengembangan perangkat lunak hanyalah satu bagian dari manajemen proyek, dan tugas-tugas manajer proyek dan tugas-tugas master Scrum tidak mungkin tumpang tindih sama sekali.

Seorang manajer proyek harus menjadi antarmuka master Scrum ke organisasi. Master Scrum harus menjadi antarmuka manajer proyek untuk tim.

Jadi, apakah manajer proyek bermanfaat dalam Scrum? Tidak, manajer proyek berguna di luar Scrum. Mereka bukan bagian dari metodologi pengembangan perangkat lunak Scrum, tetapi mereka menyediakan sumber daya yang memungkinkan Scrum bekerja.

Pertanyaan ini berbau Scrumbut .

Scrum adalah bagian dari apa yang terkandung dalam metode manajemen proyek (Prince2 / PMP dll). Bahkan, jika Anda melihat proses Prince2 MP (mengelola pengiriman produk), semua elemen Scrum dapat terkandung di sana.

Scrum Master tidak ingin terjebak dalam pertemuan dengan vendor, personel, hukum, keuangan, pemasok, eksekutif, atau aktivitas BAU . Mereka perlu berkonsentrasi pada menghilangkan hambatan dari tim pada sprint saat ini, tidak menegosiasikan seberapa banyak agen tenaga kerja dapat mengurangi tarif kontraktor di FY2011 / 12 atau memvalidasi perjanjian escrow dengan vendor x.

Jika Scrum Master Anda melakukan hal di atas, Anda tidak menjalankan Scrum, Anda menjalankan Scrumbut.

Dari pengalaman, kombinasi terbaik adalah memiliki Master Scrum untuk setiap pemimpin tim dan manajer proyek untuk mengoordinasikan master scrum dalam Scrum fashion scrum. Memiliki manajer proyek dalam peran ini lebih efektif karena alasan yang diberikan di atas dan pengalaman mereka yang mendalam. Pada gilirannya, manajer proyek ini melapor menjadi Manajer Portofolio / Program dll dan semua dalam rantai komando setidaknya bersertifikasi Scrum Masters.

Ingat bahwa Scrum adalah alat untuk mengelola pengiriman produk, pada lapisan abstraksi dapat digunakan untuk menjalankan proyek, tetapi sudah ada proses yang jauh lebih baik di luar sana untuk itu.

Salah satu masalah utama dengan peran manajer proyek tradisional adalah bahwa ia memisahkan otoritas dari tanggung jawab. PM memiliki wewenang penuh atas organisasi proyek - (s) ia memutuskan tugas apa yang perlu dilakukan, oleh siapa, dalam urutan apa, dll. Tetapi (s) ia tidak bertanggung jawab atas penyelesaian tugas-tugas ini atau kualitas perangkat lunak yang diproduksi. Anggota tim adalah satu-satunya yang bertanggung jawab. Ini menciptakan overhead komunikasi yang sangat besar, untuk mengembalikan wewenang dan keputusan dalam sinkronisasi dengan pekerjaan operasional, anggota tim secara konstan harus melaporkan semua yang dilakukan kepada PM di samping anggota tim lainnya. Ini juga menciptakan perasaan perampasan, ketidakberdayaan dan kehilangan tujuan dengan anggota tim, yang merupakan sumber besar frustrasi dan keputusasaan.

Agile entah bagaimana menyatukan kembali gagasan-gagasan ini - otoritas atas organisasi kerja dipegang oleh tim secara keseluruhan (melalui rilis, iterasi, dan pertemuan harian) sehingga semua orang merasa seperti mereka dapat memiliki suara dalam masalah ini, dengan imbalan masing-masing anggota tim harus bertanggung jawab untuk memproduksi perangkat lunak berkualitas yang berfungsi dan membuat komitmen kuat untuk mencapai tujuan itu. Dengan demikian Anda secara teoritis dapat menyingkirkan manajer proyek.

Setelah Anda mengatakan itu, masih ada tugas-tugas yang secara tradisional ditugaskan kepada PM yang masih perlu diurus - lunivore menggambarkannya dengan cukup akurat.

Seperti yang disarankan artikel ini , dalam tim yang benar-benar multi-keterampilan, satu hal yang dapat Anda lakukan adalah membuang peran manajer proyek, mendistribusikan kembali tugasnya di antara anggota tim dan membuat mantan PM menjadi anggota tim reguler.

Peran Scrum didefinisikan dengan sangat baik (jika mereka tampak tidak jelas, itu karena mereka dimaksudkan untuk berlaku di berbagai jenis organisasi), dan karena tim Scrum selalu (well, umumnya) dengan ukuran yang sama - yaitu tidak terlalu besar - relatif mudah untuk menyepakati apa yang mereka jangkau, bahkan jika itu bervariasi tergantung pada organisasi yang mendasarinya.

Membaca pertanyaan, jawaban, dan komentar di atas, tampak jelas bahwa definisi peran manajer proyek jauh lebih sulit untuk dipecahkan. Saya yakin Anda dapat menemukan definisi umum yang bagus dan lengkap tentang peran PM, tetapi apa yang sebenarnya berarti dalam kehidupan nyata adalah cerita yang sama sekali berbeda.

Bagaimanapun, karena bekerja di pekerjaan saya, manajer proyek sangat jarang terlibat dengan "Scrumming" yang sebenarnya. Mereka tidak diizinkan menjadi Scrum master (aturan konflik kepentingan lokal yang kami semua senang), dan mereka hanya pemilik produk dalam kasus luar biasa.

Jadi di mana saya bekerja, manajer proyek masih di sana, melakukan cukup banyak apa yang selalu mereka lakukan. Berarti mereka menjaga proyek tetap pada jalurnya, bertindak sebagai filter terhadap terlalu banyak paranoia dan kecenderungan manajemen mikro dari "di atas", memecahkan masalah yang membutuhkan pengaruh lebih dari yang kita miliki untuk dipecahkan, dan seterusnya.

Saya yakin ini sangat berbeda di tempat lain, tetapi bagi kami ini bekerja dengan baik.

Sunting : Mungkin saya harus mengklarifikasi bahwa bagi kami, tim Scrum tidak menggantikan tim proyek. Satu atau lebih tim Scrum mulai melakukan pekerjaan pengembangan aktual untuk (dan biasanya di) proyek. Tim Scrum dapat (dan mungkin selalu melakukannya) terdiri dari anggota tim lama, kecuali pemimpin proyek :-)