Apa negatif dari Manajer Pengembangan sebagai Scrum Masters?


27

Secara umum disepakati bahwa manajer tim tidak boleh menjadi scrum master, tetapi saya berjuang untuk melihat alasannya. Untuk konteks, saya seorang Manajer Pengembangan Aplikasi dengan 4 devs di Tim Scrum. Saya berasal dari latar belakang Scrum Master, dan telah memperkenalkan scrum ke organisasi. Saya telah membangun tim dari awal dan menjelaskan bahwa semua yang saya lakukan adalah untuk memfasilitasi tim, dan mereka membuat keputusan. Sebagai sebuah tim, kami sangat terbuka - mereka bahkan membungkam saya di stand-up untuk sementara waktu untuk menghilangkan perasaan 'melaporkan' yang mulai kami dapatkan. Kurangnya keterbukaan umumnya merupakan argumen terbesar terhadap manajer sebagai scrum master, tetapi ditangani dengan baik, mudah diatasi dengan budaya yang tepat.

Saya telah diperingatkan oleh pelatih scrum berpengalaman bahwa ini adalah situasi berbahaya, dan ada risiko 'jika semuanya berjalan buruk'. Cara saya melihatnya 2 posisi tidak bertentangan, di kedua peran saya memiliki tujuan yang sama untuk tim dan individu. Scrum menyelesaikan konflik dalam tim, yang secara tradisional bisa menjadi peran manajer. Sifat sprint yang mengatur diri sendiri menghilangkan alokasi pekerjaan yang biasanya dilakukan oleh seorang manajer.

Yang saya benar-benar lihat tersisa untuk dijemput sebagai manajer dev adalah memastikan kebutuhan individu terpenuhi, tujuan karir, tempat kerja dll. Saya memiliki perbincangan mingguan dengan setiap anggota tim untuk mengangkat masalah, dan menangani tugas admin. Banyak dari ini berhubungan langsung dengan tim, atau peran saya sebagai scrum master.

Saya memahami dalam organisasi besar bagaimana ini bisa tidak dapat dikelola dan peran terpisah tetapi untuk organisasi kecil kita tentu saja tidak dapat membenarkan Scrum Master atau Manajer Pengembangan lainnya.

Tolong beri tahu saya tentang perangkap Manajer Pengembangan sebagai Scrum Masters, tidak termasuk poin yang saya kemukakan di atas dan sudah diatasi.



Siapa Pemilik Produk?
Aaron Kurtzhals

@ Thomas, Terima kasih. Saya sudah melihat ini, dan faktor utama dalam hal ini adalah 'peringkat menarik' yang telah saya coba gariskan, saya sangat tidak melakukannya.
SpoonerNZ

@AaronKurtzhals, Pemilik Produk adalah manajer pemasaran digital kami, produk utama tim adalah situs web. Mungkin perlu dicatat bahwa saya secara efektif adalah pelatih scrum seluruh tim.
SpoonerNZ

Menurut pendapat saya, siapa pun yang berorientasi pada pemilik produk tidak boleh menjalankan scrum. Sumber daya QA bukan pilihan yang buruk karena membuat mereka mengikuti apa yang akan terjadi. Pengembang adalah pilihan utama karena mereka memiliki kepentingan untuk menjaga beban kerja.
Rig

Jawaban:


18

Pada dasarnya, Anda memiliki konflik kepentingan. Tugas seorang manajer adalah memenuhi tenggat waktu. Pekerjaan master scrum adalah memastikan estimasi seakurat mungkin dan bekerja dengan kecepatan yang berkelanjutan. Seorang manajer cenderung ingin lebih banyak pekerjaan ditarik ke dalam sprint, dan seorang scrum master cenderung menginginkan jumlah yang dapat diselesaikan secara realistis, terlepas dari tenggat waktu eksternal. Meskipun manajer yang baik dapat menyeimbangkan konflik itu, itu jauh lebih mudah ketika pekerjaan dibagi antara dua orang. Manajer biasanya jauh lebih cocok untuk peran pemilik produk.

