Apa yang Anda lihat salah saat memperkenalkan SCRUM?

Apa satu titik kegagalan yang ditemui ketika perusahaan Anda memutuskan untuk mengganti proses saat ini dengan SCRUM?

Bisakah Anda memberi saya beberapa contoh hal-hal yang salah ketika perusahaan mencoba memperkenalkan SCRUM? Saya ingin mendengar anekdot Anda, sesuatu yang Anda alami sendiri, kegagalan besar yang Anda lihat datang tetapi tidak dapat dicegah.

Saya mendengar banyak kekhawatiran tentang dokumentasi yang hilang tentang keputusan tentang detail implementasi, dan tentang ukuran cerita dan tingkat detail cerita.

Masalah terbesar adalah kesalahpahaman. Kegagalan umum adalah:

• Hanya tim yang melakukan Scrum tetapi bagian lain dari perusahaan (termasuk penjualan, manajemen, SDM) masih berpikir dengan cara lama. Contoh:

  Interaksi terus menerus dengan pelanggan dan keterlibatan pelanggan sangat penting.

  SDM harus memahami bahwa kinerja tim lebih penting daripada kinerja individu. KPI harus berubah.

  Definisi fitur adalah proses yang berkelanjutan. Definisi proyek akan berkembang selama pengembangan oleh umpan balik pelanggan. Karena tenggat waktu proyek itu, anggaran yang diperlukan atau rangkaian fitur hasil dapat berubah (setelah disetujui oleh pemangku kepentingan).

  Perubahan adalah bagian dari proses.

  Estimasi adalah proses berkelanjutan yang tidak dapat Anda katakan di awal proyek bahwa Anda akan selesai dengan semua fitur (banyak dari mereka tidak diketahui di awal) dalam waktu 5 bulan.

  Tim diberdayakan untuk membuat keputusan. Tim membuat komitmen untuk sejumlah fitur yang disampaikan selama sprint berikutnya. Ini tidak bisa diminta atau diperintahkan.

  Sprint adalah zona aman bagi tim. Setelah tim berkomitmen untuk beberapa cerita pengguna yang ditetapkan, komitmen tidak dapat dimodifikasi di luar tim.

  Bagian dari struktur organisasi lama tidak masuk akal ketika pindah ke Scrum. Scrum mendefinisikan tiga peran: Master Scrum, Pemilik produk, tim. Ada peran lain tetapi ketiganya biasanya cukup untuk mengirimkan aplikasi. Yang tidak masuk akal adalah memiliki master Scrum, ketua tim, pemilik produk dan satu atau lebih manajer proyek. Manajer proyek dan pemimpin tim adalah peran yang berlebihan di Scrum.

• Guy ditugaskan peran master Scrum tidak melakukan master Scrum. Scrum master memecahkan hambatan. Apa pun yang mengganggu tim adalah halangan yang harus diselesaikan secepatnya. Kegagalan yang paling umum adalah menetapkan peran ini untuk pengembang tanpa pengalaman sebelumnya dengan Scrum. Peran ini menggantikan sebagian manajer proyek umum tetapi master Scrum tanpa kekuasaan atas tim dan master Scrum tidak menuntut fitur apa pun untuk diimplementasikan. Scrum master menjaga tim bahkan terhadap pemilik Produk dengan persyaratan yang tidak dapat direalisasi.

