Skeptis dalam Tim Scrum


14

Perusahaan saya baru-baru ini beralih ke cara kerja Agile dan sebagai bagian dari itu kami sudah mulai menggunakan SCRUM. Sementara saya sangat nyaman dengan itu dan merasa bahwa cara ini lebih unggul daripada yang tradisional, beberapa rekan tim saya tidak memiliki pendapat yang sama. Bahkan mereka sangat skeptis tentang "semua hal yang gesit", dan tidak menganggapnya serius. Sebagai contoh, salah satu rekan tim selalu terlambat menghadiri rapat, dan tidak terlalu peduli. Manajemen IMO berusaha untuk tidak memperhatikan hal ini (mungkin karena ini baru, dan perlu waktu bagi orang-orang untuk terbiasa dengannya).

Pertanyaan saya adalah, bagaimana cara mengatasi masalah ini sementara tidak menimbulkan konflik di dalam tim?


4
Apa itu WoW? Googling "WoW-warcraft lincah" ternyata tidak banyak.
Joe Daley

1
@ Jo - "Cara Kerja" mungkin?
ChrisF

Cara bekerja.
Sorantis

Scrum! bukan SCRUM! Wow? Agile # 1 = WoT, bukan WoW. Tanpa WoT, WoW itu hanya SNAFU. Dan salah satu cara berpikir utama adalah merobohkan hambatan komunikasi, bukan membangun yang baru.
MIA

2
Agile WoW = Menggerebek satu atau dua bos setiap malam selama seminggu dan melakukan pembersihan penuh? Dan memasangkan perampok / melakukan ulasan DPS? Maaf, mantan pemain WoW di sini.
Wayne Molina

Jawaban:


21

Ketika dihadapkan dengan skeptisme ekstrim saya mencoba beberapa hal:

1.) Saya mendemonstrasikan teknik seperti TDD, Penyebaran Berkelanjutan, Pemrograman Pasangan, Persyaratan Berkumpul dengan pengguna Anda, iterasi pendek, dll. Saya tidak menyebut teknik itu Agile atau kecapi tentang Agile Manifesto (saya menggunakan harpa tentang Pengerjaan Perangkat Lunak - tapi itu berbeda; p). Saya hanya menunjukkan kepada anggota tim alat dan teknik yang berguna yang membuat hidup mereka lebih mudah. Mereka cenderung naik kereta Agile begitu mereka melihat manfaatnya sehari-hari.

2.) Saya tidak langsung menukar dengan metodologi SCRUM (atau lainnya) yang meledak. Itu selalu terbaik untuk memperkenalkan aspek kecil dari Agile sekaligus.

3.) Saya setuju dengan skeptis (to the point). Agile bukan peluru perak dan SCRUM, Kanban, Lean dll juga bukan peluru perak. Alih-alih, saya bekerja dengan mereka untuk melihat aspek apa yang bisa menguntungkan mereka dengan segera (server CI biasanya tidak punya otak) dan kemudian saya uji coba sisanya "Mari kita coba stand-up selama satu minggu dan kemudian memeriksanya".

Seperti metodologi apa pun, SCRUM dan lainnya perlu benar-benar bekerja dengan tim dan organisasi, bukan mengasingkan mereka.

Jadi untuk langsung ke pertanyaan Anda. Angkat bersama tim:

"Saya juga sedikit skeptis tentang stand-up, tapi saya pikir sebagai tim kita harus mencobanya selama 1 minggu (tanpa alasan!) Dan kemudian memeriksanya untuk melihat apakah itu bekerja untuk kita. Apa yang orang lakukan berpikir?"


9
@ Atlantis - Itu sebenarnya bukan masalah Agile WoW kan? Sepertinya anggota tim ini tidak pandai bekerja dalam tim! Itu lebih dari masalah psikologi manusia / perilaku dan trik untuk itu umumnya untuk mengetahui apa yang memotivasi orang itu (baik dalam perilaku positif dan perilaku negatif mereka).
Martijn Verburg

4
++ Ketika dipaksakan, itu seperti agama, dan orang-orang secara alami tahan. Ketika menjelajahi fitur demi fitur, itu lebih seperti akal sehat, dan jika orang mengatakan "tapi pada dasarnya itulah yang kami lakukan" maka Anda menang. Saya pikir bagian dari masalah dengan Agile adalah ia memiliki nama, dan karena itu berasal dari luar.
Mike Dunlavey

1
Pasangan pemrograman Ahhh - di situlah 1 orang membaca majalah sementara kode lainnya :)?
Chris S

2
@ Martijn, saya sudah melakukan pemrograman pasangan di mana satu orang memiliki mouse dan yang lainnya memiliki keyboard. Dengan begitu keduanya harus berkonsentrasi;)
Benjol

