Bagaimana cara saya menangani tim scrum kontraproduktif?

Backstory:
Saya telah bekerja sebagai bagian dari tim ini selama tiga tahun terakhir dan saat ini kami memiliki tiga Scrum Master yang berbeda yang semuanya menjalankan berbagai hal secara berbeda.

Karena perubahan dalam Scrum Masters ini dan cara mereka menjalankan pertunjukan, itu membuat tim saya mati rasa dengan gagasan Scrum karena prinsip-prinsipnya belum ditegakkan secara konsisten dan salah satu dari Scrum Masters adalah orang yang tidak percaya pada gesit. pengembangan dan hanya menyimpan acara dan artefak sebagai pemula untuk mematuhi keputusan perusahaan.

Sekarang anggota tim saya jengkel dan bosan ketika kami melakukan acara Scrum dan satu orang khususnya sangat verbal tentang hal ini.

Sekarang:
Dua bulan yang lalu perusahaan menunjuk saya Scrum Master dari tim saya karena dedikasi saya untuk bekerja gesit dan prinsip-prinsipnya.

Saya sangat menderita di bawah tekanan atmosfer dari keengganan anggota tim saya untuk melakukan Scrum.

Seperti yang disebutkan mereka kesal dengan seluruh proses yang membuatnya sangat sulit bagi saya karena mereka tidak terlibat dalam percakapan yang diperlukan untuk membuat Perencanaan, Retrospektif, dan Scrum Harian efektif.

Bagi mereka, Perencanaan hanyalah buang-buang waktu, karena kami hanya memindahkan kelebihan ke Sprint baru dan tidak menyelesaikan pekerjaan, jadi mengapa repot-repot.

Selama Retrospektif saya hanya bisa merasakan bahwa mereka ingin mengatakan "Berhenti melakukan Scrum". Satu orang melakukannya, tetapi yang lain diam dan saya harus berurusan dengan ini setiap waktu.

Scrum harian lagi-lagi hanya buang-buang waktu karena tidak ada dari mereka yang mau berbicara dan merencanakan hari itu. Mereka hanya menyatakan "Saya mengerjakan tugas X kemarin dan akan mengerjakannya lagi hari ini." Dan sebagian besar waktu mereka hanya bercanda sampai saya mendapatkan lebih keras.

Saya sangat besar dalam hal bagaimana mereka menghabiskan waktu selama acara-acara ini. Tapi saya sekarat di dalam karena saya memiliki hasrat untuk ini dan mereka tidak peduli lagi.

Hari ini orang yang selalu menentang saya mengatakan kepada saya untuk berhenti mengatakan, "Mereka mengatakan ini adalah apa yang mereka berkomitmen untuk Sprint ini" karena, dalam kata-katanya, "Kami tidak pernah menyelesaikan Sprint. Kami hanya bergerak dalam tugas dan menerima yang baru di Sprint berikutnya untuk mengisi kuota. Kami melakukan KanBan dalam kenyataan. Jadi berhentilah mengatakan itu. "

Saya mengerti mengapa dia mengatakan ini, tetapi dia tampaknya tidak menyadari bahwa ini adalah karena dia dan semua orang di tim tidak peduli. Mereka hanya bekerja daripada berurusan dengan hambatan. Mereka mengeluh tentang rintangan, tetapi tidak melakukan apa-apa tentang mereka. Dan ketika saya mencoba untuk membantu mereka hanya mengabaikannya.

Mereka dulu peduli, tetapi selama dua tahun terakhir kesediaan mereka telah menurun ke titik terendah.

Bagaimana saya bisa membuat mereka melihat bahwa bercanda dan membuang-buang waktu selama pertemuan ini menghabiskan banyak uang bagi perusahaan?

Anda mungkin pernah mendengar banyak statistik tentang proyek perangkat lunak yang gagal dan sampai pada kesimpulan bahwa kegagalan itu tidak bersifat teknis. Masalah teknologi dapat diselesaikan melalui ratusan solusi teknis, tetapi menyelesaikan masalah di atmosfer tempat kerja Anda dengan menggunakan Scrum tidak akan berhasil.

Saran saya di sini adalah untuk sepenuhnya berhenti melihat ini sebagai masalah teknis. Ini bukan tentang Scrum, ini bukan tentang standup harian, sprint, retrospektif atau hal lain seperti itu. Anda perlu menghubungi tim Anda dan menemukan cara kerja yang efektif yang memuaskan mereka serta Anda dan atasan Anda.

Jika mereka menganggap harian adalah ide yang buruk, Anda seharusnya tidak memberi tahu mereka untuk melakukan harian dan mencoba memasukkan alasan Anda ke dalamnya. Pikirkan sendiri apa yang ditawarkan harian kepada Anda. Periksa dengan tim Anda apakah mereka juga menghargai keunggulan itu. Cari tahu mengapa mereka tidak berbagi pemahaman Anda - seperti dalam memahami sudut pandang mereka, bukan dalam meyakinkan mereka tentang apa pun. Kemudian periksa apakah harian benar-benar membantu tim Anda, atau apakah Anda dapat mencapai lebih banyak dengan mekanisme lain. Hal yang lucu tentang para master Scrum adalah mereka adalah pelayan bagi tim mereka - Anda dapat melayani mereka sebaik-baiknya dengan menghapuskan Scrum sekaligus.

Singkatnya, berhentilah berfokus pada Scrum dan sebaliknya kembali ke dasar-dasar kelincahan. Anda mungkin ingin memulai dari awal dengan manifesto tangkas : Nilai individu dan interaksi atas proses dan alat.

Dalam pengalaman saya, tim yang kecewa perlu memulai dengan memiliki retrospektif yang efektif. Itu sebabnya menurut saya retrospektif adalah satu-satunya bagian wajib dari proses lincah. Segala sesuatu yang lain dapat berubah melalui retrospektif.