• Orang yang ditugaskan Peran pemilik produk tidak melakukan Pemilik produk. Pemilik produk memiliki tanggung jawab keuangan untuk produk tersebut. Ini sangat spesifik dan peran kunci kesuksesan. Peran tersebut memiliki kesamaan dengan analitik, manajer proyek, dan manajer produk. Pemilik produk mengumpulkan dan memelihara persyaratan (biasanya dalam bentuk cerita pengguna). Tanggung jawabnya adalah memberikan informasi kepada tim dan menentukan prioritas cerita pengguna. Dia harus berada di lokasi dengan tim karena kerja sama antara PO dan tim terus berlanjut.
• Mengubah nama proses menjadi Scrum tetapi meninggalkan sebagian besar proses seperti sebelumnya. Skenario yang paling umum adalah bahwa Anda akan berubah dari air terjun ke Scrum dan perubahan yang paling signifikan adalah bahwa Anda tidak melakukan analisis dan dokumentasi lagi dan Anda mengatakan bahwa Anda Scrum.
• Persyaratan / cerita pengguna tidak ada definisi selesai - sangat umum. Jika Anda tidak memiliki definisi selesai (kriteria penerimaan) Anda tidak dapat membuat asumsi tentang kompleksitas cerita pengguna selama perencanaan sprint. Jika Anda tidak memilikinya selama sprint, Anda tidak dapat menandai cerita pengguna sebagai selesai karena Anda tidak dapat memvalidasinya.
• Kualitas dianggap sebagai opsional. Kualitas dalam Scrum adalah warga negara kelas satu. Kita dapat mengatakan bahwa setiap kriteria penerimaan harus dicakup oleh tes end-to-end otomatis. Setelah Anda mulai mengurangi kualitas dan menambahkan fitur yang belum diuji, Anda kehilangan kendali atas produk karena fitur yang dianggap selesai dapat berhenti bekerja kapan saja karena regresi.
• Hasil dari sprint harus merupakan peningkatan yang dapat dikirim (= berfungsi dan diuji) ke produk.

Edit:

Saya menambahkan catatan penting. Saat menggunakan pendekatan lincah, poin utama adalah memberikan jumlah nilai bisnis tertinggi kepada pelanggan secepat mungkin. Tetapi pelanggan (diwakili oleh Pemilik Produk) menjelaskan apa nilai bisnisnya. Jadi umumnya tidak benar bahwa Anda tidak memiliki analisis atau dokumentasi saat menggunakan Scrum. Jika pelanggan meminta analisis atau dokumentasi dan menandainya sebagai nilai bisnis (misalnya karena proyek berskala besar atau jangka panjang yang harus ditingkatkan dalam beberapa tahun mendatang) Anda akan membuatnya juga. Pendekatan yang paling mendasar adalah memasukkan analisis dan dokumentasi dalam kriteria penerimaan untuk cerita pengguna. Analisis dalam kasus seperti ini didokumentasikan komunikasi dengan pemilik produk dalam beberapa cara standar.

Masalah terbesar yang saya perhatikan dalam lebih dari 10 tahun xp dan scrum, adalah ketika tim yang belum cukup "gesit", memutuskan untuk "fleksibel tentang gesit" dan mulai menyesuaikannya, menjatuhkan bagian-bagian tertentu, dll, tanpa pemahaman yang jelas tentang apa yang masing-masing bagian lakukan dan mengapa itu ada di sana.

Saya telah melihat tim lebih sukses dengan scrum ketika mereka melakukan sesuatu berdasarkan buku pada awalnya, daripada tim yang mengubah apa yang mereka "belum" dapatkan.

Saat itulah Anda mendapatkan hal-hal seperti "sprint pertama, kami akan melakukan semua persyaratan. Sprint kedua semua desain, dll, dll, sprint terakhir semua pengujian". Juga dikenal sebagai air terjun. Atau bahkan hal-hal sederhana seperti "mari kita duduk, ada apa dengan bisnis standup ini?".

