Adakah orang lain yang merasa Scrum tidak gesit?


41

Saya penggemar berat pengembangan tangkas dan menggunakan XP pada proyek yang sangat sukses beberapa tahun yang lalu. Saya menyukai segala sesuatu tentang itu, pendekatan pengembangan berulang, menulis kode di sekitar tes, pemrograman pasangan, memiliki pelanggan di situs untuk menjalankan sesuatu. Itu adalah lingkungan kerja yang sangat produktif dan saya tidak pernah merasa seperti berada di bawah tekanan.

Namun beberapa tempat terakhir saya pernah bekerja menggunakan / menggunakan Scrum. Saya tahu itu poster anak untuk pengembangan tangkas hari ini, tetapi saya tidak 100% yakin itu tangkas. Berikut adalah dua alasan utama mengapa itu tidak terasa gesit bagi saya.

Manajer Proyek Menyukainya

Manajer proyek, yang pada dasarnya terobsesi dengan garis waktu, semua tampaknya menyukai Scrum. Dalam pengalaman saya, mereka tampaknya menggunakan Sprint Backlog sebagai sarana untuk melacak persyaratan waktu dan mencatat berapa banyak waktu yang dihabiskan untuk tugas yang diberikan. Alih-alih menggunakan papan tulis, mereka semua menggunakan lembar excel, yang harus diisi oleh setiap pengembang secara religius.

Menurut pendapat saya ini terlalu banyak dokumentasi / pelacakan waktu untuk proses tangkas. Mengapa saya membuang waktu untuk memperkirakan berapa lama tugas akan membawa saya ketika saya bisa melanjutkan tugas itu sendiri. Atau juga mengapa saya membuang waktu untuk mendokumentasikan berapa lama suatu tugas ketika saya dapat melanjutkan ke tugas berikutnya.

Rapat Standup

Pertemuan standup di tempat saya sebelumnya bekerja adalah mimpi buruk. Setiap hari kami harus menjelaskan apa yang telah kami lakukan kemarin dan apa yang akan kami lakukan hari itu. Jika kita membahas "perkiraan" waktu kita untuk suatu tugas, manajer proyek akan menendang busuk, dan merujuk Sprint Backlog sebagai cara untuk menunjukkan ketidakmampuan Anda untuk tidak mematuhi timeline.

Sekarang saya mengerti perlunya komunikasi, tetapi tentu nada pertemuan sehari-hari harus ringan dan fokus pada berbagi pengetahuan. Saya tidak berpikir itu harus berubah menjadi tempat sandiwara gaya pekerjaan rumah Anda. Juga tentu titik lubang lincah adalah bahwa waktu berubah, mereka tidak boleh dibuat mati.

Kesimpulan

Gagasan tangkas adalah untuk membuat perangkat lunak lebih baik dengan membuat hidup para pengembang lebih mudah. Karena itu, menurut saya setiap proses tangkas yang digunakan oleh tim harus dipimpin oleh pengembang. Saya tidak berpikir memiliki manajer proyek menggunakan proses yang mereka sebut "lincah" untuk melacak proyek ada hubungannya dengan pengembangan tangkas.

Pikiran siapa pun?


6
Dalam scrum, tim harus dikelola sendiri. Tujuan manajer proyek adalah pada akhirnya menghilangkan peran mereka sehingga tim akan mengatur dan menghadiri pertemuan harian sendiri. Peran manajer proyek idealnya dihilangkan untuk menghadiri rapat retrospektif dan perencanaan dan menangani semua pekerjaan organisasi.
superM

7
Iya nih. Bahkan salah satu "bapak" lincah tidak setuju bahwa Scrum benar-benar gesit: youtube.com/watch?v=hG4LH6P8Syk
Euphoric

18
Jadi yang Anda katakan adalah bahwa Anda tidak melakukan Scrum, dan Anda menyadarinya, tetapi kemudian Anda terkejut bahwa Notscrum juga Notagile?
pdr

2
Saya tidak pernah menghabiskan lebih banyak waktu dalam rapat untuk membicarakan proses daripada setiap tim "gesit" yang pernah saya ikuti. Tapi saya masih menyukainya jauh lebih baik daripada alternatifnya.
Rob

11
Dalam pengalaman saya, Scrum pada dasarnya adalah upaya untuk membuat Air Terjun terlihat gesit dengan membaginya menjadi unit yang lebih kecil. Bahkan, sprint seharusnya lebih realistis disebut "kaskade".
Berislav Lopac

Jawaban:


25

Ada elemen-elemen tertentu dalam Scrum yang lebih rentan terhadap penyimpangan, tetapi jujur, apa yang Anda gambarkan adalah hasil dari mencoba membuat sebuah organisasi untuk mengadopsi Scrum tanpa mendidik semua pihak yang berkepentingan tentang apa itu semua tentang, bagaimana cara kerjanya dan mengapa itu berhasil. Anda perlu ikut serta di seluruh perusahaan untuk mendapatkan hasil.