Dalam retrospektif yang efektif, Anda tidak hanya mengeluh tentang masalah Anda, Anda memilih setidaknya satu dari masalah itu dan mengidentifikasi solusi yang mungkin untuk itu, kemudian mencoba solusi itu untuk iterasi berikutnya. Pada retrospektif berikutnya, Anda berbicara tentang bagaimana solusi itu bekerja atau tidak berfungsi, dan membuat penyesuaian lebih lanjut jika perlu, atau memilih masalah lain untuk dikerjakan.

Ketika anggota tim melihat mereka memiliki kekuatan untuk melakukan perubahan aktual dalam proses mereka, mereka akan menjadi lebih bersedia untuk terlibat.

Proses retrospektif adalah mengapa jika Anda mengunjungi semua tim di sebuah perusahaan yang gesit dengan baik, mereka semua melakukannya dengan agak berbeda. Kami memiliki beberapa tim yang melakukan Kanban, beberapa yang melakukan XP, beberapa yang hanya melakukan standup pada hari Senin, Rabu, Jumat.

Jika tim Anda tidak menyukai cara Anda mengatasi mabuk, lakukan brainstorming beberapa pendekatan berbeda. Saya telah memenangkan pengembang yang sangat enggan hanya dengan mendengarkan secara retrospektif dan mencoba solusi secara konsisten.

Ok jadi mari kita mulai dengan kasar - sebagian besar masalah ada pada Anda - Anda dengar, tetapi Anda tidak mendengarkan. Tim Anda memberi tahu Anda dengan jelas apa masalahnya. Anda harus mengatasinya alih-alih menyalahkan tim Anda.

Perencanaan

Bagi mereka, Perencanaan hanyalah buang-buang waktu, karena kami hanya memindahkan kelebihan ke Sprint baru dan tidak menyelesaikan pekerjaan, jadi mengapa repot-repot.

Persis. Jika Anda secara konsisten gagal mengalokasikan jumlah waktu yang tepat untuk tugas-tugas, dan mereka secara konsisten diremehkan, itu memiliki efek yang sangat negatif:

• Pengembang merasa mereka terus-menerus di bawah tekanan.
• "Aku tidak bisa menyelesaikan apa pun tepat waktu".
• Karena prosesnya tidak berhasil, mereka berhak melihatnya sebagai pemborosan waktu.

Solusi : Perbaiki estimasi Anda menggunakan kombinasi:

• Story Points (sebagai kombinasi Waktu dan Risiko).
• Jangan izinkan tugas menjadi sprint> 55 SP
• Estimasi Komparatif
• Penjadwalan Berbasis Bukti

Sebagai dasar untuk ini, Anda benar-benar perlu melacak waktu yang sebenarnya diperlukan untuk menyelesaikan tugas sebelumnya, ini termasuk pengujian, dokumentasi penulisan, tes menulis, pelatihan pengguna akhir, upaya integrasi, penyebaran. dll.

Setelah Anda memiliki total waktu untuk tugas yang diberikan, Anda dapat mendasarkan waktu yang diharapkan pada tugas-tugas sebelumnya.

Tanyakan kepada setiap anggota apakah tugas yang diberikan kepada mereka terasa lebih rumit atau lebih mudah daripada pemilihan tugas sebelumnya, sesuaikan jumlah tugas yang dialokasikan berdasarkan itu.

Jika Anda belum pernah menggunakan SP sebelumnya, saran saya adalah memulainya dengan 1 jam kerja jujur ​​sejujurnya kepada dewa kerja = 5SP sebagai pedoman. Perlu diingat bahwa dalam lingkungan pengembangan yang biasa, Anda mungkin akan mendapatkan 6 dari itu per hari, jadi maks 30SP / hari . Jangan pernah mengizinkan tugas yang membutuhkan lebih dari 2 hari untuk naik ke papan tulis. Idealnya, dalam pengalaman saya, Anda harus memiliki 2 tugas per hari.

Jika Anda tidak melakukan Perencanaan dengan benar, sisa kegiatan Scrum Anda akan terlihat seperti buang-buang waktu (termasuk Perencanaan).

Retrospektif

Selama Retrospektif saya hanya bisa merasakan bahwa mereka ingin mengatakan "Berhenti melakukan Scrum". Satu orang melakukannya, tetapi yang lain diam dan saya harus berurusan dengan ini setiap waktu.

Mengingatkan saya pada Daily beatings will continue until morale improves!dan dua pekerjaan sebelumnya. Jika Anda tidak menghilangkan hambatan, maka mereka benar bahwa ini adalah buang-buang waktu.

Sekali lagi, dengarkan apa yang orang katakan. Jika keluhan yang diajukan selama retrospektif tidak ditangani, mengapa repot-repot melakukannya?

Begitu:

• Pertimbangkan teknik Enam Topi Berpikir untuk meningkatkan komunikasi.
• Kurangi waktu yang dihabiskan untuk Retrospektif, maksimum 30 menit.
• Pastikan bahwa keluhan yang diajukan selama Retrospektif ditangani sebelum yang berikutnya.

SCRUM harian

Scrum harian lagi-lagi hanya buang-buang waktu karena tidak ada dari mereka yang mau berbicara dan merencanakan hari itu. Mereka hanya menyatakan "Saya mengerjakan tugas X kemarin dan akan mengerjakannya lagi hari ini." Dan sebagian besar waktu mereka hanya bercanda sampai saya mendapatkan lebih keras.

Sepertinya Anda memiliki dua masalah di sini: Rapat SCRUM terlalu lama, dan perencanaan dan pembuatan tugas Anda menyebalkan.

Keduanya dapat membuat suara seperti rapat scrum adalah buang-buang waktu.

Untuk panjang SCRUM:

