Anggota tim yang dominan dalam tim Scrum


22

Apa yang akan Anda lakukan dalam situasi di mana seorang anggota tim mencoba untuk mengambil tanggung jawab pada awalnya tidak ditugaskan kepadanya tetapi kepada Scrum Master?


5
Haruskah ini dipindahkan ke pm.stackexchange.com ?
Abdel Raoof

1
Saya tidak yakin bagaimana ini benar-benar berhubungan dengan Scrum, atau pemrograman dalam hal ini. "Anggota tim yang dominan membayangi semua orang di tim".
ozz

5
Saya tidak setuju dengan pindah ke pm.stackexchange.com karena master Scrum bukan PM dan proyek Scrum seharusnya tidak memiliki PM.
Ladislav Mrnka

3
Sepertinya Anda satu-satunya di tim Anda yang peduli. Tantang dia untuk berduel.
JeffO

2
Saya kehilangan konteks penting dalam pertanyaan ini. Bisa jadi 'dominan' dev mengambil lebih banyak tanggung jawab karena dia benar-benar merasa scrum master sedang berkinerja buruk dan sedang berusaha meningkatkan kinerja tim, mungkin dia ingin memberi makan egonya dan keterampilan unggul, mungkin dia bertindak dengan niat baik dan hanya tidak menyadari efek merusak potensial pada tim, mungkin dia hanya brengsek ... atau mungkin scrum master sendiri masalahnya.
MaR

Jawaban:


17

Tim Scrum diatur sendiri sehingga ada ruang untuk seseorang yang sedikit lebih dominan. Orang lain harus menanyakan ide-idenya tentang tugas yang sedang mereka kerjakan, tetapi dominasinya harus tetap terkendali.

Apa yang dapat Anda lakukan:

  • Memotivasi orang lain untuk menjadi mandiri tetapi kolaboratif - ini dapat dicapai terbaik jika Anda bekerja sama dengan manajer dan SDM mereka yang akan memberi mereka beberapa harapan, yang akan dievaluasi secara teratur.
  • Selama stand-up, perencanaan, dan retrospektif; biarkan anggota tim yang lain berbicara terlebih dahulu. Selama ulasan, biarkan anggota tim lain menyajikan cerita pengguna yang mereka implementasikan.
  • Biarkan yang lain memilih tugas terlebih dahulu sehingga pengembang dominan tidak hanya dapat memilih tugas yang ingin dia lakukan.
  • Libatkan pemrograman pasangan untuk beberapa tugas sehingga anggota tim yang dominan berkolaborasi dengan pengembang lain.
  • Jadilah Demokrat - pendapat satu anggota tim tidak cukup untuk melakukan perubahan pada proses - Scrum hanya akan berfungsi jika tim berkomunikasi dengan jelas, atau Anda hanya akan saling menghalangi.
  • Jika tidak ada yang membantu Anda harus berbicara dengan anggota tim yang dominan dan menjelaskan situasinya kepadanya - tetapi berhati-hatilah tidak ada pemimpin tim di Scrum karena suatu alasan. Jika Anda memiliki dukungan dari manajemen, Anda juga dapat mengancam stabilitas pekerjaannya, tetapi ini harus menjadi pilihan terakhir.

Jika anggota tim yang dominan tidak ingin kehilangan dominasinya dan anggota tim yang pasif tidak ingin menjadi lebih aktif, Anda akan memerlukan dukungan dari manajer dan SDM mereka. Ini bisa menjadi masalah jika proses Scrum tidak didukung oleh manajemen.


14

Agaknya, alasan untuk pertanyaan ini adalah karena Anda merasa bahwa tim itu entah bagaimana kinerjanya rendah karena orang yang dominan ini. Mungkin karena anggota tim lainnya tidak berkontribusi 100% karena, well, apa gunanya?

Sebagai seorang manajer, jika demikian, Anda bertanggung jawab untuk memastikan bahwa semua karyawan Anda memahami apa peran mereka. Secara khusus, apa yang diharapkan dari mereka dan bagaimana mereka akan dievaluasi. Sebagai anggota tim dalam tim Scrum, setiap orang secara pribadi bertanggung jawab atas keberhasilan tim. Jadi anggota tim yang mendominasi ini perlu tahu bahwa mereka gagal dalam tanggung jawab itu, dan akan dievaluasi sesuai.

Umpan balik adalah poin kunci. Jika ada pertemuan tim dan orang ini mendominasi diskusi, memaksakan desain dan pendekatannya pada anggota tim lainnya dan mendorong mereka yang lain ke dalam peran pasif maka dia perlu diberitahu, terus terang dan secara pribadi, bahwa dia gagal memenuhi persyaratan. peran. Jika Anda melihatnya secara diam-diam menyoroti hanya pencapaian pribadinya sendiri, maka ia perlu dipanggil, dan dibuat untuk memahami bahwa prestasi pribadi dihargai jauh, jauh lebih sedikit daripada membantu tim untuk memiliki pencapaian kelompok.