1
@Mike Dunlavey: "jika orang mengatakan" tetapi pada dasarnya itulah yang kami lakukan "maka Anda menang." - Atau mungkin Anda memperkenalkan beaurokrasi yang tidak berguna? jika mereka melakukannya dengan benar, maka apakah mereka benar-benar membutuhkan aturan Anda tentang bagaimana melakukannya?
imre

16

Kasus tipikal Scrum yang diterapkan secara salah .

Scrum telah dibebankan pada tim. Tim (keseluruhan) tidak memilihnya.

Ketika Anda ingin mengimplementasikannya, Anda harus memiliki dukungan penuh dari tim dan manajemen, atau itu tidak akan berfungsi sama sekali.

Perlawanan untuk berubah adalah musuh Anda di sini.

Saya sangat menyarankan Anda untuk memulai kembali dan menyerahkan Scrum kepada tim dan membiarkan mereka mengajukan pertanyaan.

Jika Anda gagal menjual ide, jangan coba memaksa mereka menggunakan metodologi yang tidak mereka inginkan. Mereka akan melakukan segalanya untuk menyabotnya. Datang terlambat di stand up harian adalah salah satu perilaku yang akan Anda dapatkan.

Harap dicatat bahwa Scrum mungkin tidak disarankan untuk perusahaan Anda. Satu-satunya orang yang dapat menjawab pertanyaan itu adalah orang-orang yang bekerja di pangkalan. Tim .


1
Apakah ada cara untuk membuat orang skeptis menyukai SCRUM? Ini agak lemah untuk dilakukan - jangan gunakan itu jika Anda tidak menyukainya.
Sorantis

1
@ Atlantis: tidak ada cara mudah untuk melakukan itu. Anda harus menginvestasikan banyak upaya dan waktu untuk menjelaskan bagaimana Scrum akan memberikan manfaat kepada mereka . Kenyamanan status quo sangat penting sehingga mereka akan melakukan apa saja untuk mempertahankannya. Bahkan memaksakan diri untuk tidak memahami manfaatnya. Itulah yang terjadi ketika Anda memaksakan ide-ide Anda kepada orang lain. Situasi Anda sangat sulit untuk dipecahkan.

@ Atlantis - ini terjadi setiap hari. Ini disebut penjualan. Terus tunjukkan hal-hal baik yang telah dibawa oleh SCRUM kepada Anda. Peningkatan komunikasi! Beradaptasi untuk berubah! Menyederhanakan proyek! Jangan terlalu baik menggunakan karya Pavlov. ;-) Orang merespons diperlihatkan, kurang diberi tahu. Tunjukkan pada mereka seberapa baik SCRUM bekerja untuk Anda, dan mereka akan mengikuti dari waktu ke waktu.
Steve Goodman

Itulah yang dikatakan Stalin.
Pekerjaan

Stalin berkata apa?

5

Mungkin konsep pertemuan harian tidak berlaku dengan baik untuk apa yang dilakukan seseorang. Pertemuan-pertemuan itu tidak gratis.

Jika apa yang Anda lakukan membutuhkan banyak konsentrasi jangka panjang, seperti matematika yang berat, rapat dapat membuat Anda tidak nyaman dan membuat frustrasi. Saya bekerja dengan seseorang seperti itu, yang lebih suka bertemu setiap minggu, yang sangat masuk akal.


5

Sebenarnya jujur ​​jika saya berada di tim pemrograman Anda, saya mungkin akan skeptis! Saya telah melihat sederet metodologi yang seharusnya merevolusi berbagai hal dan membuat proyek masuk tepat waktu, sesuai anggaran, dan bebas bug. Ini baru terbaru. Mengapa saya harus percaya pada minyak ular? 10 tahun yang lalu orang yang sama mencambuk sesuatu yang lain, dalam beberapa tahun akan datang sesuatu yang baru. Jangan salah paham, saya pikir beberapa metodologi baru membawa beberapa ide berguna. Sayangnya mereka membawa banyak dogma dan ide-ide bodoh juga.

Apakah itu penting jika dia tidak naik? Cukup berikan dia beberapa tugas pemrograman dan biarkan dia melakukannya seperti yang dia inginkan. Jika pekerjaannya memuaskan, biarkan saja. Jika pekerjaannya tidak memuaskan, gantikan dia. Mengapa begitu penting bagi orang untuk mengikuti scrum?

Selama bertahun-tahun saya telah melihat banyak programmer yang baik berhenti atau merasa kesal karena manajer mereka terus memperkenalkan metodologi baru. Mereka hanya ingin kode dan menyelesaikan pekerjaan. Percayalah kepada saya beberapa tahun dari sekarang Anda akan mengutuk scrum, dan melompat pada apa pun mode terbaru.


