Apakah berlari Scrum berarti bekerja pada kecepatan tercepat mungkin?


21

Saya baru-baru ini mewawancarai beberapa perusahaan yang melakukan Agile, Scrum agar lebih tepat dan ada beberapa hal yang sepertinya tidak Agile bagi saya. Saya akan mengambil satu kasus yang sangat menarik minat saya saat ini, yaitu sprint Scrum.

Satu manajer proyek tertentu yang saya ajak bicara (ya, saya katakan manajer proyek) dengan bangga menyatakan bahwa orang-orang di timnya mengerti ("diberi tahu" adalah apa yang saya ambil dari konteks) bahwa Anda tidak pulang ketika jam kerja selesai , Anda pulang saat pekerjaan selesai, tidak peduli berapa banyak yang dibutuhkan. Apa yang saya baca di sela-sela adalah bahwa kita mengemas fitur sebanyak mungkin ke dalam sprint dan bekerja lembur untuk mewujudkannya.

Sekarang, saya belum melakukan Agile sekarang (bekerja dengan lembaga keuangan dan pemerintahan yang sebagian besar masih lebih suka air terjun) tetapi pemahaman saya adalah bahwa:

  • sprint in Scrum adalah nama untuk iterasi umum dalam Agile;
  • tim harus bekerja dengan kecepatan yang berkelanjutan dan mencoba untuk menghindari lembur jangka panjang karena itu hanya berdampak pada waktu yang singkat dan efeknya dikerdilkan oleh masalah yang mereka hadapi dalam waktu yang lama.

Apakah pernyataan saya benar? Dan, haruskah saya menganggap presentasi manajer sebagai bendera merah?


Tidak ada pengalaman nyata dengan Agile, tetapi dari apa yang saya pahami, beban kerja sprint Anda harus seimbang dengan durasi sprint Anda, jadi apakah pengembang meremehkan beban kerja mereka atau manajer hanya memberi mereka pekerjaan tanpa meminta tanggapan mereka tentang beban kerja . Dalam hal ini mungkin yang terakhir. - Perbaiki saya jika saya salah,
Andreas

4
@gnat Saya pikir pertanyaannya terlalu berbeda
Andreas

27
"... kamu tidak pulang ketika jam kerja selesai, kamu pulang ketika pekerjaan selesai, tidak peduli berapa banyak yang dibutuhkan ...". Berlari seperti angin. Dia idiot.
JᴀʏMᴇᴇ

Saya memilih untuk membuka kembali pertanyaan ini. Pertanyaan duplikat yang diajukan adalah sama-sama-baru-manajemen mikro memiliki kesamaan dengan pertanyaan ini, bahwa manajer menyebut sesuatu "scrum" dan penanya ingin tahu apakah ini benar-benar scrum. Pertanyaan ini adalah tentang "lembur" yang diusulkan tentang "tidak diizinkan untuk berbicara dengan pengembang lain".
k3b

"... bahwa kamu tidak pulang ketika jam kerja selesai, kamu pulang ketika pekerjaan selesai, tidak peduli berapa banyak yang dibutuhkan" tampaknya seperti konflik langsung dengan konsep kunci kecepatan berkelanjutan - saya akan bekerja di sana jika saya harus meletakkan makanan di atas meja. HST, jika ini terjadi dari waktu ke waktu, saya tidak punya masalah dengan itu. Terkadang, terlepas dari segala upaya, ada krisis, dan pelanggan yang lebih dulu. Tapi dia membuatnya terdengar seperti itu adalah kejadian biasa, dan itu mengagumkan. Artinya adalah bahwa mereka tidak melakukan root root untuk memahami mengapa itu terjadi dan memperbaiki masalah yang mendasarinya.
Don Branson

Jawaban:


27

Anda tidak perlu mencari jauh untuk melihat bahwa praktik-praktik ini bertentangan dengan prinsip-prinsip di balik Agile. Salah satu prinsip di balik Agile Manifesto menyatakan:

Proses lincah mempromosikan pembangunan berkelanjutan. Sponsor, pengembang, dan pengguna harus dapat mempertahankan kecepatan konstan tanpa batas.