• Coba maksimal 15 menit.
• Coba semua orang berdiri.
• Rumus tetap:
  • Apa yang kamu lakukan kemarin?
  • Apa yang kamu rencanakan hari ini.
  • Apa yang harus diketahui oleh anggota tim Anda (bukan Anda!) Tentang tugas itu, bagaimana hal itu akan memengaruhi mereka.
• Jangan repot-repot dengan rintangan jika Anda tidak akan mengatasinya.

Ini adalah bukti kedua bahwa perencanaan Anda merusak situasi Anda - jika Anda tidak memiliki laporan khusus, itu berarti biasanya tugas itu terlalu besar dan yang dapat Anda katakan hanyalah: Saya sedang mengerjakannya.

• Hancurkan tugas menjadi poin-poin.
• Pastikan tugas cukup kecil untuk memakan waktu kurang dari sehari. Idealnya, IMO, tugas harus berlangsung ~ 3 jam dan setara dengan sekitar 13 SP, sehingga Anda dapat melakukan 2 per hari di sebagian besar kondisi.

Berurusan dengan tim

Hari ini orang yang selalu menentang saya mengatakan kepada saya untuk berhenti mengatakan, "Mereka mengatakan ini adalah apa yang mereka berkomitmen untuk Sprint ini" karena, dalam kata-katanya, "Kami tidak pernah menyelesaikan Sprint. Kami hanya bergerak dalam tugas dan menerima yang baru di Sprint berikutnya untuk mengisi kuota. Kami melakukan KanBan dalam kenyataan. Jadi berhentilah mengatakan itu. "

Dia benar. Anda salah. Anda melakukan SCRUM bastardisasi dan / atau variasi pada Kanban. Bukan kesalahan mereka sama sekali.

Saya mengerti mengapa dia mengatakan ini, tetapi dia tampaknya tidak menyadari bahwa ini adalah karena dia dan semua orang di tim tidak peduli.

Saya pikir Anda tidak mengerti sama sekali. Mereka mungkin peduli kurang dari sebelumnya, namun menyalahkan mereka tidak hanya tidak akan memperbaiki apa pun, itu mungkin hanya membuat situasi lebih buruk. Jika itu adalah dasar batu, mereka mungkin benar-benar mulai menggali.

Mereka hanya bekerja daripada berurusan dengan hambatan.

Dan di sini saya pikir melakukan pekerjaan adalah tugas mereka. Aku ingin tahu siapa yang seharusnya berurusan dengan rintangan .... oh benar. Seorang Master Scrum. Ini Anda pekerjaan. Mereka memberi tahu Anda apa yang salah. Anda memperbaikinya. Bukan sebaliknya.

Ini mungkin mengapa Anda memiliki begitu banyak masalah di Retrospektif.

Bagaimana saya bisa membuat mereka melihat bahwa bercanda dan menyentak selama pertemuan ini menghabiskan banyak uang bagi perusahaan?

Hentikan pertemuan yang tidak berguna dan mereka malah akan bercanda di watercooler. Juga lihat paragraf tentang pemukulan meningkatkan moral. Jika mereka menggunakan humor sebagai mekanisme pertahanan, Anda memiliki beberapa masalah serius, Pak!

Ikuti lelucon - seperti bekerja dengan tim Anda, bukan menentangnya. (Siapa fuuuuuuck peduli dengan uang perusahaan? Apakah Anda pemegang saham sekarang?)

Untuk meringkas

Perencanaan buruk Anda membuat bagian-bagian lain dari SCRUM gagal, dan semua orang yang berpartisipasi menderita. Mereka melihat bahwa tidak ada yang berubah, tidak ada yang diatasi, dan keluhan mereka tidak terdengar.

Perbaiki perencanaan Anda, dan Anda akan meningkatkan alur dan moral.

Apakah pekerjaan Anda menghilangkan rintangan dan tim Anda akan berkembang lebih cepat. Tanyakan kepada mereka apa yang menurut mereka harus Anda lakukan untuk membantu mereka.

Yang terpenting: Dengarkan orang-orang Anda. Mereka sudah memberi tahu Anda (dan saya) apa masalahnya.

Semoga berhasil!

Salah satu prinsip tangkas utama adalah kembali, dan memperbaiki apa pun yang salah. Itu tidak hanya mencakup perbaikan kode dan perbaikan bug, tetapi juga memperbaiki proses pengembangan.

Jadi, mengapa Anda tidak melakukan pertemuan dengan tim Anda, dan lihat bagaimana Anda dapat meningkatkan proses pengembangan? Jika itu berarti, tidak ada rapat scrum atau standup, maka jadilah itu.

Anda juga melanggar salah satu prinsip dalam manifesto tangkas : "Individu dan interaksi atas proses dan alat".

Di sisi lain, jika tim Anda berpikir bahwa pengembangan berulang itu buruk, maka mungkin Anda salah melakukannya. Tidak masalah jika Anda tidak menyelesaikan semua yang Anda rencanakan untuk satu iterasi - Anda selalu dapat memindahkan hal-hal ke iterasi berikutnya. Itu juga mengapa Anda menandai hal-hal sebagai "harus mengandung", "baik untuk dimiliki", dll. Selama Anda memberikan fungsionalitas baru, Anda melakukannya dengan baik.

Hanya kata-kata kasar kecil: di perusahaan saya sebelumnya dan saat ini kami lakukan dan masih melakukan pertemuan standup. Dari pengalaman saya, mereka sangat membuang waktu, karena setiap kali mereka berubah menjadi pertemuan laporan status 30+ menit, dan bagi saya memberikan sedikit atau tidak ada informasi. Orang-orang membicarakan masalah mereka, yang sejujurnya saya tidak peduli.
Di perusahaan saya sebelumnya, mereka cerdas, mengenali masalah ini dengan standup, dan menghentikan mereka segera setelah orang mulai mengeluh.