Semua itu sulit, tetapi untuk itulah para manajer dan Scrum Masters diperuntukkan.

Ada satu cara lain yang memungkinkan untuk melakukan ini. Jadikan itu masalah tim. Panggil mereka bersama-sama dan beri tahu mereka bahwa mereka kurang berprestasi dan inilah alasannya. Minta mereka untuk menemukan solusi. Anda mungkin akan terkejut.


1
Jawaban yang sangat bagus.
Ladislav Mrnka

Saya suka fokus Anda pada umpan balik.
ngeri

7

Mengapa tidak meminta pendapat pengembang alfa. Sangat mungkin dia tidak tahu efek apa yang dia alami. Bawa dia ke samping dan katakan apa yang Anda pikirkan. Anda bahkan dapat menulis diskusi "hei Anda pengembang utama kami, tetapi kami perlu membawa orang-orang ini ke tingkat Anda, saya perlu bantuan Anda dalam bekerja bagaimana kita bisa melakukannya?". Ubah dominasinya menjadi aset. Lihat apakah dia bisa melihat cara melakukan itu.

Jika dia mengukur seberapa baik dia mendukung timnya dan membawa mereka ke levelnya maka dia akan memiliki motivasi lebih untuk melakukan hal itu.

Anda menyiratkan dia sebenarnya tidak bekerja untuk kepentingan tim (tebakan saya), yaitu dia jahat dalam beberapa hal, maka ya, singkirkan dia. Tetapi seorang yang bijak pernah berkata kepada saya: Jangan menganggap niat buruk, ketika ketidakmampuan atau ketidaktahuan sederhana lebih mungkin terjadi.


Itu cara yang luar biasa untuk membingkai ulang masalah. Meminta bantuannya benar-benar mengubah situasi (dan membuatnya jauh lebih tidak menakutkan).
Joe White

5

Sepertinya dia mencoba menjadi Scrum Master.

Klarifikasi posisi Anda, dan bertindak sesuai itu.

Peran Master Scrum adalah untuk mengaktifkan semangat tim. Jika Anda tidak dapat membuat yang ini dan satu-satunya orang menjadi pemain tim, keluarkan dia dari tim .

Catatan cepat: Pengembang dominan Anda tidak lebih bermasalah daripada pengembang pasif Anda.


3
Sementara kalimat yang bagus, menghapus seseorang dari tim lebih mudah diucapkan daripada dilakukan dalam banyak kasus, saya akan berpikir Pierre.
ozz

@ James: bisakah Anda memberi tahu saya alasannya?

Nah, memiliki orang yang terbatas untuk mengerjakan satu proyek untuk satu. Memindahkannya ke tim lain, tim lain merasa tidak nyaman dan mungkin menolak. Retensi pengetahuan pada suatu proyek akan menjadi hal lain (mudah untuk mengatakan bahwa pengetahuan harus disebarkan, tetapi kenyataannya tidak). Itulah 3 alasan yang SANGAT NYATA mengapa lebih mudah diucapkan daripada dilakukan. Bukannya itu tidak bisa dilakukan tentu saja. Tentu saja mungkin maksud Anda memecatnya :-)?
ozz

1
Saya berbasis di Inggris, dan memiliki kepribadian yang dominan bukan alasan untuk memecat seseorang, Anda akan membutuhkan lebih dari itu!
ozz

1
@Pierre - jauh lebih sulit memecat orang di Inggris daripada mengatakan AS. Namun menunjukkan pola perilaku dan peringatan buruk, maka ya tentu saja seseorang bisa dipecat. Saya tidak yakin situasi khusus ini akan mudah memecat seseorang dari Inggris. Saya bisa saja salah.
ozz

2

perencanaan sprint saat ini adalah peran yang berputar di tim

Perencanaan sprint harus melibatkan seluruh tim, tidak diserahkan kepada satu orang pada satu waktu. Kecuali ada alasan bagus untuk ini saya melihat ini sebagai masalah yang parah.

Jika apa yang Anda katakan adalah benar dan objektif, maka Anda memiliki masalah besar di tangan Anda: orang yang tidak berpartisipasi dan "Dominator" yang mencegah proses yang benar-benar gesit. Sebagai master srum, tergantung pada Anda untuk mengambil tindakan. Mungkin Anda ingin meyakinkan manajer proyek Anda tentang situasi ini.


2

Banyak tim tersesat dari inti lincah, dan tugas Anda adalah mengembalikannya. Anda perlu mengajar dan menanamkan kembali nilai-nilai lincah ke dalam tim. Bahkan, Anda harus terus - menerus mengajarkan nilai-nilai lincah. Pertahankan visi Anda yang gesit, jernihkan dan kuat. Tunjukkan pada mereka komitmen Anda untuk "gesit dilakukan dengan baik".