Beberapa tahun yang lalu, Scrum membuat halus namun penting perubahan . Alih-alih tim berkomitmen untuk pekerjaan yang dapat dicapai, mereka meramalkan apa yang mereka pikir bisa mereka lakukan.

Perubahan itu terjadi karena pelecehan, yang terdengar sangat mirip dengan sikap jangan-pulang-sampai-selesai yang Anda gambarkan. Dalam pengembangan, ada banyak faktor di luar tim yang tidak dapat mereka komit - untuk menggunakan analogi cuaca, Anda tidak bisa "berkomitmen" bahwa besok akan hujan.

Untuk langsung menjawab pertanyaan Anda:

  • ya, Sprint adalah nama untuk iterasi di Scrum lihat jawaban ini untuk perbedaannya
  • ya, tim harus bekerja dengan kecepatan yang berkelanjutan. Satu-satunya kepastian lembur adalah bahwa hal itu akan mengurangi produktivitas tim dalam jangka panjang.
  • ya, itu adalah bendera merah!

23

Ya, Anda benar, dan jika saya diberi tahu apa yang Anda katakan, saya akan lari dari sana secepat mungkin. Mereka hanya menggunakan gesit sebagai alasan. Kedengarannya seperti mars kematian klasik.


3
Bukankah pawai kematian biasanya berakhir? Proyek itu terdengar seperti neraka abadi jika begitulah cara mereka bekerja sprint demi sprint.
DXM

5
Tidak, dalam pawai kematian selalu ada "kita hanya perlu mendorong ke versi berikutnya, maka kita dapat refactor dan memperbaiki bug! Oops, kami berjanji kepada klien versi berikutnya berikutnya dalam dua bulan, hanya perlu mendorong ke berikutnya berikutnya versi!" dan seterusnya, Anda mendapatkan idenya.
Miki Watts

2
@DXM memiliki akhir ketika semua orang berhenti atau diberhentikan. Proyek Death March bisa berlangsung bertahun-tahun.
Dogweather

3
@DXM pawai kematian berakhir ketika Anda mati.
Dave Hillier

hmm, saya rasa saya memproyeksikan pengalaman saya sendiri di sana. Entah bagaimana dalam pikiran saya proyek yang salah dikelola adalah kombinasi dari mars kematian diikuti oleh bulan keraguan ke mana harus pergi berikutnya. Tim kami yang paling lama duduk di jempol mereka dengan tumpukan kosong hampir 8 bulan. Kemudian kami akan diberikan 4-6 bulan untuk rilis dengan pernyataan "kami berada pada siklus rilis tahunan"
DXM

11

Ada satu hal kunci yang dapat membuat ini diterima: tim menerima lingkup sprint.

Di Scrum, tim tidak hanya mendapatkan pekerjaan yang ditugaskan. Pemilik produk bernegosiasi dengan tim untuk memprioritaskan pekerjaan produk dan pekerjaan teknis (hutang). Manajer proyek, pemilik produk, dan tim kemudian bernegosiasi tentang apa yang ditarik ke dalam sprint dan apa ruang lingkup pekerjaan itu.

Di dunia ini, tim pada dasarnya mengatakan "kita bisa menyelesaikan pekerjaan X, diuji dan dikirimkan iterasi ini". Jadi saya berharap tim untuk sesekali bekerja lembur untuk memenuhi komitmen ini.

Yang mengatakan, begitu banyak tempat bajingan lincah - dan begitu sedikit pemimpin tim dapat bernegosiasi secara efektif dengan orang-orang yang biasanya bos mereka ... Saya akan menganggap ini sebagai bendera merah besar.


8
"sesekali bekerja lembur untuk memenuhi komitmen ( perkiraan salah ) ini" => membuat estimasi yang salah menjadi kebiasaan
nyamuk

1
@gnat - pssh. Estimasi terkadang tinggi. Perkiraan terkadang rendah. Jika meremehkan menjadi tren, itu pasti masalah. Tetapi itulah mengapa iterasi ada: untuk membantu memperbaiki estimasi.
Telastyn

