Banyak buku dan artikel Scrum mengatakan bahwa sprint yang gagal (ketika tim gagal menyelesaikan beberapa fitur dari Sprint Backlog) bukan sesuatu yang buruk, itu terjadi dari waktu ke waktu, dan itu sebenarnya dapat berguna jika tim belajar dari kesalahan mereka dan meningkatkan sesuatu di sprint berikut. Dan tim seharusnya tidak dihukum karena tidak menyelesaikan pekerjaan yang telah mereka lakukan.
Cara Anda "menghukum" perilaku semacam ini adalah dengan membatasi jumlah pekerjaan yang tidak dapat diselesaikan orang pada sprint berikutnya. Peluang untuk mengerjakan hal-hal keren menghilang. Hadiah untuk melakukan pekerjaan yang baik adalah lebih banyak pekerjaan.
Ini terlihat hebat dari sudut pandang pengembang, namun, katakanlah kita memiliki perusahaan perangkat lunak "Scrum-Addicts LLC" yang mengembangkan sesuatu untuk klien serius ("Money-Bags Corporation"):
Manajer Scrum-Addicts menyarankan untuk membuat perangkat lunak untuk Money-Bags. Mereka menyetujui daftar fitur, dan Money-Bags meminta untuk memberikan tanggal pengiriman. Manajer Scrum-Addicts berkonsultasi dengan tim scrum mereka, dan tim mengatakan akan memakan waktu 3 minggu. sprint lama untuk menyelesaikan semua fitur Manajer Scrum-Addicts menambahkan 1 minggu untuk aman, berjanji untuk mengirimkan perangkat lunak dalam 1 bulan dan menandatangani kontrak dengan Money-Bags Setelah 4 sprint (batas waktu pengiriman) tim Scrum hanya dapat memberikan 80% fitur (karena tidak berpengalaman dengan sistem baru, kebutuhan untuk memperbaiki bug kritis pada fitur sebelumnya di lingkungan produksi, dll ...) Seperti yang disarankan Scrum, pada titik ini, produk berpotensi dapat dikirim, tetapi Money-Bags membutuhkan 100% fitur, sebagaimana disebutkan dalam kontrak. Jadi mereka melanggar kontrak dan tidak membayar apa pun.
Scrum-Addicts berada di ambang kebangkrutan karena mereka tidak mendapat uang dari Money-Bags, dan para investor kecewa dengan hasilnya dan tidak mau lagi membantu perusahaan.
Jika pada hari Senin saya bertaruh Anda $ 100 hujan akan turun pada hari Kamis dan hujan tidak turun sampai hari Jumat Anda berhak mengambil uang saya. Jika, alih-alih kesempatan untuk bertaruh, yang Anda inginkan adalah ramalan cuaca maka kami membutuhkan kontrak yang memungkinkan saya memberi Anda ramalan yang diperbarui pada hari Selasa.
Jelas, tidak ada perusahaan perangkat lunak yang ingin berada dalam posisi Scrum-Addicts. Apa yang saya gagal mengerti tentang Agile dan Scrum adalah bagaimana mereka menyarankan tim harus berurusan dengan perencanaan dan tenggat waktu untuk menghindari situasi yang dijelaskan di atas.
Pikirkan MENGAPA MB ingin mengambil bola mereka dan pulang. MB tidak menuntut pekerjaan dilakukan dalam sebulan sejak awal. SA menjanjikan 100% fitur penting dalam satu bulan dan tidak memberikan. SA menetapkan tenggat waktu bukan MB. SA bahkan secara sewenang-wenang menambahkan satu minggu ke tenggat waktu. Jadi mengapa ini tenggat waktu?
Kadang-kadang ketika bersaing untuk perusahaan perangkat lunak kerja menyerah pada godaan untuk pamer dan menjanjikan bulan. Profesional dengan cermat menentukan apakah bulan bahkan diperlukan. Yang merupakan kebutuhan lebih penting untuk MoneyBags? 100% fitur atau produk yang berfungsi dalam waktu satu bulan? Apakah mereka tahu apa yang benar-benar kritis? Apakah ada beberapa acara mendatang yang menetapkan tenggat waktu yang sulit?
Jika saya Scrum-Addicts sedang merundingkan kontrak ini, saya ingin tahu lebih banyak tentang kebutuhan bisnis Money-Bags dan menyusun kontrak untuk memberikan fleksibilitas sebanyak yang dapat diterima Money-Bags. Saya akan mengajari mereka bagaimana proses tangkas bekerja sehingga mereka tahu apa yang diharapkan dari kami.
Dengan cara ini daripada mengharapkan semuanya tiba-tiba bekerja dengan sempurna dalam sebulan mereka akan mengharapkan untuk mengevaluasi pengiriman pertama dalam 1 hingga 2 minggu.
Jadi, untuk meringkas, saya punya 2 pertanyaan:
Siapa yang harus disalahkan? Manajer, karena itu tugas mereka untuk melakukan perencanaan yang tepat
. Tim, karena mereka berkomitmen untuk melakukan lebih banyak pekerjaan daripada yang bisa dilakukan orang
lain
Siapa pun bisa menghentikan parodi ini sebelum kita punya waktu sebulan.
Saya bisa menyalahkan Money-Bags Corp karena merekrut tim yang jelas-jelas mewakili proses air terjun yang gesit. Kontrak itu sendiri menjelaskan bahwa ini tidak gesit. Perencanaan untuk dilakukan dalam sebulan tidak membuatnya gesit.
Jika Anda bersikeras bahwa gesit, gesit dengan hanya satu sprint yang panjang sebulan. Yang, ya, saya tidak akan merekomendasikan karena itu, sekali lagi, hal yang sama dengan air terjun.
Apa yang Harus Dilakukan?
Bagaimana dengan tangkas? Memberikan sesuatu setiap sprint? Dapatkan umpan balik sebelum batas waktu? Sprint selama seminggu? Bagaimana kalau menegosiasikan ulang kontrak kejam itu tepat saat Anda mencurigai tenggat waktu lebih berbahaya daripada bersembunyi dan berdoa? Paling tidak Anda bisa berhenti membuang-buang waktu untuk proyek yang hancur dan menemukan pelanggan yang lebih masuk akal.
Manajer harus memindahkan tenggat waktu 2x (atau 3x) kali lebih lambat dari perkiraan tim asli.
Pengganda tenggat waktu sama bermanfaatnya dengan menyetel jam tangan Anda 15 menit lebih awal sehingga Anda tidak akan pernah terlambat. Anda hanya bisa membodohi diri sendiri begitu lama sebelum Anda menyadari apa yang Anda lakukan.
Perkiraan awal salah. Cobalah untuk menangkap betapa salahnya. 5 minggu, memberi atau mengambil beberapa minggu adalah ungkapan sederhana yang memungkinkan Anda mengungkapkan seberapa tidak pasti tanggal penyelesaiannya. Daripada mencoba menebak secara akurat, Anda menebak betapa liarnya tebakan Anda. Lakukan beberapa pekerjaan nyata dan dapatkan beberapa data nyata. Kemudian Anda dapat mulai membuat taksiran dengan rentang yang lebih sempit. Satu hingga dua minggu adalah banyak waktu untuk melakukan ini.
Anggota tim harus didorong untuk melakukan semua pekerjaan yang mereka lakukan untuk apa pun (dengan mengeluarkan penalti untuk sprint yang gagal)
Anggota tim harus didorong. Gagal, berkomitmen, atau sebaliknya. Daripada membangun konsekuensi buatan seperti hukuman atau bahkan bonus (wortel dan tongkat) penelitian telah menunjukkan bahwa orang yang melakukan pekerjaan kreatif seperti pemrograman merespons paling baik jika memberikan tiga hal: Otonomi, Penguasaan, dan Tujuan.
Daniel Pink berbicara tentang hal ini dengan TED . Pembicaraan tentang motivasi tidak gesit tetapi saya dengan mudah melihat bagaimana memetakan poin-poin ini menjadi gesit:
Otonomi - Saya ingin mengarahkan hidup saya sendiri - Biarkan saya memilih pekerjaan dari jaminan.
Penguasaan - Saya ingin menjadi lebih baik dalam hal yang penting - Umpan balik pelanggan.
Tujuan - Saya ingin menjadi bagian dari sesuatu yang lebih besar dari diri saya - Tim kolaboratif.
Tim harus membatalkan Scrum karena tidak sesuai dengan tenggat waktu perusahaan. Kebijakan Scrum dapat mencapai batas waktu lebih akurat daripada air terjun. Mengingat batas waktu scrum dapat memenuhi itu. Mungkin memenuhi hanya dengan 1 dari 47 fitur tergantung pada waktu, fitur, dan keterampilan tetapi dapat memenuhi itu.
Proyek lincah dapat ditata sedemikian rupa sehingga setiap malam saat tim pulang, ia siap dikirim. Ini tampak konyol kecuali jika Anda menganggap pengiriman meminta pelanggan untuk menguji dan memberikan umpan balik. Semakin cepat itu terjadi semakin cepat Anda dapat melakukan penyesuaian. Ini mencapai setiap tenggat waktu yang mungkin. Hanya saja tidak setiap fitur. Tapi itu mengarahkan Anda ke fitur yang penting.
Kita semua harus menghentikan pengembangan perangkat lunak dan bergabung dengan biara
Benar, seperti mengunci saya di ruangan yang jauh dari kehidupan nyata akan membuat saya menulis kode KURANG.
Saya telah mengedit jawaban ini hingga ukurannya. Jika Anda penasaran baca riwayat sunting.