Untuk melakukan ini, berjalanlah mereka melalui nilai-nilai manifesto tangkas dan Scrum. Tanyakan kepada mereka apa arti kolaborasi bagi mereka dan mengapa itu penting. Tanyakan kepada mereka tentang peran kepercayaan dalam gesit. Ini adalah saat yang tepat untuk membicarakan mengapa tidak ada peran memimpin tim dan tidak ada peran manajer proyek di Scrum dan bahwa adalah tanggung jawab seluruh tim untuk membuat perangkat lunak yang hebat, bukan individu.

Rencanakan seluruh sesi retrospektif tentang ini. Buat mereka untuk berkomitmen pada beberapa nilai dan menindaklanjuti selama retrospektif berikutnya. Jangan arahkan jari, gunakan metode netral.

Perkenalkan metode yang memaksa anggota lain untuk menyatakan pendapat mereka dengan aman. Sesuatu yang sederhana seperti kepalan lima sangat bagus untuk membuat suara bisu dalam tim terdengar. Sangat jelas bahwa tim tidak setuju dengan lelaki dominan. Perencanaan Poker bekerja dengan baik tetapi kuncinya adalah tidak memungkinkan diskusi apa pun sebelum kartu ditampilkan. Apa pun yang membantu membuat orang lain didengar tanpa memulai konflik sangat membantu.

Jika itu berjalan dengan baik, Anda siap. Kalau tidak, bicarakan dengannya tentang masalahnya. Gunakan pembinaan dan ajukan pertanyaan yang kuat yang dapat membantunya mewujudkan masalah dengan jelas. Cobalah untuk sampai ke akar penyebab mengapa ia mengambil peran dominan. Mungkin dia kurang percaya pada tim (mengapa?) Dan mungkin dia merasa dia bertanggung jawab untuk sukses (mengapa?). Saya menduga peran ini bukan sesuatu yang dia inginkan dan sangat mungkin dia ingin itu berubah. Dia mungkin datang dan menyadarinya.


1

Mungkin dev "dominan" dihargai oleh kinerja pribadinya daripada prestasi tim?

Di masa lalu saya telah memastikan bahwa orang-orang yang sangat vokal dan memiliki gagasan yang jelas juga dihargai (melalui tujuan mereka) dengan mendorong kontribusi orang lain.

Secara umum, saya pikir itu adalah ide yang buruk untuk menghargai anggota scrum dengan solid atas kontribusi individu mereka daripada pada pencapaian tim.

Anda juga dapat mencoba melakukan putaran umpan balik 360 di tim Anda untuk semua anggota tim, hanya jika Anda berpikir anggota tim lainnya akan jujur ​​dalam komentar mereka.


1

Usulkan bahwa ia menjadi Scrum Master untuk sprint berikut.

Orang-orang yang mau memikul tanggung jawab bukanlah masalah (selama mereka tidak ingin memonopoli mereka), justru itulah yang ingin kita capai dengan pengaturan diri.

Ngomong-ngomong, tim dengan peran master scrum yang berputar tidak jarang.


0

Satu-satunya tugas master Scrum adalah memastikan semua orang bermain sesuai aturan buku Scrum. Jika master non-scrum akan melakukannya sendiri tanpa gangguan dari master Scrum, itu hanya akan menunjukkan Anda dalam kondisi (Scrum-) yang hebat! Semakin sedikit yang harus dilakukan master Scrum, tim Anda lebih jahat dan lebih ramping dari perspektif Scrum. Akhirnya peran master Scrum bisa / harus dihilangkan, dia ada di sana untuk membantu Anda memulai dan mengajar Anda Scrum.

Sekali lagi, master Scrum tidak berpartisipasi dalam proses pengembangan. Dia harus memastikan semua pemangku kepentingan berkomunikasi tepat waktu tentang hal-hal yang benar, dia tahu Scrum dan memberikan panduan untuk melakukan Scrum, dia bukan pemilik produk atau pemimpin proyek. Jika Anda mengalami sesuatu yang berbeda, Anda mungkin tidak melakukan Scrum dengan semangat lincah. Tentu saja, dalam pengaturan yang lebih kecil, master Scrum dapat menjadi peran yang dimainkan salah satu anggota tim atau pemegang pasak di samping. Maka itu hanya topi yang dikenakan ketika saatnya untuk formalitas. Jangan bingung dengan peran kepemimpinan, itu adalah peran bimbingan.


-1

Merangkul individualisme dan kinerja individu, tetapi juga mencoba memberdayakan individu pasif untuk menjadi lebih partisipatif.

Pengalaman saya mengatakan bahwa meskipun mereka mungkin tampak serupa pada pandangan pertama, komunisme dan lincah tidak sama. Agile tidak bertujuan untuk masyarakat tanpa kelas (tim) tetapi untuk perangkat lunak yang berfungsi.

Cobalah untuk membuat pengembang alfa Anda mengerti bahwa ia dapat membantu Anda mengembangkan keterampilan orang lain dengan bertanya dan melatih, daripada selalu menjawab terlebih dahulu, dan mencapai prestasi individu. Tentunya pengembang alpha Anda adalah yang peduli dengan perangkat lunak yang baik, dan itu adalah sesuatu yang tidak dapat Anda biarkan hilang.

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.