Jika Anda suka melihat video yang sangat bagus tentang scrum, lihat " Robert C. Martin - The Land that Scrum Forgot ".

Saat saya prioritaskan, saya akan melihat tugas-tugas yang terus terbawa. Tidak memenuhi target sangat melemahkan semangat. Apakah Anda terlalu banyak berkomitmen? Apakah ada fatlog yang harus diurai? Apakah ada kemacetan di luar kendali Anda? Apakah Anda memiliki definisi yang jelas tentang "selesai"? Apakah persyaratannya jelas? Apakah jam per pengembang masuk akal (yaitu memperhitungkan admin akun, standup, perencanaan, retrospektif, istirahat keyboard, pekerjaan non-proyek).

Selanjutnya, selokan apa pun yang tidak berfungsi. Proses tanpa nilai hanyalah pencuri waktu. Standup dapat menghabiskan banyak waktu jika tidak fokus dan tidak memberikan nilai kepada tim. Jam mungkin lebih baik dihabiskan di tempat lain. Mungkin juga mempertimbangkan memecah tim jika terlalu besar.

Cobalah untuk memahami apa yang mendemotivasi tim. Milikilah retrospektif dan yang lebih penting, tindak lanjuti hasilnya. Sama pentingnya untuk merayakan keberhasilan dan juga melihat kegagalan.

Akhirnya, Anda mungkin ingin menilai pendekatan master scrum yang telah ada sebelumnya yang mungkin telah merusak merek. Saya telah bekerja di bawah master scrum beracun sebelum di mana setiap masalah yang muncul ditambahkan ke beban kerja Anda apakah Anda mengetahuinya atau tidak. Hasil akhir: masalah diabaikan dan semua orang mengerjakan area kecil mereka sendiri dengan kerja tim yang sangat sedikit.

Membuat tim Anda untuk menutup sprint Anda secara efektif (seperti setidaknya menutup 80% cerita) sprint over sprint adalah menurut saya satu-satunya hal terpenting yang dapat Anda lakukan. Jika tim Anda hilang secara konsisten, maka itu indikasi yang jelas bahwa Anda perlu menyesuaikan perkiraan Anda.

Tim harus menerima hal ini, meskipun mungkin sangat sulit untuk membuat pengembang lebih realistis tentang perkiraan - saya bekerja pada tim yang tidak menutup sprint selama setahun (secara konsisten menutup kurang dari 50% dari sprint) , selalu di bawah perkiraan dan dalam setiap perencanaan / retrospektif saya adalah seorang penyendiri yang mengatakan bahwa perkiraan Anda payah, Anda terlalu percaya diri, berhenti membuat alasan untuk apa yang mencegah Anda membuat perkiraan dan alih-alih menyesuaikan perkiraan untuk mencerminkan kenyataan ( mungkin lebih diplomatis dari itu tetapi itu adalah sentimen dasar) - Ketika Anda berada di posisi itu, saya akan sepenuhnya setuju dengan curmudgeon di tim Anda yang mengatakan prosesnya adalah buang-buang waktu karena Anda sebenarnya melakukan KonBon, terlepas dari apa yang Anda sebut itu. Pada titik tertentu, pendapatnya divalidasi oleh keadaan. Saya t'

Pada titik tertentu Anda harus mengatur ulang hal-hal, Anda harus membuat tim untuk secara drastis mengkompensasi estimasi mereka hanya untuk membuat sistem bergerak. Begitu sebuah tim mulai menutup cerita secara konsisten, mereka harus menyadari bahwa proses Agile pada dasarnya masuk akal dan gagal mewujudkannya dengan cara tertentu berbahaya bagi produktivitas Anda. Tetapi selama 'komitmen' dan 'tujuan sprint' tidak ditanggapi dengan serius, yang terjadi ketika mereka tidak tercapai secara konsisten, maka semuanya adalah palsu dan menjadi menguras produktivitas tim.

Membuat orang untuk membeli pada sprint yang sangat berbeda (dalam hal perkiraan, perencanaan, komitmen dll) sulit, pada tim saya akhirnya berhasil karena dua faktor. Salah satunya hanya mengumpulkan data dari JIRA dan mengatakan "tidak ada alasan untuk ini, jumlahnya jauh, mereka selalu dalam satu arah, kita perlu memperbaikinya, saya tidak ingin alasan di retro, saya ingin jumlah yang dijumlahkan "- dan yang lainnya adalah tekanan dari pimpinan yang lebih tinggi yang pada akhirnya saya jelaskan kepada mereka seperti ..." Maksud dari proses ini adalah membuat garis waktu pengembangan kita dapat diprediksi. Jika kita menyelesaikan jumlah pekerjaan yang konstan setiap sprint itu bagus, terlepas dari itu, dewan kami perlu secara akurat mencerminkan apa yang kami lakukan. Manajemen lebih sadar akan kesuksesan kami dibandingkan komitmen dibandingkan dengan output kami yang sebenarnya, demi diri Anda sendiri, buatlah proyeksi sesuai dengan output sehingga tampaknya Anda menyelesaikan pekerjaan daripada menghabiskan setengah dari setiap sprint tidak melakukan apapun. Semakin banyak orang yang dihapus berasal dari saat ini, semakin mereka hanya melihat Anda gagal, alasan yang Anda buat di retro bahkan bukan sesuatu di ruang lingkup mereka, mereka hanya melihat Anda gagal. "

Akhirnya tim kami mendapat traksi dan segalanya mulai berjalan lebih lancar dan lebih rendah dan lihatlah, kami bahkan mulai memiliki hasil yang lebih tinggi begitu proses benar-benar mulai bekerja. Jadi, lakukan apa pun yang diperlukan untuk memulai menutup sprint dengan tingkat keberhasilan yang relatif tinggi. Jika Anda tidak melakukan itu, curmudgeon di tim Anda akan terus memiliki resistensi terhadap Scrum divalidasi oleh hasil dan pada akhirnya akan benar bahwa proses Anda sebenarnya hanya palsu dan buang-buang waktu semua orang.

