Mengapa dan untuk alasan apa pengembang mungkin tidak menyukai "scrum harian"? [Tutup]

Ada keuntungan dalam memegang scrum harian, seperti:

1. Tim saling berkoordinasi
2. Semua orang tahu berapa banyak tugas yang telah dilakukan
3. Burndown chart menjadi semakin lengkap
4. Papan tugas diperbarui
5. Itu tidak bertahan lama, 15 menit tidak akan membunuh siapa pun

Namun, baru-baru ini (setelah 6 bulan menerapkan dan menggunakan scrum), saya merasa bahwa pengembang kami tidak terlalu menyukai scrum setiap hari. Orang-orang hanya memperbarui papan tugas, tanpa cukup menjelaskan dan tampaknya mereka bosan karenanya. Saya melihat bahwa ketika karena alasan apa pun, kami tidak memegangnya, mereka baik-baik saja menjadi sangat bahagia.

Aku hanya tidak tahu apa yang salah dengan ini. Apakah ada alasan yang disebutkan di suatu tempat untuk kerugian "scrum harian" dapat miliki untuk tim? Apa yang bisa menjadi alasan bagi pengembang bosan dengan scrum harian?

Saya memiliki pengalaman berpartisipasi dalam tim "SCRUM" dengan beberapa majikan. Tampak bagi saya bahwa para manajer mengambil "rapat scrum harian" sebagai poin utama SCRUM, dan menetapkannya sebagai tujuan, alih-alih memilikinya seperti apa adanya: cara untuk mencapai siklus pengembangan yang lebih efektif .

Sangat cepat rapat 15 menit menjadi rapat 45 menit, pembaruannya tidak efektif karena orang akan sibuk menguap dan berpikir "kapan kita bisa pergi" daripada mendengarkan orang lain, dan itu juga akan merusak rutinitas orang (saya, misalnya, seorang burung hantu, dan mulai bekerja pada jam 9 pagi untuk pertemuan bodoh ini setiap hari adalah alasan yang cukup baik bagi saya untuk keluar dari pekerjaan).

Ketika manajer mengambil beberapa ide yang mungkin bagus jika diterapkan dengan benar, dan membawanya ke ekstrem - mereka mendapatkan kebalikan dari hasil yang mereka harapkan. Saya pribadi berpikir bahwa semakin banyak pertemuan yang saya ikuti - semakin sedikit pekerjaan yang saya lakukan. Saya memiliki 2 pertemuan rutin seminggu di kalender saya dan saya biasanya melewatkan salah satunya. Rapat adalah untuk manajer, biarkan pengembang melakukan pekerjaannya.

Saya yakin akan ada banyak penggemar SCRUM yang akan mengatakan "Tapi ini luar biasa" - yah, selamatkan, saya sudah mendengar semuanya.

Saya akan menemukan setiap hari berdiri membosankan dan tidak berguna jika saya merasa ada sedikit atau tidak ada nilainya di dalamnya. Ada beberapa hal yang dapat mengurangi utilitas standup harian.

• Informasi yang dibagikan tidak pernah menyinggung atau memengaruhi saya dengan cara apa pun.
• Tidak adanya kepemilikan tim dan semua orang selalu mengerjakan proyek mereka sendiri.
• Tidak adanya komunikasi tim di luar standup.
• Kurangnya kemajuan yang terlihat atau dikomunikasikan.
• Tidak adanya informasi untuk dibagikan.

Ini hanya di luar kepala saya, tetapi selalu ada alasan yang lebih mungkin.

Mungkin Anda harus bertanya langsung kepada pengembang mengapa mereka tampaknya tidak tertarik? Jika Anda ingin lebih banyak / komunikasi yang lebih baik itu harus dimulai dengan Anda.

Beberapa masalah yang terjadi dengan pertemuan SCRUM harian:

