Scrum: Menangani kurangnya motivasi


11

Menurut ini , "Scrum sangat bergantung pada tim yang sangat termotivasi, berkolaborasi erat, lintas fungsi dan mengatur diri sendiri." Jadi, bagaimana Anda menangani rekan kerja yang mungkin tidak termotivasi untuk mengambil kepemilikan kode? Bagaimana Anda membuat seseorang tertarik untuk mengambil kepemilikan?


Mungkin mereka lebih suka menjadi pemilik kode yang berbeda? Tentu saja, jika kode yang dimaksud begitu beraroma sehingga TIDAK seorang pun ingin memilikinya, itu adalah masalah yang lebih besar ... dan BEBERAPA orang hanya perlu menyedotnya dan memiliki kode itu.
FrustratedWithFormsDesigner

2
Akan lebih baik untuk mencari dulu alasan di balik kurangnya motivasi. Ada kecenderungan untuk mengabaikan faktor manusia mulai dari konflik kepribadian dalam tim hingga kebijakan SDM perusahaan yang lebih disalahkan daripada memberikan kredit (mis: "pangkat dan tarik").
jfrankcarr

1
Tidak ada dalam artikel yang berbicara tentang memotivasi orang untuk memiliki kode. Sebenarnya Scrum tidak mendukung kepemilikan kode. Mengapa Anda mencoba memotivasi mereka untuk memiliki kode alih-alih beban kerja?
pdr

Jawaban:


14

Saya tidak tahu apakah ini masalah tim Anda, tapi itu pasti bagi kami ketika kami pertama kali memperkenalkan scrum. Manajemen kami datang kepada kami suatu hari dan berkata, mulai sekarang Anda tidak akan bekerja di silo individu. Sebagai gantinya, Anda akan bekerja sebagai scrum. Inilah sekelompok proses baru yang harus Anda ikuti dan ikuti semuanya.

Kuncinya adalah bahwa mereka tidak pernah datang kepada kami, para pengembang, dan bertanya, bagaimana Anda ingin bekerja? apa yang akan membuatmu lebih bahagia? lebih efisien?. Jadi yang saya dengar adalah, "Anda tidak lagi memiliki kode apa pun. Apa pun yang Anda tulis, akan diinjak-injak (Anda tahu, kepemilikan tim). Anda tidak akan bergerak atau mengangkat jari karena sekarang kami akan mengatur waktu Anda per jam". Oh, dan sekarang Anda memiliki waktu 15 menit untuk berdiri membosankan setiap hari di mana orang akan membahas hal-hal yang tidak Anda pedulikan dan biasanya akan memakan waktu 30 menit dan kemudian setiap dua minggu akan memiliki rapat perencanaan 4 jam yang membosankan dan pasti akan menyedot semua kehidupan keluar dari kamu.

Pada kenyataannya ini bukan Agile atau Scrum, ini hanya bergerak dari satu gaya manajemen ke gaya yang berbeda, di mana semuanya masih dikendalikan secara terpusat, dan tidak hanya menyedot semua kehidupan dari saya, tetapi juga memberi saya banyak gratis waktu untuk memperbarui resume saya.

Dalam dua belas bulan terakhir, setelah saya melobi berkali-kali agar manajer tim kami mencoba sesuatu yang berbeda, dia benar-benar menerima saran saya, dan saya pikir kami memiliki tahun yang sangat sukses.