8
Memprogram sweatshop umumnya tidak menerima negosiasi oleh pekerja.
maple_shaft

1
@gnat: Jika Anda menemukan, sebagai sebuah tim, bahwa Anda terbiasa meremehkan pekerjaan, Anda harus berkomitmen untuk mengurangi pekerjaan di sprint berikutnya.
Bart van Ingen Schenau

Ketika tujuan manajemen adalah menyelesaikan sebanyak mungkin pekerjaan, terlepas dari batasan jam kerja (dan pengalaman menunjukkan ini benar dalam sebagian besar kasus), dan tujuan karyawan adalah menyelesaikan sebagian besar pekerjaan tanpa melebihi pekerjaan yang dibayar jam (saya akui bahwa beberapa manajer mungkin berpendapat bahwa ini optimis), maka terlepas dari kesalahan bawaan dalam estimasi, penjadwalan akan selalu cenderung>> jam kerja. Perpanjangan logisnya adalah bahwa tujuan karyawan harus bergeser menjadi terlalu rendah. @BartvanIngenSchenau, inilah kebiasaan yang berkembang secara alami.
Steven Evers

1

Scrum dipecah menjadi sprint di mana Anda memperkirakan satu set tugas yang harus diselesaikan dalam durasi sprint itu (biasanya 2 minggu, tetapi saya telah melihat di mana saja dari 1 hari hingga 4 minggu). Saya pikir ini menciptakan insentif untuk tugas yang salah. PO (pemilik produk) menginginkan estimasi rendah untuk mendapatkan komitmen besar per sprint. Tim akan memberikan perkiraan besar untuk menghasilkan grafik burndown yang bagus untuk dilihat oleh para PM. Ini, tentu saja, menunjukkan organisasi yang jelek. Anda benar-benar ingin mendapatkan perkiraan yang akurat dan tidak takut gagal atau membawa cerita ke sprint berikutnya atau menyelesaikan awal dan menarik tugas tambahan dari jaminan. Saya pikir istilah "sprint" menciptakan gambar orang yang bekerja lebih cepat.


1
kecuali bahwa PO tidak boleh memiliki bagian dalam proses estimasi. Jika mereka gesit, tim akan bertanggung jawab untuk membuat perkiraan dan berdasarkan perkiraan tim PO hanya dapat mengubah prioritas jaminan.
DXM

2
"Tim akan membuat perkiraan besar untuk menghasilkan grafik pembakaran yang bagus untuk dilihat oleh para PM.": Ini adalah salah satu alasan mengapa saya pikir seluruh mekanisme ini cacat. Saya pikir seorang manajer bisa mendapatkan kinerja yang jauh lebih baik dari tim yang mereka percayai daripada dengan memaksa tim untuk memberikan perkiraan untuk dimasukkan ke dalam grafik.
Giorgio

Tim harus, tetapi seperti yang saya katakan, mereka memiliki insentif untuk membuat estimasi. Jika PO-lah yang membayar, mereka dapat memberikan tekanan untuk memperkirakan lebih agresif. Sebagai latar belakang, saya bekerja dalam konsultasi sehingga tim scrum adalah rekan kerja saya, sedangkan PO biasanya berasal dari luar dan membayar tingkat tagihan kami yang meningkat :)
jiggy

@Giorgio, tim yang tidak dapat dipercaya selalu dapat memperkirakan dan memperburuk keadaan. Tetapi tim yang dapat dipercaya, bahkan para pakar, dapat belajar memperkirakan lebih baik. Inilah sebabnya mengapa estimasi dibuat, dan kemudian dibandingkan dengan pekerjaan yang sebenarnya, untuk mencoba meningkatkan kemampuan mereka untuk memperkirakan. Mekanismenya tidak cacat, memiliki tim yang memanfaatkan sistem adalah masalahnya, dan akan menjadi masalah terlepas dari sistem manajemen.
Chris

1