-1. Sekalipun scrum tidak ada di sini untuk tinggal, Anda masih menjadi bagian dari suatu organisasi. Jika organisasi itu memutuskan untuk pindah ke scrum, maka sangat sedikit kesulitan untuk bergerak bersama. Jika Anda seorang programmer dan pemain tim yang baik, dan Anda bersedia menerima bahwa ada orang lain yang tahu lebih banyak tentang prioritas komersial, maka scrum akan memungkinkan Anda untuk melakukan pekerjaan Anda, dengan cara Anda. Jika dilakukan dengan baik, scrum tidak boleh memakan waktu lebih dari 10% dari waktu Anda. Dalam 10% itu, Anda juga telah melakukan perencanaan dan pelaporan. Huu huu.
Kris Van Bael

1

Jika Anda tangkas maka Anda harus memiliki backlog yang sedang Anda kerjakan. Gunakan scrum untuk membagikan tugas dari backlog.

Tugas pilihan (terbaik) dipilih terlebih dahulu di awal pertemuan. Ketika Anda terlambat datang, berikan saja apa yang tersisa untuk hari itu.

Tidak masalah jika dia adalah anugerah Tuhan untuk pemrograman, dia mendapatkan tugas jelek yang tidak diinginkan orang lain. Jika ia mencoba memperkuat tugas lain atau mengerjakan sesuatu yang lain, tim secara keseluruhan perlu bersandar padanya dan memaksanya untuk hanya mengerjakan tugas "yang dipilih" -nya. Anda mungkin harus memiliki master bangunan yang dapat menolak perubahannya jika dia tidak mengerjakan pekerjaan yang dipilih.

Juga tim harus menetapkan tujuan dan kemungkinan kompensasi. Anda dapat memilih sebagai tim untuk tidak memberi penghargaan kepada mereka yang tidak berpartisipasi. Ini bervariasi pada jumlah kepemilikan yang diberikan manajemen Anda kepada tim tangkas Anda. Ingatkan manajemen mereka yang menyakiti tim dan mencegah tim agar tidak berhasil.

Ingatkan dia bahwa jika dia datang tepat waktu dia dapat berpartisipasi dalam proses.


Dengan cara ini Anda akan kehilangan kesempatan terakhir untuk menjual Scrum ke pihak yang skeptis. Masalah sebenarnya adalah metodologi yang dipaksakan, seperti yang disarankan oleh jawaban lain.
MaR

1

Tim scrum seharusnya mengatur diri sendiri. Scrum juga berfungsi dengan menerapkan transparansi ekstrem dalam segala hal.

Jadi jawaban yang jelas adalah bahwa Scrum Master mengadakan pertemuan, menjelaskan masalahnya (tapi jangan menipu diri sendiri, semua orang di tim sudah tahu persis apa masalahnya) dan kemudian memberi tahu mereka bahwa mereka punya 1 jam untuk mencari tahu apa mereka akan lakukan. Lalu dia duduk di sudut dan tutup mulut.

Jelas, ini adalah tim baru untuk Scrum. Jadi kuncinya adalah bahwa Scrum Master harus menerima jawaban apa pun yang dihasilkan oleh tim. Jika dia mengesampingkan mereka, atau memaksakan ide-idenya sendiri ke solusi dia akan menghancurkan kepercayaan tim perlu membangun bersamanya bahwa mereka diizinkan untuk mengatur diri sendiri. Mungkin saja tim akan memutuskan untuk tidak melakukan apa pun.

Dalam hal apa pun, masalah tersebut harus ditinjau di Sprint Retrospective dan kemanjuran solusi apa pun yang mereka buat dapat didiskusikan.

Menghindari "konflik tim" bahkan seharusnya tidak menjadi faktor sama sekali.


0

Memecat rekan satu tim, maka dia tidak akan menimbulkan kontroversi di dalam tim.


1
Saya kira ini bukan solusi sama sekali. Ini seperti, tanganku sakit..Oh, mari kita potong saja.
Sorantis

4
Itu tergantung - jika perusahaan telah memilih untuk mengimplementasikan SCRUM dan staf memebers tidak mau bekerja seperti yang disyaratkan oleh bisnis maka itu alasan yang cukup klasik untuk pemberhentian.
Murph

@ Atlantis: lebih seperti, "jika tangan kiri menyinggungmu, potong jika", atau sesuatu seperti itu. Dan, peringatkan dia dulu.
John Saunders

2
@Rob: lanjutkan prosesnya, jelaskan apa yang diharapkan dari orang yang skeptis, dan jika dia tidak mau melakukan apa yang diminta, biarkan dia pergi, atau memecatnya. Gagal melakukan itu mengirimkan pesan yang salah ke seluruh tim - bahwa SCRUM tidak masalah, dan bahwa mereka semua dapat mengabaikannya, sama seperti orang yang skeptis.
John Saunders