Sebagai Scrum Master Anda melatih dan membimbing tim untuk menjadi lebih produktif. Kerangka kerja Scrum adalah alat yang ampuh untuk sampai ke sana, tetapi kerangka kerja Scrum benar-benar tidak boleh menjadi tujuan dengan sendirinya - jika tidak, Anda melakukan Cargo Cult .

Sepertinya Anda telah melakukan Cargo Cult selama 3 tahun sekarang dan orang-orang menyadari bahwa itu adalah metodologi manajemen proyek yang mengerikan. Berita baiknya adalah Anda memiliki orang-orang pintar , mereka melakukannya dengan benar. Sayangnya, beberapa orang di perusahaan Anda menyebutnya Scrum, tetapi sekali lagi Anda memiliki orang-orang pintar , mereka bahkan memberi tahu Anda apa yang dilakukan tim tidak disebut Scrum.

Perencanaan hanyalah buang-buang waktu, karena kami hanya memindahkan kelebihan ke Sprint baru dan tidak menyelesaikan pekerjaan, jadi mengapa repot-repot.

Persis. Mengapa mengganggu? Anda perlu menemukan jawaban, atau lebih tepatnya Anda perlu mengubah perencanaan dan sprint itu sendiri sehingga ada titik untuk perencanaan. Entah itu, atau berhenti membuang waktu semua orang dengan Perencanaan Sprint yang tidak berguna. Anda mungkin ingin meminta perusahaan untuk mengirimi Anda pelatihan Scrum Master, karena menjalankan Perencanaan Sprint yang hebat bukanlah hal sepele.

Selama Retrospektif [...] yang lain diam dan saya harus menghadapinya setiap saat.

Jika Anda berurusan dengan masalah yang sama setiap Retrospektif, orang bahkan tidak repot-repot (lagi?) Untuk berbicara selama Retrospektif, itu hanya buang-buang waktu. Kecuali jika Anda atau tim entah bagaimana dapat mengatasi masalah yang diangkat dalam Retrospektif, rapat hanyalah sebuah demoralisasi tim. Masalah yang diangkat dalam Retrospektif harus diatasi, dan harus ada kemajuan oleh Retrospektif berikutnya.

Scrum harian lagi-lagi hanya buang-buang waktu karena tidak ada dari mereka yang mau berbicara dan merencanakan hari itu. Mereka hanya menyatakan "Saya mengerjakan tugas X kemarin dan akan mengerjakannya lagi hari ini."

Memang, mengapa repot-repot membuang waktu semua orang jika mereka hanya mengerjakan tugas yang sama beberapa hari? Mereka benar sekali, bahwa Standup Harian memang tidak ada gunanya. Standup memfasilitasi kolaborasi erat pada banyak tugas yang masing-masing dapat diselesaikan dalam setengah hari atau kurang. Jika tugas Anda tidak dapat dipecah seperti itu (karena Perencanaan Sprint rusak, atau karena tugas Anda sebenarnya tidak cocok dengan Scrum), tidak ada banyak gunanya mengadakan rapat Standup Harian 5 menit (ini adalah tidak lebih dari 5 menit, kan?).

"Kami tidak pernah menyelesaikan Sprint. Kami hanya bergerak dalam tugas dan mengambil yang baru di Sprint berikutnya untuk mengisi kuota. Kami melakukan KanBan pada kenyataannya. Jadi berhentilah mengatakan itu."

Saya mengerti mengapa dia mengatakan ini, tetapi dia tampaknya tidak menyadari bahwa ini adalah karena dia dan semua orang di tim tidak peduli.

Tidak, Anda sama sekali tidak mengerti mengapa dia mengatakan ini . Anda mendapatkan akar penyebab dari hambatan - yang harus Anda selesaikan - salah. Mereka tidak peduli karena praktik manajemen proyek tim itu payah. Peduli melakukan Cargo Cult dan melakukan Cargo Cult lebih keras tidak menghentikannya menjadi Cargo Cult, salah satu metodologi manajemen proyek terburuk yang ada (dalam pertahanan Anda: juga yang paling banyak digunakan).

Apa yang dapat Anda lakukan tentang ini?

1. Dengarkan keprihatinan mereka. Sekali lagi, Anda diberkati karena Anda memiliki orang-orang pintar .

2. Bantu mereka mengatasi rintangan.

Dan itu saja, sungguh. Anda perlu bereksperimen dengan cara mengubah Perencanaan Sprint, Scrum Harian, dan Retrospektif untuk menjadikannya berharga bagi tim - bahkan jika Anda ingin melepaskan label Scrum, Anda masih memiliki 3 pertemuan dengan frekuensi yang sama dan tujuan yang serupa di setiap lainnya metodologi manajemen proyek di luar sana. Adapun bagaimana Anda akan bereksperimen (frekuensi, konten, yang menjadi tuan rumah pertemuan, waktu, durasi, dll), itu sangat mudah: Tanyakan pada tim. Jangan memaksakan ide-ide Anda pada mereka, jika Anda membiarkan mereka memaksakan ide-ide mereka kepada Anda (dengan asumsi mereka dapat menyetujui beberapa).

Jika Anda takut kehilangan kendali, tetapkan beberapa batasan sebelumnya, misalnya:

• Label rapat tetap sama.
• Pertemuan masih berlangsung dan frekuensi pertemuan tidak dapat berubah lebih dari faktor 2.
• Anda sedang bereksperimen, jadi perubahan apa pun hanya berlangsung selama 2 sprint, setelah itu Anda kembali ke pola lama (paling baik berikan waktu dalam beberapa minggu untuk menghindari ambiguitas ketika mereka ingin menggandakan durasi sprint).