Tidak ada yang salah dengan bertindak sebagai scrum master jika tidak ada seorang pun di tim Anda yang mengenalnya, tetapi tim Anda akan melihat manfaat jika Anda melepaskan peran itu setelah beberapa bulan. Penting bagi peran itu untuk dilihat sebagai teman sebaya. Bahkan master scrum non-manajemen sering harus memutar setelah beberapa saat karena tim mulai memperlakukan mereka seperti seorang manajer.


Saya setuju sepenuhnya jika dikatakan 'master scrum cenderung menginginkan jumlah yang tepat'.
SpoonerNZ

24

Saya percaya masalah utama adalah bahwa sebagai seorang manajer, Anda memiliki wewenang untuk memberi tahu tim apa yang harus dilakukan. Seorang master scrum tidak memiliki otoritas ini di luar menegakkan prinsip-prinsip Scrum.

Apa artinya ini? Masukan manajer secara implisit akan membawa lebih banyak bobot. Anda mungkin tidak bermaksud demikian, atau menginginkannya, tetapi pada akhirnya, karier dan gaji anggota tim Anda tergantung pada Anda. Dan mereka tahu itu. Dan ini menodai hubungan.

Masih bisakah kamu melakukannya? Tentu saja. Anda hanya perlu bekerja sangat keras untuk memperkuat bahwa Anda adalah seorang pelayan-pemimpin dan top-down tidak akan terbang.


Saya memahami hal ini, dan merasa bahwa dalam tim kami, kami telah mengatasi hal ini - sering kali dalam keputusan retrospektif akan dibuat bahwa saya tidak harus setuju dengan itu, tetapi saya memiliki keyakinan pada tim sehingga saya senang mereka melakukannya. Jika ini satu-satunya alasan, saya pikir saya aman, maka pertanyaan mencari alasan lain.
SendokNZ

2
Saya seorang manajer dev yang bertindak sebagai master scrum, dan ini adalah masalah yang saya miliki. Terlalu menggoda untuk menghabiskan scrum memberitahu setiap pengembang apa yang akan mereka lakukan. Ini bekerja lebih baik bagi kami untuk memiliki pengembang senior menjadi scrum master.
Gort the Robot

24

Saya benar-benar telah melihat apa yang terjadi ketika seorang "manajer teknis" terlalu banyak terlibat dalam mekanika proyek sehari-hari, dan itu tidak cantik. Dalam kasus kami, manajer yang dipermasalahkan bukanlah master scrum tetapi mencoba mengkooptasi beberapa keputusan itu; jika kita tidak benar - benar memiliki master scrum terpisah untuk bermain pertahanan maka itu akan jauh lebih menyakitkan.

(Kebetulan, ini bukan manajer saya , jadi saya merasa cukup objektif tentang hal ini.)

