Apa negatif dari Manajer Pengembangan sebagai Scrum Masters?

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.

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 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 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.

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.

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.

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.

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 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.