Saya pikir semua orang mengutip kalimat yang sama dari Agile Manifesto . Saya akan melakukan hal yang sama: "Individu dan interaksi atas proses dan alat."

Jika Anda sebagai master SCRUM ingin menggunakan SCRUM untuk melakukan pekerjaan itu, Anda harus mendekatinya sebagai satu individu yang berinteraksi dengan yang lain. Mulai curah pendapat bagaimana membuat proses lebih baik. Mungkin Anda bisa meyakinkan mereka untuk menyukai SCRUM. Mungkin mereka dapat meyakinkan Anda untuk menggunakan proses yang berbeda. Ayo cari tahu!

Sepertinya tim sudah mengenali bahwa sistem saat ini tidak melakukan pekerjaan. Dapatkah Anda mendorong mereka untuk percaya bahwa itu dapat melakukan pekerjaan? Anda menyebutkan beberapa contoh. Jika Anda mengisi terlalu banyak Sprint sehingga selalu bocor ... berhenti. Ini tim SCRUM Anda. Bantu mereka berhenti berlebihan. Dorong kembali manajemen untuk mendapatkan ruang bernapas. Gunakan SCRUM untuk apa manfaatnya. Gunakan itu untuk menyajikan data kepada manajemen bahwa mereka mendorong cukup keras sehingga mereka kehilangan nilai dari proses mereka. Jika manajemen menginginkan SCRUM sebagai suatu proses, minta mereka untuk membantu membangun ruang dan energi yang Anda butuhkan untuk memperbaikinya. Sebagai master SCRUM, tugas Anda adalah menyelesaikan masalah sehingga tim bisa produktif.

Pendekatan lain yang bermanfaat adalah menelurkan proses baru di dalam yang lama. Terus jalankan SCRUM dengan cara yang tidak berguna sama, tapi lepaskan sebagian kecil dari jadwal dan katakan "di bagian ini dari jadwal kami, kami akan mencari cara untuk menggunakan alat dengan benar." Jangan berlebihan di sana. Gunakan metrik Anda. Fokus pada semua rapat Anda di sana. Hanya bagian yang tersisa dari proyek "SCRUM" Anda sebagai perisai untuk membuat manajemen senang sementara Anda dan tim Anda "[mengungkap] cara yang lebih baik untuk mengembangkan perangkat lunak dengan melakukannya dan membantu orang lain melakukannya." Seiring waktu, Anda akan ingin menempatkan lebih banyak tugas Anda yang berharga di dalam ember ini, dan ember lama itu perlahan-lahan akan mati. Segera, Anda memiliki lingkungan pengembangan perangkat lunak yang dinamis dan tidak ada yang lebih bijak.

Atau campur dan cocokkan. Saya bekerja pada sebuah program yang anti-scrum. Klien ingin dapat menambahkan tugas baru kapan saja selama proses berlangsung dan meminta kami segera menindaklanjutinya. (Ini sebenarnya permintaan yang waras: pekerjaan mereka sangat fluktuatif dan mereka sering membutuhkan dukungan cepat ... itulah yang dibayar untuk kami). Tentu saja, kami harus mencari cara untuk menangani masalah "mengapa X tidak dilakukan saat Anda berjanji dalam sprint". Solusi kami sebenarnya adalah membangun proses dua langkah. Tugas jangka panjang dimasukkan ke dalam SCRUM untuk penentuan prioritas yang tepat. Tugas jangka pendek dimasukkan dalam proses homebrewed yang berfokus pada interaksi yang erat antara klien dan pengembang. Dipahami bahwa klien dipersilakan untuk mendorong kami menggunakan proses jangka pendek ini, tetapi mereka memahami bahwa hal itu mendorong Sprint ' timeline, dan mereka dilarang menambahkan permintaan tanpa secara bersamaan mendengar dan mengatasi masalah penjadwalan yang disebabkannya. Hasil? Itu berhasil. Sebagian besar tugas dimasukkan ke dalam proses SCRUM, seperti seharusnya, dan keadaan darurat berinteraksi secara mulus dengan mereka. Sikapnya adalah "Jika Anda ingin menjadi pelanggan, antri untuk cerita SCRUM. Jika Anda ingin menjadi mitra, jangan ragu untuk turun dan bekerja bersama kami pada tingkat sehari-hari dan membuat produk ini berfungsi ! "

Saya mengatakan ini karena saya benar-benar tahu. Anda memiliki masalah dalam manajemen tingkat atas dengan penjadwalan berlebih, tidak dapat menetapkan prioritas, dan keinginan untuk menambahkan lebih banyak item tetapi tidak mendorong tanggal rilis kembali.

Dulu saya mengatakan bahwa tidak ada metodologi yang dapat berfungsi seperti ini, tetapi sekarang saya telah melihat Kanban, saya mengatakan itu bisa, tetapi hanya karena Kanban tidak perlu peduli. Ini terus berfungsi saat terlalu berkomitmen. Ini tidak akan membawa hasil lebih cepat tetapi cadangan dalam antrian tidak diizinkan untuk diletakkan pada individu mana pun sehingga masalah manajemen ada pada manajemen. Laporan umpan balik menunjukkan kelebihan, yang benar.

Karena perubahan dalam Scrum Masters ini dan cara mereka menjalankan pertunjukan

Oh well, ini mungkin masalahmu. Master Scrum tidak ada di sana untuk menjalankan pertunjukan, dia bukan pemimpin proyek. Dia ada di sana untuk memastikan semua pemangku kepentingan berkomunikasi dan operasinya transparan.