Ada hubungannya dengan Shuhari ( http://c2.com/cgi/wiki?ShuHaRi ).

Masalah terbesar selalu terjadi. Jika ada tim, atau individu kunci yang belum membeli (manajemen proyek, QA, pengembangan, dll) maka kegagalan hampir dapat dipastikan.

Masalah terkait lainnya sebenarnya membuat semua orang yang terlibat sadar akan apa sebenarnya scrum dan apa yang bukan.

Saya telah melihat lingkungan di mana manajemen proyek telah benar-benar menganggap ini sebagai tiket untuk datang langsung ke pengembang dengan perubahan dan mengharapkannya selesai besok, karena kami menggunakan proses baru yang hebat. Siapa pun yang berada dalam situasi ini atau dalam upaya gagal lainnya dalam mengimplementasikan Scrum dan memiliki rasa pahit di mulut mereka. Orang-orang ini kadang-kadang akan mencoba untuk menghilangkan proyek juga.

Masalah lain yang saya lihat adalah pertemuan berdiri. Anda akan selalu mendapatkan orang yang ingin duduk selama pertemuan berdiri .... "Saya mendapat punggung yang buruk" atau apa pun. Tampaknya selalu menjadi orang yang sama yang tidak tahu apa tujuannya di balik standup, dan tidak akan tutup mulut tentang politik atau apa yang dia lakukan akhir pekan itu. Rapat berdiri, saya temukan, adalah kunci komunikasi yang efektif. Penting untuk tidak membiarkan siapa pun meracuni pertemuan ini.

Mencoba melakukan semua analisis untuk kode yang kami kembangkan dalam sprint yang sama kami benar-benar mengkodekannya.

Kami pindah ke scrum beberapa saat yang lalu, dan terus terang manajemen yang menjalankannya memperlakukan setiap scrum sebagai proses air terjun 2 minggu. Ada semacam kepatuhan terhadap aturan scrum yang menjadi proses itu sendiri!

Ini adalah masalah yang saya temukan, semua metodologi lincah harus tentang fleksibilitas untuk bekerja secara efektif dengan cara yang bekerja untuk Anda. Bukan cara yang dilarang oleh proses. Sebagai contoh, kami memiliki scrum 2 minggu, dan sebuah tim mengatakan mereka merasa 2 minggu tidak cukup untuk melakukan pekerjaan dengan baik (tidak dengan downtime yang disebabkan oleh akhir scrum demo dan tinjauan persyaratan awal) sehingga mereka ingin pergi ke 3 minggu. Horor kejut! Manajemen menolak karena mereka telah memutuskan 2 minggu per scrum adalah ideal dan yang sekarang didokumentasikan dalam prosedur kualitas.

Scrum adalah yang paling lincah dari metode lincah, yang mungkin mengapa begitu populer - lebih mudah untuk dijual ke penjaga lama. Anda seharusnya menghapus hal-hal yang tidak Anda sukai, tetapi saya rasa itu tidak terjadi. Saran saya adalah untuk pergi dengan yang lebih fleksibel, berdasarkan aturan dan menambahkan aturan yang Anda butuhkan. Saya lebih suka Crystal karena ini.

Pada akhirnya, ingat saja manifesto tangkas yang setengah matang .

Masalah terbesar adalah bahwa klien Anda juga perlu menerima proses SCRUM dan menjadi gesit juga. Sebagian besar klien ingin mendengar ini di awal proyek:

• Berapa biayanya
• Akan terlihat seperti apa
• Kapan itu akan dilakukan

Kedengarannya masuk akal, tapi itu benar-benar tidak kompatibel dengan gesit. Anda perlu menjelaskan kepada klien Anda mengapa lincah baik baginya daripada air terjun.

Kami memiliki dua masalah besar pada kunjungan pertama saya di SCRUM:

1) Kami tidak benar-benar memiliki pemilik produk. Bos kami harus memainkan peran karena tidak ada orang yang seharusnya menjadi pemilik produk yang akan setuju untuk melakukannya. Jenis ini membuat kerutan karena dia tidak selalu benar-benar tahu jawabannya.

2) Kami buruk dalam akuntansi untuk komponen luar. Beberapa sprint pertama kami melibatkan pengujian otomatis penuh dan berjalan, dan kami berulang kali mengalami masalah mengotomatisasi simulator yang kami gunakan. Entah bagaimana kami tidak pernah menjadi lebih baik dalam menyadari bahwa ini akan terjadi.

Masalah utama yang saya hadapi dalam proyek saya adalah bahwa pengumpulan persyaratan terjadi setelah kami memperkirakan untuk sprint berikutnya. Kami memperkirakan berdasarkan kriteria penerimaan. Selama pertemuan persyaratan kami menemukan bahwa AC yang disetel jauh lebih besar sehingga tugas awal diperkirakan selama 8 jam sekarang benar-benar 24 jam! Jadi bisakah saya mengubah sprint backlog saya dan merevisi perkiraan dan mengurangi cerita saya? Tidak pak! Persyaratan cerdik bahwa Anda tidak dapat mengubah sprint backlog! Itulah yang dikatakan TL saya. Jadi seharusnya saya juga mengkode sesuai kriteria penerimaan asli yang saya perkirakan waktunya 8 jam! Allah! Tidak! Kamu tidak bisa melakukan itu! Itu tidak akan Agile, kan!