Gambar diambil dari sumber ini .Pesaing atau mitra Anda telah menerapkan Scrum dan menunjukkan hasil yang baik, dan tentu saja Anda ingin mencapai yang sama. Saya punya berita buruk untuk Anda: jika digunakan secara tidak benar, Scrum bisa berbahaya.
Di sini, misalnya, adalah daftar situasi yang diidentifikasi secara empiris di mana Scrum dapat mengganggu pekerjaan Anda.
1. Apakah Anda berencana untuk menggabungkan peran dari manajemen proyek klasik dan Scrum
Scrum-team harus mencakup 3 peran: Pemilik Produk, Tim Pengembangan dan Scrum-Master. Dalam kerangka komposisi yang diusulkan, tim tetap "datar", yaitu, kami tidak memiliki subordinasi langsung antara peserta. Tim semacam itu diberdayakan untuk secara independen membuat semua keputusan mengenai produk yang sedang dikembangkan. Peran dalam Scrum menggambarkan dengan jelas siapa yang bertanggung jawab atas masalah apa.
Sekarang bayangkan Anda berencana untuk mengimplementasikan Scrum dalam sebuah tim dengan manajemen proyek klasik. Kemudian tim Scrum mulai bekerja dengan partisipasi Manajer Proyek. Apa yang terjadi dalam kasus ini? Faktanya, PM tidak punya apa-apa untuk menyibukkan diri dalam proyek semacam itu. Setiap bidang tanggung jawab yang kami transfer kepadanya menciptakan ketidakseimbangan dalam tim Scrum. Berikan PM anggaran? Luar biasa, yaitu, PM tidak mengatur nilai dan konten produk, tetapi jika ada masalah, dialah yang akan menerimanya di kepala. Akankah kami juga memberinya pekerjaan dengan nilai produk? Maka akan mungkin untuk menghapus Pemilik Produk. Tapi itu bukan Scrum.
Bagaimana peran dan tugas dalam suatu tim berubah dengan kedatangan Scrum2. Anda bekerja dengan persyaratan yang sangat jelas
Scrum diciptakan untuk mengembangkan produk dengan tingkat ketidakpastian yang tinggi. Ini bekerja dengan baik dalam kasus-kasus di mana kita perlu rilis sering untuk mendapatkan umpan balik dari pasar. Dalam situasi di mana kami memiliki persyaratan terperinci yang tidak memberikan ruang untuk kreativitas, atau ketika kami tidak membutuhkan umpan balik dari pelanggan / pengguna, Scrum hanya menghabiskan waktu tim untuk rapat yang tidak memiliki nilai besar untuk pengembangan produk.
Ketika semuanya sudah jelas, mengapa menyulitkannya?
3. Anda bekerja dengan proyek berdurasi pendek
Dasar Scrum adalah pendekatan empiris. Artinya adalah kita beralih ke pengalaman tim yang ada untuk dapat memprediksi keberhasilannya di masa depan. Jika kami mengerjakan proyek yang berlangsung 2 bulan, kami tidak akan punya waktu untuk mengumpulkan cukup pengalaman untuk menerapkannya untuk meningkatkan proses kerja.
4. Tim tidak memiliki keinginan untuk mengubah pendekatan untuk bekerja
Ini adalah salah satu batasan utama dalam mengimplementasikan Scrum. Menerapkan Scrum sebagai pedoman hampir selalu merupakan ide yang buruk, pertama-tama penting untuk menyampaikan nilai kepada tim, “jual ide”. Tetapi bahkan setelah itu, Anda tidak akan memiliki jaminan bahwa ide-ide Scrum akan dekat dengan semua pesertanya. Mereka yang belum menerima ide Scrum dan nilai gesit secara internal dapat mulai menghancurkan sistem dari dalam, “goyang perahu”.
Ada beberapa skenario yang mungkin. Pertama: Scrum tidak berakar sama sekali. Ini bisa terjadi jika sebagian besar tim menentang perubahan. Entah tim akan mengatur kerusuhan sejak awal, atau akan melakukan segalanya untuk membuat pendekatan baru terbukti tidak efektif.
Opsi kedua: satu atau lebih peserta tidak akan mau bekerja di sistem yang baru. Biasanya, situasi seperti ini mengakibatkan peserta yang “bermasalah” meninggalkan tim sendirian.
Ubah Kami sedang menunggu perubahan.
Gambar diambil dari sumber ini .5. Anda tidak siap untuk menggunakan semua praktik Scrum yang diperlukan
Untuk pendekatan ini, mereka bahkan menciptakan istilah khusus ScrumBut. Ini adalah saat kami bekerja di Scrum, tapi ... Kami tidak memiliki retrospektif. Tetapi kami memiliki pertemuan harian 2 kali seminggu. Tapi kami mengabaikan peran master Scrum. Dan banyak "tapian" serupa lainnya.
Kerangka kerja Scrum memberikan jawaban yang sederhana dan jelas untuk semua situasi ini. Ya, Anda dapat menambahkan praktik tambahan ke proses Scrum tim Anda (misalnya, praktik dari XP). Tapi tidak, Anda tidak bisa menolak elemen Scrum, karena ini bukan Scrum.
Semua peran, acara, dan artefak Scrum terikat erat bersama dan ditujukan untuk mencapai tujuan bersama - untuk secara efisien memasok pelanggan dengan produk bernilai maksimum. Penolakan terhadap setiap bagian Scrum menjauhkan kita dari tujuan ini.
6. Anda tidak siap merekrut karyawan untuk mengerjakan produk penuh waktu
Pernahkah Anda melihat grafik ketergantungan waktu kerja produktif pada jumlah proyek yang Anda kerjakan secara bersamaan? Jika tidak, maka tontonlah.
Diagram ini sendiri adalah argumen terbaik yang mendukung pelibatan karyawan dalam mengerjakan satu proyek pada satu waktu. Tetapi jika dia tidak meyakinkan Anda, kurangi dari waktu yang tersisa pada satu proyek ketika bekerja dengan beberapa proyek lain, waktu yang akan dihabiskan untuk pertemuan wajib (rapat harian, retro, perencanaan, sprint review). Seorang anggota tim akan memiliki terlalu sedikit waktu untuk mengerjakan tugas. Apakah kamu membutuhkannya?
Ada pengecualian untuk aturan ini. Sebagai contoh, Scrum-Master dapat bekerja dengan beberapa tim sekaligus. Tetapi untuk peserta lain perlu untuk memastikan keterlibatan maksimum hanya dalam proyek ini.
7. Anda tidak memiliki dukungan manajemen
Sama seperti kita ingin karyawan mengambil pendekatan baru untuk bekerja, kita juga membutuhkan dukungan manajemen. Penting untuk memahami bahwa pengenalan Scrum, terutama pada
tahap awal mungkin memerlukan investasi. Misalnya, mempekerjakan pelatih Agile atau Master Scrum profesional, melatih Pemilik Produk, melakukan pelatihan Scrum untuk karyawan, dan banyak lagi. Pemimpin harus siap untuk mendukung usaha baru secara finansial.
Tetapi ini bukan hal yang paling penting. Jauh lebih penting bahwa manajemen perusahaan berbagi nilai-nilai Scrum dan siap untuk mengubah budaya perusahaan. Misalnya, seorang pemimpin perlu dipersiapkan untuk fakta bahwa ia harus memberikan kekuatan baru sebagai bagian dari peran baru dalam tim. Tidak semua orang siap untuk ini, jadi "menjual ide" di tingkat ini juga mungkin diperlukan.
Daftar kriteria ini tidak berpura-pura lengkap, Anda dapat menambahkannya sendiri atau membagikan kasus Anda di komentar.