Apakah manajer proyek bermanfaat dalam Scrum?


17

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?


Saya mengenali itu. Namun mungkin ScrumMasters berpikir bahwa mereka adalah PM baru.
Amir Rezaei

Siapa yang melakukan anggaran dan menyinkronkan dengan proyek lain?
Amir Rezaei

3
@Amir Rezae Yah, tentu saja ini PM. Tetapi mereka tidak harus mengambil bagian dalam scrum. Yang persis seperti yang kita miliki, PM pengawas yang memastikan berbagai bagian proyek (dev dan non-dev) berada di jalurnya dan tidak ada yang menunggu umpan balik dari yang lain. Berhasil.
biziclop

Apa yang Anda maksudkan dengan manajer proyek di sini? Saya terbiasa melihat manajer proyek dari bagan organisasi menjadi Pemilik Produk di Scrum sehingga mereka sangat banyak di sana meskipun tidak harus menggunakan kekuatan sebanyak sebelumnya.
JB King

Saya setuju dengan @biziclop. Ini adalah cara kami bekerja juga. Manajer proyek kami yang luar biasa terus berkeliaran di antara tim scrum (dan semua orang lain yang terlibat), memastikan bahwa tidak ada masalah serius, dan membantu kami menyelesaikannya saat terjadi. Tapi dia sama sekali tidak terlibat dalam "scrumming", dan memang seharusnya begitu.
Boise

Jawaban:


15

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.


Terima kasih, saya menambahkan beberapa penekanan pada pertanyaan saya untuk menyoroti itu.
Martin Wickman

Saya melihat Anda berubah, itu tidak membatalkan jawaban saya. Masalahnya saya kira adalah bagaimana mereka melihat sesuatu dengan benar? Mereka ingin satu orang yang mengelola proses. Menjelaskan di mana tanggung jawab dan cara kerjanya dapat membantu. Jadi saran saya adalah untuk berkomunikasi lebih banyak tentang peran dan karenanya membuat Scrum lebih jelas kepada mereka.

Siapa yang mencakup elemen di luar IT build?
Jon Hopkins

1
@ Jon: Pemilik Produk dan Master Scrum (lebih sedikit dari Pemilik Produk). Berarti Pemilik Produk tampak seperti manajer proyek yang sedang kita bicarakan. Dia hanya mendelegasikan hal-hal yang tidak dapat dia kendalikan ke tim.

@Pierre - Menarik. Melihat saya tidak pernah melihat PM sebagai sangat terlibat dengan tim pengembangan, dia selalu membiarkan mereka melanjutkan sementara dia mengelola bisnis. Mungkin saya beruntung.
Jon Hopkins

9

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.


1
Saya akan mengatakan bahwa mungkin peran terdekat dengan PM klasik adalah Scrum Master. Scrum Master memastikan bahwa tim dapat bekerja sesuai rencana dengan secara aktif mendengarkan keprihatinan mereka dan menghilangkan hambatan. Seorang PM sebagai Scrum Master mungkin kehilangan tugas-tugas mereka sebelumnya (seperti perencanaan) ketika mereka pindah ke peran yang lebih konsultasi -> mereka mungkin tidak merencanakan dan memperkirakan sprint secara aktual, tetapi mereka membantu tim melakukannya dan harus siap untuk melompat jika masalah muncul.
Anne Schuessler

@ Anne - ini poin yang bagus. Yang mungkin Anda temukan adalah Anda memiliki satu PM di beberapa proyek, membantu Pemilik Produk dengan kasus bisnis, Scrum Master dengan perencanaan (terutama dependensi di luar tim) dan berkoordinasi dengan unsur-unsur di luar proyek TI.
Jon Hopkins

4

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.


1
Banyak poin di sini, kebanyakan dari mereka jatuh ke tangan PO dan / atau ScrumMaster menurut definisi. Mengelola portofolio proyek perusahaan adalah hal yang baik, tetapi saya tidak yakin apakah ini merupakan tugas PM. ROI adalah masalah PO.
Martin Wickman

1
Satu-satunya kekhawatiran ROI yang harus dihadapi manajer proyek. Sering kali suatu produk tidak dimaksudkan untuk menghasilkan uang - itu hanya untuk menghentikan pesaing mencuri pangsa pasar, sehingga tidak akan ada ROI (terima kasih Chris Matts). Seringkali mereka harus bekerja dengan arsitektur, infrastruktur, dll untuk memastikan opsi tetap terbuka untuk masa depan. ROI jarang menjadi perhatian sebagian besar proyek. Ini adalah contoh yang sangat baik dari jenis hal yang mungkin diketahui oleh PM atau analis yang baik, dan PO yang baru dilatih mungkin tidak.
Lunivore

2
Apa yang ingin dikatakan di sini, bahwa PM adalah manusia super? Sama sekali tidak masuk akal. Kita berbicara tentang peran di sini, bukan individu. Tentu saja seorang "analis yang baik" tahu lebih banyak hal daripada "PO yang baru dilatih", itu jelas. Mengenai jawaban Anda: Semua poin, kecuali poin portofolio proyek ditangani oleh SM atau PO di Scrum. Dan apa dengan kuliah ROI? Tidak ada yang mengatakan ROI yang paling penting, hanya ROI yang menjadi perhatian POs (menurut definisi).
Martin Wickman

Terima kasih. Ini adalah umpan balik yang bagus yang akan membantu saya mengkomunikasikan poin saya lebih baik di masa depan. Saya minta maaf karena memberi kuliah.
Lunivore

1

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.


1
Menarik. Perhatikan bahwa POlah yang bertanggung jawab atas ROI dengan selalu memastikan hal-hal terpenting sedang dibuat. Jadi bagian itu tertutup dengan cukup baik.
Martin Wickman

1

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.


Saya tidak berpikir saya setuju dengan ini, saya pikir pembukaan untuk PM / SM secara simultan mengacu pada perusahaan yang percaya pada scrum peran PM hanya telah diganti namanya dan tidak mengerti itu telah digunakan kembali sama sekali. Itu dan wajan PM memang cocok untuk peran Scrum Master (meskipun lebih kepada pemangku kepentingan jika Anda bertanya kepada saya)
Jimmy Hoffa

1

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.


1

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.


2
Ada apa dengan komentar sampah, saya tidak mengerti.
Martin Wickman

2
@ MartinWickman Saya membacanya berarti "tidak cukup berkomitmen untuk scrum way" seperti dalam: Kami melakukan scrum tetapi kami masih memiliki manajer yang mengatur jadwal.
Caleb

0

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.


0

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 :-)

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.