Tidak: scrum sprint adalah kotak waktu, tidak lebih, tidak kurang. Pada awal sprint / iterasi, tim memberikan perkiraan jumlah poin cerita yang mereka yakini dapat mereka capai, berdasarkan hal-hal seperti kinerja sebelumnya, ketersediaan, acara mendatang, hambatan terbuka, dll. Mereka kemudian bernegosiasi dengan pemilik produk tentang cerita pengguna mana yang dimasukkan ke dalam sprint. Yaitu (atau tadi? Lihat jawaban lain) komitmen yang diberikan tim kepada pemilik produk.

Selama pengembangan, jika ternyata hal-hal tidak benar-benar seperti yang diperkirakan (ini adalah pengembangan perangkat lunak setelah semua) dan ada risiko tim tidak akan memenuhi komitmen, mereka memberi tahu pemilik produk bahwa ada risiko satu atau lebih cerita akan tidak selesai.

Dan itu tidak masalah. Tentu, rasanya tidak enak, harus mengakui pada akhir sprint bahwa sprint gagal, tapi ini bukan kekalahan, ini adalah peluang untuk perbaikan. Karena pada akhir sprint / mulai yang baru, Anda bisa melakukan sprint retrospektif, dan hal pertama yang akan ditanyakan siapa pun adalah 'Mengapa kita gagal sprint ini, dan apa yang perlu kita lakukan untuk tidak gagal lagi ? ' Salah satu opsi adalah memberikan lebih sedikit komitmen (= mengambil lebih sedikit poin cerita).

tl; dr: Pace Berkelanjutan. Scrum adalah tentang irama, sesuatu yang dapat dipertahankan tim tanpa batas waktu berdasarkan sprint-to-sprint. Bekerja lembur bukan; tim akan menjadi terlalu banyak bekerja, pekerjaan akan menjadi ceroboh, anggota akan memanggil sakit atau berhenti sama sekali, dan kemudian Anda memiliki masalah yang jauh lebih besar daripada lari cepat yang gagal.


0

Proses lincah mempromosikan pembangunan berkelanjutan. Sponsor, pengembang, dan pengguna harus dapat mempertahankan kecepatan konstan tanpa batas.

Dari orang-orang Agile Manifesto

Bekerja lembur sepanjang waktu tidak terdengar berkelanjutan bagi saya.

Yang mengatakan, saya melihat tidak ada masalah dengan komitmen pegas menjadi yang kuat (jika itu cara tim ingin bekerja), dan harus bekerja lembur ketika Anda berkomitmen berlebihan atau mengacaukan perkiraan adalah insentif yang baik untuk menjadi lebih baik dalam memperkirakan atau berkomunikasi. harapan untuk PO.


0

Satu manajer proyek tertentu yang saya ajak bicara (ya, saya katakan manajer proyek) dengan bangga menyatakan bahwa orang-orang di timnya mengerti ("diberi tahu" adalah apa yang saya ambil dari konteks) bahwa Anda tidak pulang ketika jam kerja selesai , Anda pulang saat pekerjaan selesai, tidak peduli berapa banyak yang dibutuhkan. Apa yang saya baca di sela-sela adalah bahwa kita mengemas fitur sebanyak mungkin ke dalam sprint dan bekerja lembur untuk mewujudkannya.

Itu bukan Scrum. Beban kerja yang diusulkan untuk kotak waktu didasarkan pada kecepatan tim , bukan pada daftar keinginan manajer. Mereka hanya mencoba menipu Anda agar percaya bahwa bekerja lembur tanpa akhir adalah "Agile", padahal sebenarnya tidak. Tim akan menjadi lebih efisien saat bekerja tanpa terganggu dan fokus, tetapi Scrum bukanlah tongkat ajaib untuk keuntungan efisiensi yang tiada akhir .

Entah manajer memiliki sedikit kesalahpahaman tentang Agile, atau (lebih mungkin) ia berpikir bahwa pengembang itu bodoh. Di sisi lain, ketika tim menerima sprint lagi dan lagi, mengetahui bahwa mereka perlu melakukan kerja lembur, mungkin mereka memang bodoh dan tidak pantas mendapatkannya lebih baik?

Saya kira, Anda tahu jawabannya ... ;-)

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.