Saya bertanya-tanya dari mana tim berasal. Mungkinkah mereka lebih atau kurang otonom sebelum Scrum (termasuk master Scrum yang tak terhindarkan) dijatuhkan kepada mereka? Mengapa Scrum diperkenalkan pada awalnya? Apa yang seharusnya dipecahkan?

Scrum seharusnya memberikan panduan dan tim Anda menjelaskan bahwa mereka tidak mengalaminya dengan cara apa pun. Mereka tidak peduli dengan bimbingan, mereka menganggap itu buang-buang waktu yang tidak pantas. Tampaknya setidaknya satu pembuat keputusan berpikir mereka perlu dibimbing pula. Siapa? Mengapa? Apakah mereka ada benarnya?

Ini adalah masalah yang tidak terbatas pada perangkat lunak.

Dalam lingkungan kerja apa pun, akan ada orang yang berbeda dengan kepribadian dan kemampuan yang berbeda. Bahkan jika Scrum adalah metode yang sempurna, masih akan ada orang yang menentangnya karena kepribadian dan kemampuan mereka.

Pengembang menangani tugas-tugas sulit dengan cara yang rasional. Untuk dapat melakukan ini, setiap pengembang akan memiliki cara untuk menangani hal-hal seperti itu yang mungkin muncul sebagai keengganan terhadap hal-hal seperti Scrum. Jika semua pengembang dilatih dari awal dengan cara yang persis sama maka mungkin akan jauh lebih mudah untuk menggunakan satu pola, tetapi sebaliknya adaptasi pada sisi pengembang atau sisi manajemen diperlukan.

Selain itu, pemikir independen (pengembang dan spesialis lain) sering tidak suka diberitahu bagaimana melakukan sesuatu karena itu adalah pekerjaan mereka dan mudah untuk bentrokan pendapat terjadi. Scrum bisa tampak seperti ritual tak berguna bagi seorang pemikir logis yang biasanya akan menganalisis dan bertindak sesuai dengan setiap masalah yang dihadapi.

Di bawah ini tampaknya menunjukkan di mana masalahnya tetapi tidak apa itu. Pasti ada lebih dari ini. Saya hanya dapat berasumsi (karena pengalaman) bahwa pengembang mencoba tetapi dicegah. Saya telah melihatnya berkali-kali di mana pengembang ingin memperbaiki sesuatu tetapi sesuatu yang sistematis (manajemen, kebijakan perusahaan, dll.) Membuatnya hampir mustahil sehingga mereka menyerah. Apakah mereka benar-benar tidak peduli atau tidak hanya peduli melakukan sesuatu yang mereka yakini tidak akan membantu (mungkin karena pengalaman).

Saya mengerti mengapa dia mengatakan ini, tetapi dia tampaknya tidak menyadari bahwa ini adalah karena dia dan semua orang di tim tidak peduli. Mereka hanya bekerja daripada berurusan dengan hambatan. Mereka mengeluh tentang rintangan, tetapi tidak melakukan apa-apa tentang mereka. Dan ketika saya mencoba untuk membantu mereka hanya mengabaikannya.

Mereka dulu peduli, tetapi selama dua tahun terakhir kesediaan mereka telah menurun ke titik terendah.

Bagaimana saya bisa membuat mereka melihat bahwa bercanda dan menyentak selama pertemuan ini menghabiskan banyak uang bagi perusahaan?

Jika ada sesuatu yang dipaksakan kepada orang lain, terserah orang yang memaksa metode untuk meyakinkan mereka tentang manfaatnya. Meskipun, saya tidak benar-benar percaya memaksa orang untuk melakukan sesuatu, saya sarankan seperti dalam situasi apa pun, dengarkan semua orang dan kembangkan metode yang cocok untuk lingkungan saat ini.

Scrum bukannya tanpa kelemahan. Saya bisa berbicara untuk diri saya sendiri, tetapi saya pikir pengembang membencinya karena alasan yang baik . Ini adalah pendapat jujur ​​saya bahwa itu tidak boleh dicoba .

Untuk memahami alasannya, bacalah apa yang harus diketahui oleh setiap ahli scrum tentang scrum . Ini tidak ditulis oleh saya, namun semua yang ada mewakili pengalaman saya, yang saya dapat simpulkan sebagai teror belaka .

Dalam kasus saya, saya terutama menderita di bawah poin 5. Pada dasarnya, scrum memperlakukan saya sebagai anak dan pecundang. Sekarang, saya adalah co-developer yang pintar membantu kolega saya ... tidak heran apa yang saya inginkan!

Saya memiliki bos baru (non-scrum) sekarang, yang hanya berjalan-jalan dan berbicara kepada orang-orang, dan saya sangat berterima kasih untuk itu! Salah satu alasan mengapa hal ini berhasil adalah kami juga memiliki ruang obrolan (kami menggunakan hal terpenting) untuk komunikasi antar pengembang. Jika ada yang punya agenda, kami bawa ke sana. Rapat hanya untuk diskusi pengembang ad-hoc, bukan untuk memaksakan tenggat waktu harian artifisial pada diri sendiri.

Anda mendapatkan banyak jawaban bagus. Berikut beberapa poin lagi yang mungkin bisa membantu:

Mengubah Metodologi Sulit

Ini adalah tantangan besar di ruang kerja, karena Anda bekerja di bawah inersia "ini adalah bagaimana kami melakukan sesuatu", dan melawan tekanan tenggat waktu dan kebutuhan bisnis.

Anda cukup benar untuk menyimpulkan bahwa tim Anda perlu menghabiskan lebih banyak waktu untuk perencanaan, tidak kurang ; bahwa perencanaan adalah sesuatu yang saat ini tidak Anda sukai, dan perlu ditingkatkan. Masalahnya adalah, Anda tidak sampai di sana hanya dengan mendikte aturan baru. Aturan baru adalah beban baru sebelum menjadi bantuan besar. Dan jika mereka tidak segera memberikan nilai yang besar , Anda akan mendapatkan penghindaran daripada kerja sama.