Saya akan membahas apa yang saya lihat sebagai konflik kepentingan utama; jika Anda tidak berpikir bahwa semua ini berlaku untuk situasi Anda, maka mungkin Anda bisa melakukan keduanya. Tetapi pastikan Anda memeriksa kembali asumsi-asumsi ini secara teratur untuk memastikan Anda tidak jatuh ke dalam perangkap ini:

  1. Manajer teknis biasanya bertanggung jawab atas peran tertentu dalam banyak tim. Jika hanya satu tim, maka itu lebih merupakan "pemimpin" daripada "manajer". Penyebaran tanggung jawab ini berarti lebih sedikit waktu dengan tim dan lebih sedikit waktu dengan proyek / produk, dan cenderung mengarah pada manajemen gaya "pukul dan jalankan".

  2. Manajer teknis memiliki banyak tugas manajerial lainnya untuk bisnis. Mereka perlu melakukan pelatihan / pelatihan, ulasan kinerja, wawancara / perekrutan, perencanaan infrastruktur / sumber daya jangka panjang, dan banyak lagi. Ini dapat dengan mudah menjadi pekerjaan penuh waktu dengan sendirinya dan berarti sangat sedikit sisa yang dihabiskan untuk memfasilitasi.

  3. Jadwal yang sibuk juga dapat memaksakan diri pada tim; manajer teknis mungkin perlu (atau ingin) menarik anggota tim ke rapat pada waktu yang dianggap tidak tepat waktu oleh tim. Biasanya tugas master scrum untuk mengelola dan mencoba menghilangkan gangguan, tetapi tidak mungkin untuk bersikap objektif tentang hal itu ketika Anda memiliki jadwal Anda sendiri yang perlu dikhawatirkan. Master scrum jarang perlu bertemu secara terpisah dengan anggota tim karena semua pertemuan itu sudah dijadwalkan sebelumnya (stand-up, retrospektif, dll.)

  4. Manajer teknis harus berurusan dengan masalah proyek lintas sektoral dan dorongan alami mereka adalah mencoba untuk menstandardisasi segalanya - perpustakaan, kontrol sumber, algoritme, tata letak, warna, apa pun. Walaupun ini sebenarnya bisa menjadi hal yang baik bagi perusahaan, pada akhirnya tidak ada seorang pun yang mau melakukan apa yang ingin dilakukan tim, dan mereka mungkin memiliki alasan yang sangat baik untuk ingin melakukan sesuatu secara berbeda. Ini bertentangan dengan cita-cita "perbaikan berkelanjutan" yang mendasari Scrum dan metodologi serupa.

  5. Manajer yang berasal dari latar belakang ahli dalam peran yang mereka kelola akan memiliki gagasan sendiri yang cukup kuat tentang bagaimana pekerjaan harus dilakukan dan berapa lama waktu yang dibutuhkan. Ini bukan hal yang buruk sebagai seorang manajer , tetapi sebagai seorang scrum master, hal itu akan sering berarti membiaskan anggota tim ke dalam desain atau perkiraan yang sebelumnya tidak akan mereka sepakati - dan mereka mungkin tahu lebih banyak daripada Anda tentang masalah yang dihadapi.

  6. Anggota tim akan selalu mengalami kesulitan membedakan antara permintaan dan pesanan. Mereka tidak akan mengatakan ini kepada Anda dan bahkan mungkin tidak menyadarinya sendiri. Bahkan jika Anda menjelaskan bahwa Anda hanya bertanya dan tidak mengatakan, dalam pikiran mereka, Anda masih manajer mereka dan ada risiko tingkat karier untuk mengatakan "tidak". Ini mungkin yang paling berbahaya dari semua masalah karena tidak ada yang dapat Anda lakukan - itu adalah sikap mereka dan bukan milik Anda yang penting.

Jika Anda yakin tidak akan jatuh ke dalam perangkap ini, maka lakukanlah ... tetapi saya ulangi, pastikan Anda sering memvalidasi asumsi Anda dengan berbicara dengan tim Anda (dan tim / manajer lain!) dan pastikan itu tidak terjadi secara halus atau tidak sadar yang mungkin tidak Anda sadari.

Pada catatan positif, saya akan menambahkan bahwa fakta bahwa Anda menganggap masalah cukup penting untuk benar-benar mengajukan pertanyaan berarti bahwa Anda mungkin cukup baik di kedua peran. Memedulikan tim dan bukan hanya ambisi karier Anda sendiri mungkin menyumbang lebih dari setengah dari manajemen yang baik, dalam buku-buku saya.

... tetapi menjadi baik pada keduanya tidak selalu berarti Anda bisa menjadi baik pada keduanya pada saat yang sama, sepanjang waktu . Hati-hati dengan itu.


7

Ini bukan agama dan aturan Scrum tidak dogmatis. Jika pernah ada kasus untuk peran HR Manager / Srum Master gabungan, Anda telah membuat yang bagus. Waspadai perangkap yang Anda sebutkan, tetapi tidak akan ada satu pun aturan yang cocok dengan setiap situasi dengan sempurna.

Jika tim Anda merasa nyaman dengan Anda melakukan kedua peran, maka tidak ada alasan untuk menggoyang hanya agar sesuai dengan aturan buku.


2
Ini adalah jawaban paling pragmatik +1
ozz

3