• mereka yang bertahan terlalu lama. Anda tidak ingin ada manajer pria di harian itu karena mereka adalah akar penyebab masalah semacam ini. Lihat bagaimana biasanya mereka yang menggunakan kursi (ya, harus membela mereka adalah untuk memikat orang agar cepat)
• harus mendengar tentang seseorang (atau 2 atau 3 devs) yang menggambarkan masalah terisolasi apa pun yang ia miliki alih-alih memutuskan untuk menjadwalkan pertemuan nyata lain nanti untuk membahasnya dengan yang bersangkutan
• jam bodoh. Pertemuan-pertemuan itu tidak harus terjadi di pagi hari: Anda tidak berbicara tentang apa yang telah Anda lakukan kemarin dan memutuskan apa yang akan Anda lakukan hari ini; Anda berbicara tentang apa yang telah Anda lakukan antara harian terakhir dan yang satu ini dan memutuskan apa yang akan Anda lakukan sampai yang berikutnya.
• kurangnya kepemilikan aplikasi untuk para devs. SCRUM berfungsi jika devs tidak diperlakukan sebagai kode monyet. Tanda pertama dari proses yang salah adalah ketika para devs bukan yang mengevaluasi berapa banyak waktu yang akan dilakukan.
• jam bodoh lagi. Jika bagian dari tim telah mulai mengerjakan beberapa hal dan "berada di zona" ketika harian terjadi, itu akan mengganggu. Waktu yang baik untuk melakukan itu setiap hari adalah ketika tidak ada orang yang bekerja (setelah makan siang misalnya, atau sebelum memulai beberapa diskusi untuk makan siang).

Pengaturan waktu adalah pembunuh bagi banyak orang. Pemrogram suka kode terlambat, tidur larut dan masuk setelah pagi sibuk. Harus berada di kantor pada waktu yang tetap - terlalu dini bagi mereka. Dan sudah terlambat untuk orang lain yang mungkin datang lebih awal dan sudah mulai bekerja.

Flow adalah masalah lain. Seorang programmer yang mengalir dengan beberapa fitur akan bekerja hingga larut malam, pulang dan kembali diisi ulang dan siap untuk melanjutkan. Harus duduk melalui pertemuan dengan sebagian besar masalah yang tidak berhubungan dapat mengalihkan perhatiannya.

Pengamatan saya terlalu sering pertemuan-pertemuan ini bagi para manajer untuk terlihat dan merasa seolah-olah mereka benar-benar melakukan sesuatu daripada berguna untuk tim dan proyek.

Misalnya, tim ditugaskan untuk melakukan serangkaian perbaikan bug pendek pada proyek yang berbeda. Mereka benar-benar tidak bekerja sebagai tim tetapi sebagai individu. Namun, karena kebijakan perusahaan / departemen mengamanatkannya, ketua tim / manajer tetap mengadakan rapat scrum harian. Semua yang dicapai adalah menghabiskan 15+ menit untuk pertemuan yang tidak berguna dan mengatasi 15-30 menit gangguan dan kurangnya produktivitas sebelum dan sesudah pertemuan.

Sekarang, saya telah melihat scrum dilakukan dengan baik dalam sebuah proyek yang memiliki tenggat waktu yang ketat dan membutuhkan banyak koordinasi antara orang-orang yang bekerja pada berbagai bagian. Dalam konteks itu, itu adalah sistem yang hebat. Tetapi, dalam konteks "Kami mengadakan rapat karena kami adalah toko scrum / gesit dan itulah yang kami kira harus dilakukan" benar-benar dapat menyedot.

Pastikan tidak ada yang memonopoli pertemuan.

Jika 4 dari pengembang mendapatkan omongan mereka keluar dari jalan dalam 5 menit, dan 10 menit berikutnya yang dihabiskan mendengarkan pemimpin tim merinci semua menakjubkan , mengagumkan perkembangan baru dia buat, yang kebanyakan tidak seperti biasa atau sebagai mengagumkan seperti yang dia pikirkan, orang akan cepat bosan.

Mundur sejenak dan pikirkan tim Anda:

• Apakah mereka bekerja secara efektif?
• Apakah tugas selesai tepat waktu?
• Apakah kodenya kuat dan ditulis dengan baik?
• Apakah tim memastikan tidak ada yang jatuh melalui celah?
• Apakah tim berkoordinasi sendiri sehingga mereka tidak menduplikasi pekerjaan atau menginjak kaki masing-masing?

Jika jawaban Anda untuk semua hal ini adalah "Ya", mungkin Anda harus mempertimbangkan mengapa Anda ingin memaksakan pekerjaan yang sibuk seperti rapat harian, bagan pembakaran, dan papan tugas di tim Anda. Nilai apa yang ditambahkannya? Apakah Anda ingin menghasilkan data birokrasi semata-mata untuk kesenangan Anda sendiri atau Anda mencoba membuat tim lebih produktif?

Apakah ada penurunan produktivitas sejak scrum harian berhenti, atau apakah semuanya berjalan sama seperti sebelumnya? Jika tidak ada yang berubah, mengapa melanjutkan pertemuan?