Saya sangat merekomendasikan Roy Osherove tentang topik ini. Dia punya ringkasan singkat tentang bagaimana merencanakan dan melakukan perubahan di perusahaan Anda , dan dia masuk ke topik yang jauh lebih mendalam di video ini .

Pengamatan dasar Osherove adalah bahwa semua tantangan berikut harus dipenuhi:

Motivasi Pribadi: Mengapa seseorang harus peduli untuk berperilaku dengan cara tertentu?
Kemampuan Pribadi: Dapatkah mereka benar-benar melakukannya?
Motivasi Sosial: Apakah ada tekanan teman sebaya untuk perilaku ini?
Kemampuan Sosial: Apakah orang-orang di sekitar saya mendukung perilaku saya dan membantu saya ketika diperlukan?
Motivasi Struktural: Apakah ada penghargaan \ hukuman untuk perilaku baik \ buruk?
Kemampuan Struktural: Apakah lingkungan fisik mendukung perilaku ini?

Anda Perlu Belajar Untuk Memecah Tugas

Tim Anda merasa bahwa "Saya mengerjakan tugas X kemarin dan akan mengerjakannya lagi hari ini," dan mereka tampaknya benar, dalam arti bahwa tugas-tugas terus didorong kembali seminggu.

Apa yang benar-benar membantu di sini adalah mempelajari cara memecah tugas menjadi komponen-komponen kecil. Apa yang Anda cari adalah jawaban untuk pertanyaan "OK, Anda mengerjakan tugas X, tapi khusus apa di tugas X yang Anda kerjakan hari ini ?"

Beberapa jawaban mungkin:

• Saya sedang mempelajari kelas kode warisan ini.
• Saya memperbaiki bug, yang gejalanya (GEJALA).
  • Jika ini adalah bug yang sedang berlangsung yang memerlukan waktu: "Hari ini yang akan saya coba adalah ... (RENCANA)"
• Saya perlu mengubah antarmuka ini.
• Saya sedang menulis tes.
• Saya mengintegrasikan kode yang belum diuji.

... dan seterusnya, dan sebagainya. Mampu mengamati apa yang sebenarnya bisa Anda lakukan dalam sehari, atau dalam seminggu, adalah salah satu manfaat agile yang luar biasa. Tapi itu berarti Anda benar-benar perlu melihat resolusi setiap hari, bukan Tugas X yang monolitik yang akan Siap Kapanpun Siap.

Selesai vs. Terkirim

Satu masalah umum (dengan Agile, dan perencanaan tempat kerja secara umum) adalah bahwa tenggat waktu cenderung berasal dari manajemen, bukan dari pengembang. Tenggat waktu itu mungkin dipisahkan dari pekerjaan aktual yang harus dilakukan - dan khususnya, itu mungkin menginginkan hal-hal disampaikan secepat mungkin.

Masalahnya adalah, "disampaikan SECEPATNYA" adalah proses yang sangat kacau. Ini mendorong sudut pemotongan; coding "cepat dan kotor"; mengabaikan pedoman; tidak membersihkan setelah dirimu sendiri. Ini mendorong mentalitas "mencobanya, lihat apakah itu berhasil. Jika ya, berikan. Jika tidak, coba yang lain" - dan, dengan ungkapan seperti itu, Anda dapat melihat mengapa tidak ada yang bisa memprediksi berapa lama waktu yang dibutuhkan.

Sedangkan jika Anda sedang bekerja metodis, jika Anda ketat tentang perencanaan dan pengujian dan sebagainya, maka Anda telah menyiapkan sekelompok rambu-rambu dan jaring pengaman. Mungkin butuh waktu lebih lama - Anda mencurahkan banyak waktu untuk hal-hal yang tidak mempercepat pengiriman segera, dan, Anda mungkin belum pandai alur kerja seperti ini - tetapi itu akan jauh lebih tidak stabil.

Jadi satu hal yang perlu Anda tanyakan pada diri sendiri adalah: Apakah para pengembang menetapkan tujuan sprint, sesuai dengan kebutuhan dan kebutuhan yang sebenarnya mereka lihat? Atau manajemen menetapkan tenggat waktu, membuat pengembang mencoba dan menempatkan komitmen mereka ke dalam jadwal sprint?

Jika pengembang tidak diberi waktu untuk merencanakan sesuatu, atau bekerja sesuai dengan rencana yang andal, maka tidak heran mereka tidak dapat membuat perkiraan yang bermanfaat. :)

Ini mungkin pendapat yang tidak populer, tetapi Anda mungkin tidak bisa berbuat apa-apa.

Saya bisa membayangkan bahwa selama bertahun-tahun keberadaan tim dan aliran pemimpin, orang-orang yang benar-benar tidak puas dengan tim, pergi. Apa yang Anda miliki adalah sisa-sisa orang yang mungkin mengeluh, tetapi tidak tertarik untuk benar-benar berupaya memperbaiki situasi. Mereka hanya ingin menghabiskan 8 jam kode peretasan, tidak terganggu oleh siapa pun dan hanya pulang pada akhir hari. Apa yang Anda miliki di sini tampaknya menjadi masalah motivasi yang serius. Dan bukan tugas scrum master untuk menyelesaikan masalah itu. Ini masalah siapa pun yang membayar orang-orang itu.

Jika ini benar-benar masalahnya, maka hanya opsi nyata yang menyingkirkan tim saat ini dan memulai dari awal. Mungkin meninggalkan satu atau dua orang yang menurut Anda terbaik dalam tim dan memecat atau memindahkan sisanya ke tim yang berbeda. Anda setidaknya harus mendiskusikan kemungkinan ini dengan atasan Anda.