Masalah terbesar yang saya lihat adalah situasi di mana tim memiliki masalah yang berkaitan dengan Anda, manajer. Jika mereka masih junior, atau kurang percaya diri, mereka mungkin takut untuk berbicara selama retrospektif. Ini dapat membatasi efektivitas retrospektif. Banyak orang takut mengatakan "Saya merasa manajer tidak realistis" ketika manajer hadir.

Jadi, mungkin Anda minta diri dari retrospektif untuk menyelesaikan masalah ini. Sekarang tim Anda melakukan retrospektif tanpa master scrum, juga berpotensi membatasi efektivitas retrospektif.

Dalam kedua kasus, Anda memiliki dampak negatif pada tim.


2

Masalah utama yang saya lihat adalah bahwa Anda mengirim pesan yang bertentangan ke tim tentang organisasi tim.

Di bawah ini adalah dua organisasi tim yang mungkin. Keduanya bisa sukses. Mereka berbeda. (Mereka bukan satu-satunya pilihan yang mungkin.)

  1. Tim memiliki pemimpin yang ditunjuk secara resmi. Pemimpin tim pada akhirnya bertanggung jawab atas kinerja tim secara keseluruhan. Pemimpin tim mungkin tidak membuat semua keputusan, tetapi pemimpin tim memiliki keputusan akhir tentang semua keputusan.
  2. Tim ini mengatur diri sendiri dan tidak memiliki pemimpin yang ditunjuk secara resmi. Setiap orang di tim bertanggung jawab atas kinerja mereka sendiri dan keseluruhan tim. Scrum Master memfasilitasi proses Scrum, tetapi tidak diberdayakan untuk membuat keputusan sepihak untuk tim.

Sepertinya struktur tim Anda yang sebenarnya adalah # 1, tetapi dengan menggunakan terminologi dan beberapa proses dari Scrum, Anda menyiratkan bahwa strukturnya adalah # 2. Pendapat saya adalah bahwa # 1 bukan Scrum.

Di bawah ini adalah dua saran untuk bagaimana menyelesaikan konflik.

  1. Tetap melakukan hal-hal seperti Anda, tetapi jelaskan bahwa Anda adalah pemimpin tim dan Anda tidak mengikuti Scrum 100%. Mungkin akan membantu menjelaskan bahwa ketika Anda melihat nilai dalam memisahkan tugas seorang manajer dan scrum master, itu tidak layak untuk perusahaan.
  2. Serahkan tanggung jawab Scrum Master, sebanyak yang Anda bisa, kepada orang lain. Bahkan jika Anda masih harus mempertahankan beberapa tanggung jawab seperti membersihkan penghalang jalan dan membelokkan gangguan dari sisa organisasi, masih akan membantu jika sebagian besar pekerjaan Scrum Master dikerjakan oleh rekan kerja.

1

Apa negatif dari Manajer Pengembangan sebagai Scrum Masters?

Manajer pengembangan disewa untuk:

  • Selesaikan masalah pembangunan .
  • Pantau dan kurangi utang teknis.
  • Tumbuhkan staf teknis.

Latar belakang dan keahlian mereka membuat mereka cenderung untuk fokus pada masalah teknis .


Di sisi lain, manajer proyek / master scrum dipekerjakan untuk;

  • Pastikan kesuksesan proyek.
  • Tetapkan pekerjaan dan triase bug / pertanyaan ke sumber daya pengembangan yang sesuai.
  • Berkolaborasi dengan tim pengembangan untuk menghilangkan semua hambatan yang dapat menunda penyelesaian proyek.
  • Menyampaikan status proyek ke manajemen atas.

  • Ketika sebuah proyek atau perusahaan tumbuh ke ukuran tertentu, itu tidak efisien dan tidak bijaksana untuk meminta manajer pengembangan untuk melakukan kedua tugas.
  • Seorang manajer pengembangan harus cenderung mengambil "penyelaman dalam" ke dalam kode dan / atau arsitektur, sedangkan manajer proyek / master scrum harus selalu peduli dengan pandangan "50.000 kaki".

  • Sebagian besar manajer pengembangan telah menghabiskan bertahun-tahun mengembangkan kode. Masalah pembangunan sangat akrab bagi mereka.

    • Karena itu, mereka sangat berguna ketika mereka memecahkan masalah teknis.
  • Manajer proyek / peran utama scrum membutuhkan orang-orang yang sangat terorganisir dan sangat detail, tetapi tidak super-teknis.
  • Ketika Anda mampu membiarkan orang-orang ini mengkhususkan diri pada hal-hal yang mereka kuasai, bisnis itu paling efisien.
  • Dan ketika Anda dapat melepaskan tanggung jawab terkait scrum dari plat palungan pengembangan, ia dapat menghabiskan lebih banyak waktu untuk masalah teknis dan mengurangi utang teknis.