15 menit. Apakah itu 15 menit (ditambah waktu untuk mempersiapkannya) menyampaikan informasi yang cukup baru dan berguna antara anggota tim untuk meningkatkan produktivitas tim untuk hari mendatang dengan nilai lebih dari 15 menit? Jika tidak ada jumlah konten scrum yang berguna setiap hari, anggota tim mungkin berpikir bahwa mereka akan membuat kemajuan yang lebih jauh ke arah tujuan jika mereka keluar dari pertemuan ini secepatnya dan kembali bekerja.

Jika Anda hanya ingin memperbarui papan dan bagan sesering mungkin, letakkan salinan konsep di wiki.

Saya sarankan jika Anda mengadakan rapat Retrospektif untuk melihat "Apa yang berjalan dengan baik" dan "Apa yang tidak berjalan dengan baik" dan melihat apakah para pengembang membuat daftar pertemuan harian itu sendiri sebagai pemborosan waktu. Maka Anda perlu mengatur ulang sedikit.

Pengalaman pribadi saya:

• Tujuannya adalah untuk mengetahui apa yang kita lakukan hari ini dan di mana kita berada kemarin. Alih-alih berpegang pada agenda, itu masuk ke diskusi teknis blocker antara 2 orang dan 15 lainnya bosan. Identifikasi masalah tetapi diskusikan di luar
• Orang tidak masuk ke ruang rapat tepat waktu, dan ini menjadi siklus yang dilakukan oleh beberapa orang dengan sengaja. Jadi Scrum Master perlu berdiskusi dengan mereka di luar pertemuan untuk memastikan mereka memulai dan mengakhiri tepat waktu.
• Kami sudah memperbarui grafik burndown di luar pertemuan Scrum sehingga itu bukan tujuan utama dari stand-up harian.

Perlawanan datang ketika: 1) Mereka digunakan untuk memaksa orang bergegas masuk jam 9 pagi. Ini stres ekstra ketika kereta terlambat. 2) Kepemimpinan scrum yang buruk. Pemimpin harus memberi tahu orang-orang untuk mengambil barang-barang di luar jalur daripada meminta orang berdiri mendengarkan sesuatu yang tidak mempengaruhi mereka. 3) konten yang tidak berharga. Sekali lagi ini adalah masalah kepemimpinan scrum. Ini seharusnya menjadi forum untuk mengatasi kemacetan, masalah lintasan dan kolaborasi potensial. Apa yang sebenarnya terjadi adalah semua orang hanya mengatakan apa yang mereka harapkan untuk bekerja pada hari itu yang tidak berguna atau menarik bagi orang lain. 4) Berdiri. Saya tidak akan berdiri untuk berdiri. Logika di balik berdiri adalah bahwa hal itu mendorong orang untuk bersikap singkat. Orang sebenarnya hanya mengoceh tanpa peduli.

Saya sudah berhasil dan menjadi bagian dari tim scrum berkali-kali. Alasan utama mengapa pengembang tidak menyukai scrum adalah:

• Karena mereka dijalankan oleh master scrum yang sangat buruk, jika itu berubah menjadi 45 menit master scrum Anda perlu ditingkatkan untuk mengendalikan scrum.
• Alasan terbesar dan paling Jujur mengapa mereka tidak menyukainya, adalah karena sangat sulit untuk bersembunyi dalam etika kerja yang buruk, yaitu, lebih terang-terangan, itu menunjukkan orang-orang malas. Beberapa devs yang pernah bekerja sama dengan saya mengejutkan, mereka membutuhkan waktu berhari-hari melakukan tugas yang seharusnya 30 menit. Seorang PM yang baik harus menghilangkan hambatan bagi para dev yang berarti mereka harus dapat membajak tugas-tugas mereka dalam sprint. Devs tidak menyukainya karena mereka harus berdiri setiap hari dan menunjukkan kemajuan yang telah mereka buat. Ini menyebabkan kecemasan ketika mereka tidak dapat menunjukkan kemajuan karena alasan apa pun. Jika itu karena masalah yang valid master scrum yang baik harus segera menyelesaikan masalah itu.

Masalah muncul ketika master scrum tidak memiliki otoritas, keterampilan atau kemampuan untuk menyelesaikan masalah pemblokiran. Bahkan saya telah melihat beberapa masalah penguburan dengan harapan mereka akan pergi. Ini bencana.