Saya percaya perubahan utama bagi kami adalah memberi pengembang lebih banyak suara dan kebebasan dalam memilih bagaimana kami ingin bekerja. Beberapa hal yang kami lakukan:

  1. Hancurkan tim pengembangan "gesit" besar menjadi 3 yang kecil sehingga masing-masing hanya memiliki 3-4 pengembang. Ini membuat semua orang terlibat dan individu tidak tenggelam.
  2. Pastikan semua orang dalam tim yang sama bekerja di sekitar area fungsional yang sama sehingga orang-orang peduli dengan apa yang dibicarakan orang lain dalam perencanaan berdiri dan iterasi.
  3. Alih-alih manajemen hanya memilih siapa yang mengerjakan apa dan menugaskan cerita / tugas, kami datang dengan jaminan dan tim itu sendiri memiliki banyak pendapat tentang bagaimana pekerjaan dibagi.
  4. Karena kami memiliki banyak anggota baru, kami mulai dengan sistem silo di mana setiap orang memiliki area tanggung jawab utama. Hal ini memungkinkan orang baru untuk fokus pada area yang lebih kecil dari produk yang tidak dikenal dan juga lebih cepat merasa bahwa mereka tidak bermain di kotak pasir orang lain. Tapi 6-8 bulan setelah program, area-area itu mulai berubah ketika batas-batas menjadi lebih abu-abu. Sekarang orang-orang, di tim saya, cukup nyaman melangkah ke kode orang lain atau memiliki pengembang lain bekerja di dalamnya.
  5. Ulasan kode dari semua kiriman adalah kunci (dan ini adalah hal pertama yang kurang ketika kami pertama kali melakukan Scrum):
    • Transfer pengetahuan dalam hal teknik / metode pemrograman
    • Sangat bagus bagi orang lain untuk belajar kode yang mereka tidak akan lihat sebaliknya
    • Tim Anda mendapat kesempatan untuk berkomunikasi dan bersosialisasi yang meningkatkan dinamika tim
    • Dan saya kira, ulasan kode akan menangkap satu atau dua bug, tetapi saya melihat nilainya sebagian besar dalam aspek di atas.
  6. Manajemen harus mendengarkan tim. Jika tim mengatakan sesuatu tidak berfungsi atau perlu diubah, dan mereka mengabaikannya, maka anggota tim hanya akan memeriksa dan membiarkan manajemen menangani proyek. Jika Anda ingin orang termotivasi, mereka perlu diberi hak dan mereka hanya akan diberikan jika mereka melakukan apa yang mereka yakini benar, bukan apa yang mereka perintahkan untuk lakukan dari atas.

4

Ada banyak alasan untuk kurangnya motivasi, tetapi mungkin yang paling umum adalah tidak merasa seperti Anda memiliki suara. Ketika tim kami mulai melakukan scrum, saya perhatikan bahwa orang yang paling tidak termotivasi tentang scrum berbalik setelah mereka melihat saran dari retrospektif diimplementasikan.

Sekelompok masalah kecil dapat bertambah menjadi demotivasi. Sebagai contoh, satu hal yang muncul minggu lalu adalah anggota tim yang tidak suka pertemuan 4:00. Itu mudah diperbaiki.

Dengan kata lain, cara terbaik untuk mengetahui apa yang mendemotivasi tim Anda adalah dengan bertanya kepada mereka.


Apakah Anda memecat anggota tim yang tidak suka pertemuan 4 sore ?? ;)
Dave Hillier

3

Dengan memberi mereka kepemilikan individu atas kode.

Banyak toko yang menggunakan model "kepemilikan tim". Ini bagus untuk lintas kolaborasi dan mengurangi risiko, tetapi tidak terlalu bagus untuk memotivasi individu untuk bertanggung jawab secara pribadi. Kepemilikan tim dapat menghasilkan kode rata-rata, karena tidak ada insentif kepemilikan individu.

Solusi: Tetapkan individu ke setiap bagian kode untuk menjadi pengurus bagian kode tersebut, tetapi izinkan akses tim penuh ke seluruh basis kode.

Lihat juga: /software//a/33464/1204


Saya berpendapat untuk memastikan ini adalah area fungsional vertikal bukan bidang infrastruktur horizontal. Yaitu hal terburuk yang dapat Anda lakukan adalah memiliki Guy UI, Backend Guy, dan Database Guy karena untuk setiap bagian dari fungsi Anda akan membutuhkan ketiganya untuk berkolaborasi.
Michael Brown

1
Suara turun yang langka dari saya. Semua ini mengarah pada kebalikan yang tepat dari Scrum - dan pengembang yang bekerja pada alur kerja yang berbeda. Pengembang kehilangan pengetahuan lintas proyek dan ketika alur kerja A menjadi prioritas yang sangat tinggi, menjadi sangat sulit untuk menarik orang dari tempat lain. Tekanan ekstra diberikan pada individu yang memiliki area kode itu, dia berhenti dan Anda pergi dengan proyek yang gagal.
pdr

@ pdr: Anda menaikkan poin yang menarik. Saya pikir saya bisa belajar banyak jika Anda dan Robert Harvey memperdebatkan hal ini lebih lanjut.
Jim G.

@ Jim. Lihat jawaban DXM untuk tampilan yang lebih bernuansa dan komprehensif (yang kebetulan saya setujui).
Robert Harvey

1
@ Jim. Sangat memalukan, kadang-kadang, bahwa kita tidak memiliki forum (obrolan terlalu cepat, saya tidak punya waktu untuk mendedikasikan untuk diskusi) di mana beberapa pengembang berpengalaman dan tertarik, yang telah menghadapi masalah yang berbeda, dapat menghadang, memperdebatkan sesuatu dan kembali dengan jawaban gabungan. Saya sangat tertarik dengan yang satu ini, karena saya jarang tidak setuju dengan jawaban Robert di sini dan (mungkin lebih menarik) kami berdua sepakat dengan jawaban DXM.
pdr
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.