Saya telah menurunkan ini karena Anda tampaknya tidak menggambarkan manajer pengembangan atau master scrum dengan benar. Juga pertanyaan ini tidak ada hubungannya dengan manajemen proyek.
SpoonerNZ

0

Saya akan mendengarkan pelatih scrum berpengalaman. Ada kemungkinan bahwa Anda akan berhasil dengan baik untuk 99% dari waktu. Namun ketika 1% yang ditakuti muncul dan peran konflik Anda memiliki kesempatan untuk mengacaukan tidak hanya hubungan individu dengan Anda tetapi seluruh kesejahteraan tim. Dan setelah satu mengacaukan peran Anda sebagai master scrum dan manajer akan dirusak.

Jika saya jadi Anda, saya akan mengidentifikasi seorang individu dalam tim yang memiliki potensi untuk menjadi scrum-master dan pergi bersamanya. Saya selalu memandang master scrum sebagai seseorang yang dipercaya oleh tim dan yang memahami proses, bisnis, dan hal-hal teknis yang menakutkan juga. Jika Anda memilih orang yang cakap, peran master scrum bukanlah (dan bahkan tidak mendekati) pekerjaan penuh waktu.


3
Menjadi master scrum dapat dengan mudah menjadi pekerjaan penuh waktu tergantung pada lingkungan tempat Anda berada. Menghapus hambatan dan menjalankan interferensi untuk tim bisa sangat memakan waktu di perusahaan (terutama perusahaan birokrasi besar) yang tidak terbiasa dengan metode Agile.
Matthew Flynn

1
@ MatthewFlynn: Poin bagus. Namun ... dalam kasus itu, mereka akan memiliki sumber daya yang cukup untuk didedikasikan kepada scrummaster penuh waktu (saya mendapatkan perasaan dari pos bahwa ada kekurangan sumber daya). Namun, saya bekerja di salah satu perusahaan besar yang Anda sebutkan dan master scrum penuh waktu masih tidak selalu dijamin. Kami masih memiliki mereka tetapi mereka sering menghalangi tim melakukan pekerjaan mereka secara efisien karena mereka menyebabkan lebih banyak masalah ketika mencoba untuk membenarkan / berlebihan posisi penuh waktu mereka.
c_maker

1
Poin yang bagus segera kembali pada Anda. Saya kira itu tergantung pada perusahaan dan individu. Tidak mengherankan, sungguh.
Matthew Flynn

1
Terima kasih atas tanggapannya. Saya mencoba mengidentifikasi apa yang bisa menyebabkan, atau menjadi 'yang ditakuti 1%', karena saya tidak bisa melihat bagaimana perannya bertentangan begitu jelas bagi tim saya adalah seorang pelayan-pemimpin. Bagaimanapun, seorang pemimpin pelayan masih seorang pemimpin.
SpoonerNZ

Saya juga mempertimbangkan untuk menjadikan senior dev kami sebagai scrum master, tetapi kemudian secara realistis saya tidak bisa melihat banyak hal untuk saya lakukan! Pilihan lain yang saya pertimbangkan adalah menjadi scrum master dan bukan manajer, tetapi Kepala IT tidak akan menyukai gagasan manajemen orang dari seluruh tim yang jatuh hati padanya.
SpoonerNZ
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.