Terus terang, dalam 99% rapat scrum harian yang saya ikuti, hampir semua diskusi / pertanyaan / jawaban dapat diatasi dengan beberapa email.

Jujur saya pikir kita perlu menunjukkan alasan yang lebih valid untuk TIDAK mengadakan pertemuan. Bangun lingkungan di mana ketika saatnya untuk memasukkan semua orang ke ruangan sendiri, itu lebih baik menjadi alasan yang baik dan diorganisir untuk memaksimalkan efisiensi waktu.

Saya benci rapat secara umum, dan lebih suka menggunakan konferensi video, telepon, email, apa pun yang memungkinkan saya untuk masuk atau tetap bekerja tanpa harus bangun dan mengganggu aliran produktivitas saya.

Saya pribadi berpikir jika Anda memiliki lebih dari empat pertemuan dalam periode 8 jam maka proyek tidak dikelola dengan baik.

Ada banyak faktor yang berkontribusi terhadap ketegangan dalam rapat. Pertimbangkan ini sebagai beberapa alasan penting mengapa rapat mungkin membuat Anda lebih mahal daripada nilainya:

• Fokus - perangkat lunak versus rapat
• Manajemen - manajer perlu pengukuran
• Kepribadian - Introvert vs Ekstrovert
• Waktu - menyela, Waktu Pembuat dan Manajer
• Sasaran, Prioritas

Masing-masing faktor tersebut dijelaskan di bawah ini,

Fokus - Saya menikmati pengembangan perangkat lunak, dan itu termasuk memikirkan tantangan (masalah), menciptakan solusi, membangun perangkat lunak, dan rapat mengalihkan perhatian dari fokus pada tugas-tugas yang membangun perangkat lunak. Ada keadaan yang disebut " Aliran " di mana pengembang terbenam dalam tantangan (masalah), telah membangun model mental dari solusi, dan memiliki fokus penuh untuk membangun solusi. Pengembang dapat bekerja hingga tengah malam, pergi hanya untuk makan dan tidur, kemudian kembali ke keadaan dekat dengan tempat mereka pergi.

Pengembang perlu menghindari gangguan, dan banyak yang menemukan bahwa ada keuntungan untuk kode hingga larut malam (mereka menghindari kebisingan, panggilan telepon, kantor yang sibuk, dan rekan non-pengembang mengganggu pekerjaan mereka). Dan ketika Anda telah bekerja sampai jam 10, 11, atau 12 siang, tidak masuk akal untuk datang kerja nanti (10, 11, siang?). Apakah masuk akal untuk mengharapkan pengembang bekerja dari jam 9 pagi sampai tengah malam?

Rapat scrum (dan apa saja) mengalihkan perhatian pengembang dari tujuan utamanya, yaitu membangun perangkat lunak.

Manajemen - Manajer perlu mengukur untuk menjadi sukses, maka kebutuhan untuk jadwal, pengiriman, jadwal, prioritas, dan pertemuan untuk mengukur dan melaporkan kemajuan, dan untuk mengekspos dependensi, keterlambatan, dan bidang risiko. Tantangan dengan Scrum adalah bahwa seorang manajer membutuhkan hal-hal ini, tetapi pengembang perlu fokus. Rapat melayani manajer, dan menyediakan cara bagi manajer untuk memperoleh, mengukur, dan melacak status dan kemajuan, tetapi rapat jarang memberikan manfaat bagi pengembang. Pertimbangkan bahwa manajer memberikan nilai lebih ketika mereka menangani gangguan, menghilangkan hambatan, dan memungkinkan pengembang untuk fokus membangun perangkat lunak.

Ada solusi untuk kebutuhan rapat. Seorang manajer dapat mengunjungi pengembang mereka, meminta laporan status, mengadopsi protokol ketika gangguan kurang mengganggu, atau mengadopsi kebijakan bahwa pengembang untuk memberi tahu mereka tentang kemajuan ketika pengembang itu interupsi. Lihat pembahasan waktu mengapa ini penting.

Kepribadian - Pertimbangkan bahwa beberapa orang introvert dan yang lain ekstrovert. Ekstrovert menikmati interaksi sosial, dan diisi ulang oleh mereka. Manajer biasanya ekstrovert (karena ekstrovert biasanya lebih baik dengan interaksi sosial), meskipun introvert dapat berhasil sebagai manajer. Introvert dapat menikmati dan bahkan unggul dalam interaksi sosial, tetapi diisi ulang oleh kesendirian. Pengembang sering introvert, dan berhasil bekerja sendiri (atau dalam tim kecil) karena mereka tidak "memerlukan" interaksi sosial; mereka bisa senang bekerja sendiri pada masalah (meskipun ekstrovert juga bisa menjadi pengembang). Rapat scrum harian bisa menjadi pertemuan sosial, bagus untuk ekstrovert, tetapi tidak begitu baik untuk introvert.