2
Agile adalah tentang tim. Jika Anda memiliki seseorang yang menolak untuk menjadi bagian dari tim maka manajemen perlu menempatkan mereka dalam masa percobaan atau membiarkan mereka pergi. Dalam jangka panjang Anda akan lebih baik dengan tim yang berjalan lancar dengan seseorang yang menyebabkan masalah. Saya telah mendengar banyak kisah tentang tim tangkas yang dihancurkan oleh satu apel jahat.
Bill Leeper

0

Jelajahi karya lama Anda, gali beberapa contoh bagaimana pendekatan water-fall mengecewakan Anda berkali-kali di masa lalu. Kemudian sampaikan kasingnya ke rekan setim Anda. Dengan sekilas akal sehat, dia akan melihat cahaya.

Pemrograman adalah kegiatan presisi sehingga individu yang langka akan tetap tidak menerima fakta-fakta sulit. Setidaknya, secara teori.


Masalahnya adalah saya karyawan baru di perusahaan. Saya datang ketika mereka sudah mulai menggunakan WoW tangkas. Dan rekan satu tim saya bekerja di perusahaan selama 15 tahun
Sorantis

2
Saya hanya salah membaca "air-jatuh" sebagai "air-gagal" dan itu adalah penggantian nama terbaik dari pendekatan pembangunan yang pernah saya lihat. Luar biasa!
glenatron

@ Glenatron: Sangat bagus, sangat menyentuh kuku.

3
Masalah dengan pendekatan menggali contoh tandingan adalah mereka bukan argumen yang baik mendukung ide spesifik lainnya. Tidak ada yang suka jatuh air, tetapi itu tidak berarti mereka ingin bergabung dengan Agile.
Mike Dunlavey

0

Siapa yang membuat keputusan untuk beralih dan mengapa? Di mana mereka yang skeptis dalam mengambil keputusan sama sekali atau apakah keputusan itu hanya dijatuhkan pada mereka?

Apakah Anda terlalu kaku dan / atau cepat dalam penerapan metode baru Anda? Apakah Anda mengeluarkan produk yang bagus (belum tentu sempurna) menggunakan metode lama Anda? Sudahkah Anda menunjukkan kepada orang skeptis bagaimana itu akan bermanfaat bagi mereka? Bisakah Anda menunjukkannya? Apakah mereka yang telah "melihat cahaya" mendemonstrasikan skeptis bagaimana hal itu bermanfaat bagi mereka, tim dan perusahaan?

Mungkin Anda meminta mereka untuk menerima segalanya hanya berdasarkan perkataan orang-orang percaya. Kemungkinan besar skeptis ini telah mengambil metodologi baru sebelumnya dan tidak ada manfaat di mana pun terwujud.

Mungkin Anda dapat melakukan satu atau dua proyek dengan hanya orang percaya yang mengerjakannya menggunakan prosedur baru Anda. Ambil pengukuran nyata dan tunjukkan pada orang skeptis manfaat nyata. Mungkin bahkan mengadakan kompetisi kecil antara orang-orang skeptis dan cara lama mereka dengan orang-orang percaya dan cara baru mereka.

Tentu saja apa yang Anda lakukan jika skeptis menang?


Saya bukan manajer, saya hanya anggota tim. Keputusan telah dibuat oleh manajemen
Sorantis

0

Adakan rapat tim untuk membahas dan mencari tahu mengapa perusahaan Anda beralih ke SCRUM dan minta semua orang untuk mengidentifikasi pendapat mereka tentang SCRUM akan menambah nilai pada mode operasi saat ini. Kadang-kadang perusahaan benar-benar membuat saklar bertulang (saya telah berada di rapat scrum di mana tidak ada yang benar-benar mendengarkan dan semua orang hanya mengoceh tentang apa yang mereka lakukan kemarin dan pergi. Tim-tim ini biasanya mencapai keseimbangan seperti - "Saya tidak akan menanyai Anda dan Anda tidak mengacaukan dengan saya "dan berlenggak-lenggok di sana. Itu hanya buang-buang waktu), Jadi ambil yang terbaik untuk Anda.

Veteran biasanya memiliki banyak perlawanan terhadap apa pun yang dapat mengubah gaya kerja mereka saat ini, Jadi Anda harus memastikan ada cukup banyak wortel bagi mereka untuk melepaskan kelembaman mereka. Dalam hal ini, saya akan memiliki 1: 1 dengan orang itu atau menjadikannya scrum master :). Setelah Anda memberi mereka tanggung jawab, mereka akan menemukan kedamaian dengan itu atau menghapusnya sepenuhnya karena itu tidak menambah nilai. Keduanya sama-sama menang.

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.