Apa yang Anda lihat salah saat memperkenalkan SCRUM?


20

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.

Jawaban:


14

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.


Saya suka fokus Anda pada interaksi dan komunikasi yang berkelanjutan . Beberapa kekhawatiran yang saya dengar adalah tentang hilangnya detail dalam cerita atau keputusan tidak berdokumen (bahkan tentang detail teknis) dan orang-orang ingin melindungi dari dampak keputusan yang salah (sudut pandang yang sangat defensif).
ngeri

1
Dokumentasi dan analisis diganti dengan interaksi dan komunikasi yang berkelanjutan. Anda tidak dapat menghapus satu dan tidak memperkenalkan yang kedua - itu justru akan menyebabkan detail yang hilang dan keputusan yang salah.
Ladislav Mrnka

The most basic approach is including analysis and documentation in acceptance criteria for user stories.Itu juga reaksi awal saya. Jika cerita memiliki kriteria penerimaan, itulah dokumentasi terbaik yang dapat Anda miliki. Tetapi jika tim memutuskan untuk membuat beberapa dokumentasi tambahan (bayangkan README di bagasi atau wiki dengan informasi yang berguna), maka saya tidak melihat masalah. Saya pikir orang takut bahwa SCRUM = tidak ada yang pernah ditulis.
ngeri

10

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 ).


9

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.


1
Katakan saja Bad Back Boy untuk berdiri sambil berbicara. Jika dia masih mengeluh, buat pengumuman bahwa ada donat di dapur.
JeffO

management has actually taken this as a ticket to come directly to developersItu contoh yang bagus dari situasi di mana proses SCRUM tidak dipahami, kan? Bahwa tim tidak dapat menerima cerita baru di tengah sprint.
ngeri

@cringe, ya ... tepatnya
aceinthehole

2
apakah itu benar-benar peduli adalah seseorang duduk bukan berdiri? Serius? Inilah sebabnya mengapa metode lincah tidak berfungsi - orang mematuhi lebih banyak aturan daripada yang mereka lakukan dalam metode lama yang sarat dengan proses!
gbjbaanb

1
@ gbjbaanb Akhirnya tidak masalah. Tahukah Anda apa yang menghalangi berdiri? Dan jika demikian, bagaimana Anda mencoba mencegahnya? Dan apakah itu berhasil untuk Anda?
Julio

6

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


Dan Anda perlu analisis karena ceritanya tanpa detail yang dibutuhkan? Atau karena kodenya tidak cukup jelas dan / atau tidak didokumentasikan dengan tes?
ngeri

1
Secara efektif, ceritanya sangat tinggi hingga pemilik produk (terminologi saya mengecewakan saya di sini) bahkan tidak tahu apa yang mereka inginkan.
Kevin D

Kami juga punya yang ini. Sejak itu kami telah melakukan sebagian besar bagian analisis sebelum sprint dimulai.
Carra

4

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 .


1
+1 untuk "scrum sebagai proses air terjun 2 minggu". Sayangnya itu tampaknya sangat umum
DPD

4

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.


1
Ini benar-benar tidak sesuai dengan metodologi pengembangan apa pun. Anda tidak pernah bisa mengatakan ini di awal. Anda harus melakukan analisis + beberapa bagian desain untuk dapat menentukan ini dengan akurat, tetapi desain analisis + dapat menghabiskan setengah dari waktu / anggaran proyek dan bahkan setelah itu Anda dapat gagal karena analisis bukanlah sesuatu yang sepenuhnya dipahami klien.
Ladislav Mrnka

Tapi itu salah satu masalah besar ketika Anda beralih ke SCRUM juga. Orang-orang sudah terbiasa dengan pertanyaan dan jawaban ini sehingga sebagian besar dari mereka tidak menyadari lagi bahwa sebagian besar jawabannya salah pada akhirnya. Jika pelanggan datang dengan visi kasar tentang produk, ia akan bertanya how much will it cost?dan mereka mengharapkan jawaban terinci saat itu. Balasan saya untuk masalah ini selalu "jika Anda tahu persis apa yang Anda inginkan pada akhirnya, Anda tidak perlu gesit. Hanya kode itu." Tapi kita semua tahu itu tidak akan terjadi. ;-)
ngeri

2

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.


+1 untuk "tidak memiliki pemilik produk". Kami mengalami masalah yang sama - terkadang itu tidak dapat dihindari, tetapi Anda harus mengakuinya dan merencanakannya.
sleske

2

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!


Bagaimana Anda memperbaikinya? Atau apakah itu alasan yang gagal seluruh pengenalan SCRUM? Saya pikir jika tim mendapatkan lebih banyak pengalaman perencanaan sprint dan perkiraan poker akan mengungkapkan persyaratan yang hilang sejak awal dan perkiraan akan menjadi lebih baik dan lebih baik.
ngeri

kami belum memperbaikinya. Dan kami masih menggunakan SCRUM. Satu-satunya perbedaan adalah bahwa jika kita mengatakan bahwa pekerjaan tambahan itu terlalu banyak dan TL setuju, kita dapat mengesampingkan cerita itu. Kami akhirnya menghabiskan lebih banyak waktu.
DPD
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.