Waktu - Pengembang tidak dapat menulis kode saat mereka sedang rapat. Mereka juga tidak dapat memikirkan masalah-masalah sulit (kecuali mereka melakukan brainstorming), sementara terganggu oleh pertemuan. Pengembang membutuhkan blok besar waktu tanpa gangguan untuk fokus membangun perangkat lunak. Rapat adalah gangguan yang mengalihkan upaya mereka. Ketika Anda telah tenggelam dalam memecahkan masalah selama berjam-jam, hampir selesai, dan seseorang mengatakan "waktu untuk scrum", Anda terganggu, dan mungkin kehilangan jam kerja sambil "memindahkan gigi". Atau Anda tetap bekerja sampai jam 11:00 malam, meninggalkan pekerjaan, pulang ke rumah, tidur dengan masalah, bangun, kembali bekerja siap untuk menyelesaikan masalah, dan kemudian disela setelah satu jam mengerjakan suatu masalah, karena itu adalah "waktunya untuk scrum".

Paul Graham memiliki artikel yang sangat bagus tentang Waktu Pembuat vs. Waktu Manajer, yang menjelaskan masalah ini jauh lebih baik daripada saya. Cukup untuk mengatakan bahwa gangguan rapat, baik yang direncanakan atau tidak direncanakan dapat memutus arus, dan memaksa pengembang dari waktu Maker ke waktu Manajer. Percayalah, Anda ingin pengembang pada waktu Maker.

Sasaran, Prioritas - Pengembang dan manajer memiliki tujuan dan prioritas yang berbeda. Manajer memiliki tanggung jawab untuk melacak jadwal, meminimalkan biaya, memastikan bahwa laporan mereka bertanggung jawab, dan bahwa mereka melakukan. Pengembang memiliki tujuan untuk membangun perangkat lunak yang mengatasi tantangan / masalah. Tujuan-tujuan ini tidak bertentangan, tetapi mekanisme komunikasi yang menciptakan ketegangan. Rapat melayani kebutuhan manajer dan mengoptimalkan waktu manajer, tetapi mereka bertentangan dengan kebutuhan pengembang. Rapat scrum membuang aturan pertemuan pertama, "punya agenda", dan cenderung berkeliaran lebih banyak. Dan rapat digunakan untuk mengoptimalkan komunikasi (untuk manajer), tetapi biayanya memakan waktu pengembang (gangguan, kehilangan aliran, dll).

Apa tujuannya? Untuk membangun perangkat lunak yang memenuhi kebutuhan, dengan cepat dan dengan kualitas, sementara kendala adalah (kualitas, waktu, biaya, proses). Scrum dan metodologi gesit lainnya mengenali kendala proses, dan mencoba untuk meminimalkan faktor itu, dan telah berhasil karena mereka meminimalkan kendala itu. Tetapi menambahkan rapat memang menghabiskan waktu, dan interupsi itu membuat pengembang lebih mahal daripada durasi rapat.

Ubah rapat untuk memastikannya memberikan manfaat:

1. Jadwalkan pada waktu yang menawarkan kenyamanan. Mengapa tidak bisa 30 menit setelah pekerjaan dimulai sehingga semua orang dapat meninjau email dan mengatur pemikiran mereka untuk pertemuan tersebut. Brevity membutuhkan perencanaan. Yang tidak siap bisa mengoceh selamanya.
2. Identifikasi masalah yang bisa dihindari seandainya masalah dikomunikasikan selama pertemuan. Setiap orang perlu memahami apa gunanya.
3. Lakukan apa pun untuk menjaga input semua orang agar tetap minimum. Itu bukan tempat untuk perdebatan. Dorong orang untuk menjadwalkan pertemuan pribadi di luar pertemuan harian yang berfokus pada topik yang perlu dibahas. Aturan: hanya satu orang yang berbicara sekaligus.

Semua pengeluh perlu memastikan bahwa mereka tidak berkontribusi terhadap masalah. Jika Anda dapat mencapai tujuan Anda untuk scrum harian tanpa harus melakukannya dengan cara yang tidak terlalu menyakitkan, kami ingin mendengarnya.