Setiap transformasi tangkas akan mengekspos segala hal buruk yang terjadi di organisasi Anda, termasuk, tetapi tidak terbatas pada, micromanager, memaksa orang-orang dengan agenda mereka sendiri, pengembang yang kurang terlatih, silo komunikasi, dll. Jika tidak ada kemauan bersama untuk mengatasi masalah ini dan Anda hanya "melakukan standup" dan hanya "bekerja dalam sprint", implementasi Scrum akan jatuh datar di wajahnya.

Saya tidak bisa cukup menekankan hal ini: jika Anda ingin melakukan Scrum, Anda membutuhkan pelatih yang kompeten yang dapat menunjukkan jalannya kepada Anda. Ini tidak cukup untuk membaca Essential Scrum dan kemudian hanya melihat di mana itu membuat Anda ...


16
Dalam hal apa standup harian berbeda dari manajemen mikro?
Giorgio

10
Standup adalah untuk tim untuk mengatur waktu mereka sehingga mereka tidak saling menghalangi. Benar-benar tidak pantas untuk berbicara tentang perkiraan, waktu yang berlalu untuk tugas-tugas masa lalu dll - memang seorang manajer proyek (sebagai lawan dari scrum master) seharusnya tidak boleh hadir sama sekali.
Julia Hayward

10
@ Gegio: tergantung pada apa yang Anda maksud dengan manajemen mikro. Tujuan standup harian di SCRUM adalah untuk membuat semua orang mendapat informasi tentang apa yang dilakukan orang lain, bukan untuk memberikan kesempatan bagi manajer proyek untuk menghukum orang karena tidak memenuhi perkiraan. Bahkan, tidak ada manajer proyek di SCRUM, melacak dan menyesuaikan perkiraan adalah tugas tim, dan jika mereka tidak terpenuhi, pertanyaan untuk ditanyakan adalah "apa yang menyebabkannya dan bagaimana kita dapat menghindari atau mengizinkannya di masa depan? ", bukan" salah siapa itu dan seberapa burukkah kita dapat membuatnya merasa? "
Michael Borgwardt

3
@ErikReppen seperti halnya dengan apa pun, Anda memiliki sekelompok kecil orang yang datang dengan perbaikan yang layak dan kemudian Anda mendapatkan kelompok yang jauh lebih besar yang ingin memonetisasi dan umumnya menyesatkan sepenuhnya :-p Saya percaya pada Scrum, tapi saya benar-benar menjauhkan diri dari Aliansi Scrum dan bisnis sertifikasinya.
Stefan Billiet

8
@ jessehouwing: Ya, tetapi memaksakan pertemuan pada tim yang matang seperti naik ke seseorang yang bisa berjalan dengan sempurna dan memberi tahu mereka: lihat, Anda punya masalah, Anda tidak bisa berjalan, saya akan mengajarkan Anda untuk berjalan dengan benar. Orang-orang ini akan melihat Anda dan bertanya pada diri mereka sendiri: Hei, apa yang orang ini inginkan dari saya? Tentu saja saya bisa berjalan. Jadi, memaksakan pertemuan harian pada tim yang matang dan mengatur diri sendiri hanya mengganggu alur kerja mereka: itu hanya pemborosan. Keputusan semacam itu dapat dijelaskan oleh manajemen yang tidak kompeten atau oleh keinginan untuk mengamati / mengendalikan cara kerja tim.
Giorgio

20

Iya nih. Bahkan salah satu "bapak" lincah tidak setuju bahwa Scrum benar-benar lincah: youtube.com/watch?v=hG4LH6P8Syk - Euphoric

Saya pikir tautan ini dari salah satu komentar di atas benar-benar mengatakan semuanya. Ini layak ditonton, Paman Bob memberikan sejarah singkat tentang Scrum dan pada dasarnya mengatakan Scrum bukan proses pengembangan Agile karena Scrum telah berkembang dari waktu ke waktu menjadi proses manajemen . Alasan di balik ini tampaknya karena manajer proyek, dan bukan pengembang, yang mengambil kursus Scrum.


2
Ini (apa yang telah Anda tulis, bukan yang dikatakan paman bob) adalah non sequitur. Hanya karena sesuatu merupakan proses manajemen tidak menjadikannya inheren non-Agile.
Dave Hillier

9
Anda dapat memiliki kucing cokelat dan anjing cokelat, tetapi kucing cokelat tidak pernah bisa menjadi anjing cokelat. Itu bukan karena itu bukan cokelat, itu karena itu bukan seekor anjing. Demikian pula proses manajemen Agile tidak bisa menjadi proses pengembangan perangkat lunak Agile, bukan karena tidak tangkas tetapi karena itu bukan proses pengembangan perangkat lunak, yang sedang kita bicarakan.
winarama

1
Maka Anda mungkin ingin memperbarui pertanyaan Anda, berjudul, "Apakah orang lain merasa Scrum tidak gesit?"
Dave Hillier

Terima kasih telah berbagi videonya. Saya menemukan itu benar-benar mencerahkan.
MickJ

Nah, manajer suka gesit bahkan menyalahgunakannya. Sehingga mereka bisa menyalahkan pengembang. Jadi menggunakan gesit apa pun yang palsu atau tidak itu adalah masalah kebenaran politik.
Cinta

13

Apa yang Anda gambarkan adalah apa yang kami, Pelatih Scrum Profesional, lihat banyak di organisasi yang telah "mengimplementasikan scrum". Seringkali mereka "Melakukan XP di tim pengembangan" juga, yang berarti bahwa ada beberapa tes Unit yang berjalan di server build di suatu tempat. Ini bukan scrum .

Ya, Manajer Proyek dapat menggunakan jaminan Produk, terutama yang telah didigitalkan, untuk menyalahgunakan metrik yang dikumpulkan sistem tersebut. Tetapi Tim Pengembangan dan Scrum Master tidak seharusnya membiarkannya. Apa yang dilakukan Manajer Proyek di sana? Bukankah seharusnya itu menjadi Pemilik Produk ?!

Sama seperti XP dapat dilakukan dengan buruk, dan beberapa proses yang lebih ketat dapat terasa sangat lancar (dengan integrasi berkelanjutan, penyebaran, tetapi masih sangat didorong oleh rencana), Scrum hanyalah sebuah kerangka kerja. Dibutuhkan orang-orang baik yang memahami nilai-nilai dan proses untuk melaksanakannya dengan baik. Dibutuhkan pembelajaran berkelanjutan untuk mencapai sana.


12

Anda mungkin mengharapkan itu, tetapi hanya karena beberapa (banyak?) Orang menyalahgunakan Scrum dengan cara yang tidak gesit bukan berarti Scrum tidak gesit.

Manajer Proyek : tidak ada peran seperti itu dalam tim Scrum. Scrum Master tidak bertanggung jawab atas anggaran atau memenuhi tenggat waktu. Dia bertanggung jawab untuk membantu tim keluar dan menghilangkan segala rintangan yang menghalangi jalan mereka ke tujuan yang mereka janjikan. Dari apa yang Anda jelaskan, tampaknya PM Anda membajak Scrum untuk mengambil sendiri hak prerogatif yang biasanya pergi ke tim dan Pemilik Produk, mengabadikan kebiasaan komando dan kontrol sebelumnya.

Pelacakan waktu : Scrum merekomendasikan untuk melacak waktu yang tersisa dan menjumlahkannya untuk menentukan status sprint, bukan menunjukkan waktu yang dihabiskan oleh anggota tim individu. Ini mungkin tampak detail tetapi membuat semua perbedaan antara budaya yang berorientasi pada kesalahan dan pendekatan yang berorientasi pada tujuan.

Dari Panduan Scrum :

Memantau Perkembangan Sprint

Kapan saja dalam Sprint, total pekerjaan yang tersisa dalam Sprint Backlog dapat dijumlahkan. Tim Pengembangan melacak total pekerjaan ini yang tersisa setidaknya untuk setiap Scrum Harian untuk memproyeksikan kemungkinan mencapai Sasaran Sprint . Dengan melacak sisa pekerjaan di seluruh Sprint, Tim Pengembangan dapat mengelola kemajuannya.


Tidak dapat dihindari untuk menjadi budaya yang berorientasi pada kesalahan bahkan Scrum 100% benar secara teori dalam teori.
Cinta

2

scrum adalah metodologi manajemen proyek

agile adalah metodologi pengembangan perangkat lunak (-ish)

scrum + gesit bekerja dengan sangat baik

scrum tanpa gesit ... tidak terlalu banyak


3
Sangat menarik bahwa Scrum dulunya merupakan metodologi pengembangan perangkat lunak tetapi seiring waktu telah berkembang menjadi metodologi manajemen proyek.
winarama

2
Saya pikir itu semacam tak terhindarkan. Para dev hanya tidak memiliki rasa kepemilikan dalam proses (tidak menginginkannya). Dalam ulasan sprint baru-baru ini, saya mempertanyakan tujuan tim: menulis perangkat lunak, atau membuat grafik burndown terlihat bagus. Saya menyatakan maksud saya, tetapi kemudian semua PM di ruangan itu harus berusaha keras untuk menekankan pentingnya bla bla bla. lol!
Rob

2
@ T-Pane: Lebih menarik lagi bahwa Scrum pada awalnya diusulkan sebagai metodologi pengembangan produk baru - hbr.org/1986/01/the-new-new-product-development-game/ar/1
Steven A. Lowe

2
@ StevenA. Rendah Ah Scrum, ini dalam perjalanan penemuan diri.
winarama

1
Saya tahu ini sudah tua tetapi jawaban ini sepenuhnya salah. Scrum adalah suatu kerangka kerja yang cocok dengan pola. Agile adalah seperangkat nilai dan prinsip.
Venture2099
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.